备份并非简单之事

# 备份绝非易事 来源：https://filipovski.net/2026/09/16/backups-arent-simple.html ### 备份绝非易事 *Aleksandar Filipovski (https://filipovski.net/), 2026\-09\-16* **另请参阅：John Salvatier的优秀博客《现实拥有惊人的细节》(https://johnsalvatier.org/blog/2017/reality-has-a-surprising-amount-of-detail)** --- 我在某处看到过一条让我印象深刻的评论，大致是这样的： “世上有两种人：一种经历过数据灾难性丢失，另一种迟早会经历。” 为了给这篇博文找到出处，我发现几乎每个系统管理员都有自己版本的这句名言，但核心意思都一样：数据丢失的发生率比我们希望的要高得多，而且当它发生时（几乎总是在最糟糕的时刻），我们大多数人准备得都极为不足。 我敢确认自己也有过类似的经历。小时候，我们曾把家里笔记本电脑和台式机上的所有家庭照片都转移到了一块外置硬盘上，以腾出空间。这方法一直很管用，直到有一天，我爸想用这块硬盘作为我们电视顶盒（就是那种老式的（https://mk.wikipedia.org/wiki/%D0%9F%D0%BE%D0%B4%D0%B0%D1%82%D0%BE%D1%82%D0%B5%D0%BA%D0%B0:BoomTV.jpg））的存储空间，然后被提示需要格式化硬盘。他点了确认，硬盘就被重新格式化了。文件索引被删除，我们只剩下一块名义上空白的硬盘。 要怪他搞砸了很容易，但只有从事科技工作后才会明白，导致这种错误是一连串的失误。首先，我们把所有照片都放在一个地方，而且没有做备份。其次，大多数面向消费者的软件通常都有醒目的免责声明，告诉你格式化磁盘意味着丢失数据（而那个顶盒没有，真是糟糕的UI）。除此之外，你怎么能指望一个非技术人员了解这些呢？ 幸运的是，我们最终恢复了照片，这算是给我们上了一堂处理数据的便宜课程。你永远不会把重要的东西只放在一个地方。可能出错的事情有一百万种。你的硬盘可能坏掉、被偷，或者在冷存储中位元腐烂（硬盘有磁性颗粒，可能会莫名其妙地偏移；固态硬盘则由NAND晶体管制成，会漏电，时间一长就会损坏数据）。 所以我们的首要原则是拥有*备份*，也就是把你的文件复制一份放在别处。到目前为止，这听起来不错。 但这还没有解决外接硬盘可能带来的麻烦。勒索软件可能会加密你的文件，而你可能会犯各种错误，从误删文件的小失误，到运行脚本用零覆盖所有数据的灾难性错误。 因此，我们的备份不应该是第一块硬盘的镜像，因为我们还希望能够回溯时间，回到出错之前。重要的是，这意味着使用类似RAID 1的方式镜像磁盘是不行的。我们需要其他能*快照*事物的方法。 我们多久创建一次快照？也许对于我们保存照片的案例，应该每周运行一次备份。如果我们丢失了6天23小时的数据，那是可以接受的。这在IT领域被称为*恢复点目标（RPO）*，在实际案例中，它从对不能丢失数据的关键金融机构的<30秒，到对一些小企业的24小时或更长（如果他们甚至有灾难恢复策略的话）不等。 创建快照意味着我们的存储负担会增加。如果RPO是24小时，最终每周你会有7个快照。每月30个。一年365个，如果你真的不去清理你的快照。所以你需要轮换备份（https://en.wikipedia.org/wiki/Backup_rotation_scheme）。 假设我采用最直接的方法，决定保留14天的快照。当我创建新快照时，就删除最旧的那个并添加新的。很简单，但这现在要求我保持警惕。也许我存了很多数据，懒得检查过去两周是否有东西损坏了？但话说回来，我也不能储存一整年的备份，因为它们对我来说根本不相关。一年中第2天和第3天发生的事情，在第364天几乎毫无意义。因此，我们进行备份的粒度必须改变。离今天越近，快照越频繁；时间越久远，快照越不频繁。 所以，也许我们每天轮换一次备份，保留14天；同时创建每周备份，轮换周期为7周；再创建每月备份，轮换周期为12个月。这应该更有效率。但我们的复杂度又增长了。我们现在有了一种叫做*基于GFS轮换、基于快照的备份*。这一串形容词还会继续增加，我们稍后就会看到。 也许这时你看看MPEG如何压缩视频（https://en.wikipedia.org/wiki/Video_compression_picture_types），会对电影中平静的场景（主角在完全静止的背景下说话而没有其他动作）如何用于视频压缩感到着迷。你注意到视频由大多是相似的帧组成，只因某些运动而变化，这些变化可以用一个向量来表示，占用很少的存储空间。这让你得出一个非常合理的结论：你的快照也遵循相同的模式！更重要的是，文件变化遵循肥尾分布，所以在给定时期内，绝大多数文件根本没有变化，只有极小一部分总是在变化。 因此，很明显我们不应该存储文件的相同副本，而应该*去重*。当我们需要引用已存在的文件时，可以使用硬链接。这样，我们在磁盘上只存储一份文件，然后从每个快照中引用它。这种方式在备份轮换中也能存活，因为我们从不删除文件，只删除目录条目。rsnapshot（https://github.com/rsnapshot/rsnapshot）正是使用这种方法，它被最好地描述为*增量*备份，因为我们只存储两个相邻快照之间的变化，而不是自上次完整备份以来的所有变化（这些被称为*差异*备份，在恢复时更可靠，但为简洁起见我不展开说了）。 这样做的节省存储空间并不是我们唯一的好处。我们在开头简单提到过，我们不会把所有东西存储在一台机器上。显然，这个过程还涉及网络，因为我们需要实际将文件从一台机器传输到另一台机器。去重备份节省了大量带宽，特别是当你使用云服务作为你的第二台机器时。这直接影响到你的财务成本。 总结一下，到目前为止，我们已经创建了一种*增量的、去重的、基于GFS轮换、基于快照的备份*。我们可以使用rsync从主机器拉取文件，用cron作业来运行我们的备份脚本。我们可以在任意多的机器上运行备份，添加另一台也很简单。更好的是，文件元数据得以保留，因此访问权限和文件所有权之类的东西都没问题。 受到开发这个解决方案成功的鼓舞，我们尝试用它来备份包含10个Docker容器的家庭实验室。但后来我们从各个机器的日志中发现备份失败了。原因是许多Docker容器喜欢创建根用户拥有的文件，而如果你不小心，可能会创建一个以默认用户身份运行的cron作业。 更糟糕的是，几乎每个Web应用都使用某种数据库。数据库有时喜欢将内容存储在内存中，然后分批刷新到磁盘以提高性能。这意味着如果我们运气不好，从备份恢复将因数据损坏而失败。因此，我们让备份也转储数据库，并在我们的Docker卷上赋予其完整的文件系统权限。这应该能解决问题了！ 然后你读到了关于一些事件（https://en.wikipedia.org/wiki/Deskstar）的文章，其中某个型号的硬盘出了名的故障率高，你开始琢磨是否应该把备份存储在两台不同介质类型的机器上。这样，特定硬件的故障就不太可能同时摧毁你的备份。谈到物理安全时，还在云端或家庭成员家中的机器上存一份异地备份。这样，你就真的不太可能因为电涌、洪水或火灾而丢失一切。这就是3\-2\-1备份名称的由来：3份副本，存储在2种不同的介质上，其中1份异地存放。 假设你决定选择一家云提供商作为异地备份。具体来说，是像Amazon S3这样的对象存储。你很快会发现我们当前的设置行不通，因为第一，当你上传文件到S3时，文件会丢失元数据；第二，向S3上传大量小文件的价格高得惊人。（文件大小也遵循肥尾分布）这两个事实使得把多个文件打包成一个tarball成为最佳选择。这样既能保留文件元数据，又能保持低成本。但问题来了，你该怎么做？是把所有东西都塞进一个巨大的tarball吗？显然不行，这样你的基于硬链接的增量备份就没意义了。最好把所有东西干净地分成50MB的块，但祝你好运，找到一种可验证安全的方式来完成这件事！ 直到此刻，自己动手做备份听起来像是一个下午就能完成的事情，但这正是我可能会放弃的地方。承担所有这些心理负担根本不值得。相反，你可以直接使用经过验证的工具，如Borg（https://www.borgbackup.org/）或Restic（https://restic.net/），它们能处理所有这些以及更多功能（加密、块级去重、校验和）。并且，要衷心感谢这个出色的开源社区构建、维护并实时测试这些工具，同时要理解经历了多少试错，才达到如今能为我们抽象掉所有这些复杂性的程度。 显然，如果你不实际测试恢复过程，这一切都毫无价值。所以，这也是一条你需要加入待办事项的小小数字卫生准则。因此，只要你每6个月运行一次恢复操作，你就可以尽情享受你的： #### 加密的、块级去重的、基于GFS轮换的、时间点归档的、云端3\-2\-1备份解决方案 同时确保不要在凌晨2点或3点运行备份，否则可能会发生可怕的事情。(https://www.endpointdev.com/blog/2013/04/avoid-200-and-300-am-cron-jobs/)