灾难恢复测试 & 个人备份方案更新

 
软件研究=) › 服务器维护&配置der日常

TLDR: 数据不仅要做 3-2-1 备份, 还别忘了定期做数据恢复的测试! 特别是在大量的数据需要备份时, 备份本身出现错误也是难免的, 通过测试确保自己做的是有效的备份!

接下来是我自己的流水账式的分析…

0x00 现有系统的分析(确定需要备份的内容)

目前来说我作为一个三脚猫运维, 自己维护的系统主要分为两部分:

  1. 公开的服务

  2. 个人使用的私有系统

    • HomeLab 服务器 (承载了大部分不公开的服务)
    • 各个云平台的一些 VPS
    • 笔记本电脑 / 手机

其中的”公开服务”我在搭建的时候就将较高的可用性和较低的维护成本纳入了考量范围, 通过尽可能多的使用静态网页, Serverless 边缘计算, PaaS 等技术, 使得这些公开服务本身尽可能的简单可靠, 将基础设施的维护工作直接托管给各个平台, 基本没有什么需要备份的内容(因为部署的都是构建产物).

所以重头任务落在了个人的设备数据和服务器数据备份上.
部署了一大堆东西需要备份的 HomeLab部署了一大堆东西需要备份的 HomeLab

0x01 正在使用的备份方案

之前很多文章里都东拉西扯的分享过我使用的一些备份方案.

不再赘述, 总结如下:

  • 安卓手机:

    • 照片同步到 Google Photos
    • 少量应用数据使用谷歌账号的备份 (大部分应用不需要备份, 数据都是联网的)
    • QQ/微信聊天记录在电脑上保留, 手机不做备份
    • 其他需要备份的文件使用 Syncthing 同步到 HomeLab

  • 笔记本电脑:

    使用 Syncthing 将需要备份的文件同步到 HomeLab (主要是 Users 文件夹排除一些不必要的项目)

  • Google / Github 等网站的数据:

    定期手动使用 Google Takeout / Export GitHub Data 等方式导出数据, 存到 HomeLab

  • HomeLab:

    使用 Syncthing 接收来自手机和电脑的文件, 同时也保存了不少其他的冷数据 + 程序.

    使用 Duplicati 将所有的数据加密备份到了云盘.
    Duplicati 备份Duplicati 备份

0x02 灾难恢复测试

之前一直用的这套备份设置, 确实在发生意外情况 (如不小心删了还没进 Git 的文件, 作死给手机刷机刷崩了等) 的时候避免了数据的丢失.

但这并不能充分证明我的备份的可靠性. 如果发生更大的意外情况, 比如整个 HomeLab 的硬盘阵列损毁 / 笔记本或手机损坏的情况下, 备份是否可靠仍需要进一步的测试.

但同时, 数据本身的安全性和恢复的便捷性又是不可兼得的两面, 备份方案应该在”证明我是我”和”不让别人冒充我访问数据”间达到平衡.

于是开始了漫长且痛苦的数据恢复测试过程.

前提假设: 我丢失了我所有的电子设备和存储介质.

  1. 去购买新的手机和电脑, 并及时去补办我的手机卡. 通过手机号验证/人脸验证/好友辅助验证, 我可以及时恢复对手机上支付宝/微信/QQ的访问, 其他一些需要使用的国产 APP 也可以使用手机验证登录.
  2. 使用短信验证 + 邮箱验证(微信扫码登录) + 我背出的 Google 账号密码 + 我抄写在纸上的一次性恢复代码, 我肯定可以恢复对 Google 账号的访问. 可以恢复备份在 Google 上的照片和其他的一些应用和设置.
  3. 使用我抄写在纸上的恢复代码和背出的主密码可以恢复对密码管理器的访问, 密码管理器中可以找到我用于备份的云盘的账号密码和备份使用的 AES 密钥. 从云盘上下载所有文件, 并解密相关文件, 得到我笔记本的备份和 HomeLab 中的文件, 至此上述所有文件恢复完成.

上述的关键步骤我都已经在陌生设备/陌生梯子节点/虚拟机中测试过, 正好测试找回密码的时候也做了一波密码轮换, 测试过程中也确实发现了一些问题:

  • Telegram 我绑定的不是 +86 手机号, 而绑定的是已经被注销的 GV 号, 若我同时丢失手机和电脑, 我会失去对 TG 账号的访问.
  • 微信找回密码的过程非常繁琐… 比如通过绑定的邮箱找回密码可能提示有风险不能找回…?? 那你让我绑定邮箱干啥? 微信明明可以学习阿里用人脸验证 + 好友辅助验证或邮箱辅助, 但实际上很可能需要人工申诉. 虽然没有什么特别好的解决方法, 但我决定把微信零钱提到银行卡里, 以防突发情况被锁在账号外面连钱都用不了…
    多少是有点毛病的微信设计多少是有点毛病的微信设计
  • duplicati 在恢复大备份的时候非常慢, 慢到不可接受.

从安全性方面考虑, 国内应用主要验证我的手机号, 国外应用主要验证密码 + 2FA, 安全性相关的问题总结如下.

  • 密码安全: 使用密码管理器随机生成的密码, 如果有可能使用 2FA. 密码学能很大程度上保证网盘上的备份的安全.
  • 终端安全: 不要安装可疑的程序, 安装 AV, 电脑和手机的终端安全再怎么强调也不为过. 要不手机短信/ PC 内存中的密码和原文件甚至可能直接被读取.
  • 防范社会工程学攻击: 机器不会犯错, 但人会. 网络安全警钟长鸣, 不要让自己成为系统中最大的漏洞.

0x03 优化现有设置

其实不难看出, 我上面的模拟恢复过程中, 主要是从网盘恢复了我绝大部分 HomeLab 上的文件, 其余的只是找回我的账号和密码管理器访问权而已. 所以这一步的可靠性就显得尤其重要了.

又测试了一大波各种网盘.

https://forum.duplicati.com/t/big-comparison-borg-vs-restic-vs-arq-5-vs-duplicacy-vs-duplicati/9952

我 HomeLab 需要备份的文件大约有 500 万个, 共 4TB, 最大的文件有 1TB 的加密卷, 最小的文件有一堆 <4 KB 的代码小文件. 这种备份规模给各个备份软件的鲁棒性提出了不小的要求.

最终在一个礼拜内完成了到 Onedrive 的备份的只有 Duplicati 和 Duplicacy, 其他很多软件甚至没能成功完成备份. (卡死/不断报错)

Duplicati 在备份过程中把小文件打包成块, 块大小可以调到很大, 可以更好地支持小文件不友好的后端, 上传速度更高, 但依赖本地数据库且 CPU 占用高. 恢复文件慢!

Duplicacy 就不依赖本地数据库, 但在服务器上会产生大量小文件, 备份失败率相对更高一些, 速度比较慢. 恢复文件相对较快.

最后我选择了同时使用了 Duplicacy 和 Duplicati, 分别同时加密备份到 E5 Onedrive 和南京大学的世纪互联 Onedrive 两个网盘, 并配置了邮件提醒备份状态.

本文采用 CC BY-NC-SA 4.0 许可协议发布.

作者: lyc8503, 文章链接: https://blog.lyc8503.net/post/disaster-recovery-test/
如果本文给你带来了帮助或让你觉得有趣, 可以考虑赞助我¬_¬