Backup

数据的长期保存

我们每个人每天都在产生各种数据。包括个人笔记、照片等等在内的许多数据， 许多可能不太容易再次获得或制造。今年夏天，我整理了一些自己二十年前刻录的光盘， 这里记录一下长期保存数据的一些原则、需要避免的陷阱，以及确保数据在数十年后仍然可用的最佳实践。

备份小故事一则

原载于 Telegram 频道。

今天来讲个关于备份的小故事。

以前有个同事之前在某使用UNIX的传统行业干了多年，他们的系统可用性要求不算高，但数据非常重要， 所以备份自然也是必不可少的。为了确保备份的安全性， 他们还雇了一家专门的保全公司定期把备份磁带从办公室拿走到该保全公司的仓库。

备份和代码审计

这次回北京之前的周末，FreeBSD安全团队发表了内部通知，发现 FreeBSD.org 有些机器被入侵，最近终于做了全面披露了。目前，基本的代码审计和攻击检查已经做完，部分机器还在重装的过程中。

对 FreeBSD 这样的开源项目来说，在基础设施遭到攻击之后，首先必须被怀疑的便是有可能有人在代码库中植入了新的后门。由于代码量十分巨大，逐行审计是非常不现实的。由于 FreeBSD 在 BSD 时代即采用了版本控制系统（最早 BSD 时代是 SCCS，FreeBSD早期是CVS，现在是 subversion），因此，每一行代码的来源，包括作者、具体的修改时间，以及为什么那样修改等等，都可以很容易地查找到。

tarsnap修正了一个重大安全漏洞

今天 Colin 在blog上介绍说 他刚刚修正了一个 TarSnap 重大安全漏洞。简单地说，用来加密密钥文件的AES-CTR实现时，计数器没有增加（正确的实现中计数器应该每次递增），导致在已知明文时能够通过加密块推算出一块数据使用的密钥，并用它来解密余下的数据。

ZFS的自动化备份

主任说：

冗余不做，日子甭过；备份不做，十恶不赦。

以前一直是每天手动给自己的新服务器做备份，最近找时间写了一套脚本来自动完成这个事情。

脚本没啥复杂的，大体的思路是这样：

1. 在源上根据日期命名生成一份新的快照；
2. 将上次备份机器收到的快照和新快照之间的差异 pipe 给 xz，然后再把结果pipe给ssh（使用key验证），传到备份机上；
3. 备份机解压缩、zfs receive之后，如果成功，ssh到源系统上记录自己拿到的那个新的快照日期；

由于是通过 Internet （从AS6939送到AS33651）传递快照，所以使用了压缩。用ssh来完成传输的考虑主要是因为它能够做到互相验证身份。

关于备份

指望硬盘不挂掉是 很拼人品的事情（附带说一句，从某种意义上说，21世纪的硬盘质量并没有下降，只是单位容量出现故障的概率没有显著提高，而硬盘容量的扩大使得单块硬盘的故障率看起来提高了，但是如果我们从单位容量的故障率来看，坏损率并没有非常显著的增长）。所以想要长久地保存数据，就必须采用各式各样的冗余和备份手段。冗余和备份是不一样的，前者往往会采用同样的访问控制逻辑，提供在线或近线的数据存储，强调的是数据访问的及时性；而后者则强调的是数据的可恢复性。

关于访问控制

一般来说，不希望备份与原始数据采取相同的访问控制机制。例如，对网站来说，可以读写数据库的那个 Web 访客的数据库账户，很可能并不能直接读写网站的备份数据。有时，备份甚至是以一种"外科手术"的方式进行的：对文件系统做快照，然后将快照打包发到异地的另一套系统。