文章探讨了构建备份系统的策略，强调在编写脚本之前应制定明确的备份计划。核心内容包括选择全盘备份还是单个文件备份、利用快照确保一致性、决定推送或拉取架构，以及制定良好备份系统的指导原则。

IT笔记

目录

• 备份：不仅仅是简单的复制
• 备份计划：提出正确的问题
• 核心决策：全盘备份 vs. 单个文件备份
• 全盘（或存储）备份
• 单个文件备份
• 一致性的关键：快照的力量
• 架构：推还是拉？
• 我的备份系统指导原则
• 结论：下一步

备份：不仅仅是简单的复制

备份长期以来被许多人低估。从有缺陷的技术到“薛定谔的备份”（即从未测试过，因此既有效又无效），再到对备份是什么以及如何工作的概念性错误（RAID不是备份！），太多数据因备份不足而丢失。

如今，备份常常被忽视。许多人完全依赖“云”，却从未问过他们的数据是否真正受到保护。这是一个被许多人忽视的细节，但即使是主要的云提供商也采用共享责任模型。他们的条款通常明确表示，虽然他们保护基础设施，但保护和备份数据的最终责任在于用户。通过将所有数据放在“云”中、其他公司拥有的集群上或分布式Kubernetes系统上，备份似乎变得不必要。当我有时问开发人员或同事如何处理所有这些数据的备份时，他们看着我，好像我在说一种古老、未知且难以理解的语言。他们从未想过这个问题。但数据不是短暂的，必须以一切可能的方式保存。

我一直有一个理念：数据必须始终可恢复（并且尽可能快），以开放格式（意味着你不必购买任何东西来恢复或查阅它），并且一致。这些点可能看起来显而易见，但事实并非如此。

我遇到过各种数据丢失的场景：

• 数据中心被火灾摧毁——我在那里有142台服务器，但它们都在几小时内恢复了。
• 服务器机房被洪水淹没。
• 服务器在地震中被摧毁，通常是由于墙壁倒塌。
• 各种勒索软件攻击事件不断增加。
• 故意破坏的实体试图制造问题。
• 管理员犯的错误，这可能发生在任何人身上。

对于连接到互联网的服务器，如电子商务和电子邮件服务器，风险更高。在这里，不仅数据完整性至关重要，服务的连续运行也同样重要。本系列文章将回顾我的一些旧文章，解释我在这个主题上的核心思想，并至少部分描述我的主要技术。

许多人认为备份是简单的复制。我经常听到人们说他们有备份，因为他们“复制了数据”，但这往往是错误的，而且非常危险，给人一种虚假的安全感。复制实时数据库的文件几乎是无用的操作，因为结果几乎总是无法恢复。至少必须执行适当的转储，然后传输该文件。然而，许多人这样做，只有在面临紧急情况并需要恢复时才会意识到他们的错误。

备份计划：提出正确的问题

在接触任何文件之前，你必须从计划开始，而计划从提出正确的问题开始：

“我愿意承担多少风险？我需要保护哪些数据？在数据丢失的情况下，我能容忍多少停机时间？我有哪些类型和多少存储空间可用？”

第一个问题尤其关键。一种常见但有风险的方法是将备份存储在需要备份的同一台机器上。虽然方便，但这种方法在机器故障时失效。即使依赖经典的USB驱动器进行日常备份也不是万无一失的，因为这些设备与其他硬件组件一样容易发生故障。与普遍看法相反，即使是高端的不间断电源（UPS）也无法避免灾难性故障。

因此，第一步是制定一个管理计划，平衡安全性和成本。最安全的备份通常是存储在离源机器最远的地方。然而，这种方法引入了与空间和带宽相关的挑战。虽然局域网（LAN）备份相对简单，但网络外备份涉及额外的连接考虑。这可能会导致在备份和恢复过程中为了保持操作速度而减少备份数据量。

安全性并不总是等同于实用性。例如，使用200 MBit/sec的连接和2 TB的备份数据，恢复时间可能很长。然而，如果目标不是快速恢复，而只是确保数据可用，那么最安全的备份通常是最接近我们的备份。也就是说，一个我们可以“触摸”、断开连接并在离线时查阅的备份。

因此，必须制定一个根据特定需求定制的备份策略，记住没有“完美”的解决方案。

核心决策：全盘备份 vs. 单个文件备份

在规划备份策略时，一个关键决策是备份整个磁盘还是仅备份单个文件。或者两者都备份。每种方法都有其优缺点。

全盘（或存储）备份

优点：

• 完全恢复：恢复全盘备份可以快速将系统恢复到其确切的前一个状态，包括引导加载程序。
• 虚拟化系统中的集成：如果你的虚拟机是ZFS或btrfs等文件系统上的单个文件，你可以简单地复制该文件（在拍摄快照后）以获得虚拟机的完整备份。像Proxmox这样的解决方案提供了易于管理的全盘备份，可以通过命令行或Web界面访问。
• 虚拟环境中的灵活性：像Proxmox备份服务器这样的产品提供了从完整备份中恢复单个文件的能力，结合了两种方法的优点。

缺点：

• 物理机器的停机时间：通常需要关闭机器以创建全盘备份，导致操作中断。如果物理主机运行FreeBSD，可以采用混合方法，拍摄快照并复制主机的所有数据集。然而，恢复过程需要一些手动操作。
• 大空间需求：全盘备份可能消耗大量空间，包括不必要的数据。
• 潜在的减速和兼容性问题：备份过程可能很慢，并且可能遇到非标准文件系统配置的问题。

单个文件备份

虽然看起来更简单，但备份单个文件可能会变得复杂。

优点：

• 基本实用程序使用：可以使用标准的系统实用程序，如tar、cp、rsync等。
• 细粒度备份：允许备份特定文件并将其与以前的版本进行比较。
• 增量复制：仅备份文件的修改部分，节省空间并减少数据传输。
• 可移植性和部分恢复：可以单独移动文件并根据需要部分恢复。
• 压缩和去重：这些功能通常在文件或块级别可用。
• 操作连续性：可以在不关闭机器的情况下完成。

缺点：

• 存储空间需求：简单的复制解决方案可能需要大量存储。
• 需要文件系统快照：为了高效和一致的备份，在复制之前拍摄快照（如本机ZFS快照、btrfs、LVM卷快照或微软的VSS）是高度推荐的。
• 隐藏的陷阱：问题可能直到需要备份时才显现出来。到那时，可能为时已晚。

一致性的关键：快照的力量

备份“实时”文件系统涉及“开始”和“结束”时刻。在此期间，数据可能会发生变化，导致致命的不一致性。我过去遇到过这样的问题：一个大型MySQL数据库被破坏，我负责恢复它。我自信地使用了客户最后一次基于文件的备份，并恢复了各种文件（不是本机转储）。不出所料，数据库无法重新启动。大数据文件在复制开始和结束之间变化太大，导致其不一致。幸运的是，我还有一个适当的转储，所以我设法从中恢复。

问题很明显：备份实时文件系统是有风险的。一个开放的数据库，即使是像浏览器历史记录这样的基本数据库，也很可能被破坏，使备份变得无用。

解决方案是在开始备份之前创建整个文件系统的快照。这种方法冻结了数据的一致“时间点”视图。到目前为止，使用快照，我设法恢复了一切。

以下是我多年来探索的方法：

• 本机文件系统快照（例如，BTRFS或ZFS）：如果你的文件系统本身支持快照，明智的做法是使用此功能。它可能是最有效和技术上最合理的选择。
• LVM快照：对于使用LVM的用户，创建逻辑卷的快照是一种可行的方法。这种方法可能会导致一些空间浪费，虽然我仍然使用它，但偶尔会导致文件系统在快照销毁期间冻结，需要重新启动。这是一个罕见但反复出现的问题，尤其是在高I/O负载下的不同硬件设置中。
• DattoBD：我从其诞生之初就跟踪这个工具。我过去广泛使用它，但有时会遇到稳定性问题（内核恐慌或无法删除快照，迫使重新启动）。对于Datto的快照，我经常使用UrBackup脚本，它们方便且高效。

架构：推还是拉？

专家们长期以来的一个争论是备份应该由客户端（推）发起还是由服务器（拉）请求。在我看来，这取决于情况。

通常，我更喜欢在专用服务器上集中备份系统，这些服务器在高度安全的环境中维护，运行的服务最少。因此，我倾向于“拉”方法，即服务器连接到客户端以启动备份。

理想情况下，备份服务器不应从外部访问。它应该受到保护、加固，并且只能访问需要备份的设置。目标是尽量减少在客户端机器本身受到攻击时备份数据可能被泄露或删除的可能性（不幸的是，这种情况并不罕见）。

这并不总是可能的，但有办法缓解这个问题。一种方法是确保必须通过“推”备份的机器（即自己联系备份服务器）只能访问自己的空间。更重要的是，出于安全原因，备份服务器应在一段时间内维护自己的文件系统快照。这样，即使是最坏的情况（工作负载被破坏 -> 连接到备份服务器 -> 删除备份以勒索赎金），备份服务器也有自己的快照。这些服务器端快照不应从客户端主机访问，并且应保留足够长的时间，以确保任何破坏都能及时检测到。

我的备份系统指导原则

多年来，我倾向于对备份进行细粒度控制，经常发现需要恢复客户意外删除的特定文件或电子邮件。在我看来，一个好的备份系统应具备以下关键特性：

• 即时恢复和速度：系统应支持快速恢复并以高处理速度运行。
• 外部存储：备份必须存储在外部，而不是在正在备份的同一系统上。不过，本地快照对于立即回滚是个好主意。
• 安全性：我避免使用像Dropbox或Google Drive这样的主流云存储服务进行主要备份。拥有你的数据！
• 高效的空间管理：这包括压缩和去重等功能。
• 最小侵入性：系统应需要最少的额外组件来运行。

结论：下一步

备份的方法多种多样，在本系列中，我将描述我通常面对的主要场景。我将从备份服务器及其主要配置开始，然后介绍我使用的各种软件和技术。

但这将从下一篇文章开始，我将讨论构建备份服务器，当然，它将由FreeBSD驱动——就像我过去20年所有的备份服务器一样。

评论总结：

1. 备份的重要性与忽视

   • 观点：许多人忽视备份，甚至大公司也缺乏有效的备份策略。
   • 论据：评论2提到一家年营业额10亿欧元的公司依赖数据中心操作员的随机备份，导致生产数据库被毁后只能恢复四天前的数据。
     • 引用："They don't make their own backups. They rely on disk copies made by the datacenter operator, which happen randomly."
     • 引用："The most recent "backup" was four days old. Then we had to replay all transactions that happened during those four days."

2. 备份系统的复杂性

   • 观点：备份系统需要考虑数据的类型、变化频率和恢复速度。
   • 论据：评论4指出不同数据（如操作系统、配置、日志）需要不同的备份策略，评论5强调备份的可恢复性和文档化的重要性。
     • 引用："How data changes, and what changes it, matters when trying to optimize backups."
     • 引用："A good backup (system) is only good, if it has been tested to be restorable as fast as possible and the procedure is clear."

3. 备份策略的多样性

   • 观点：备份策略应根据数据量和需求定制，从简单到复杂均可。
   • 论据：评论6描述了一种简单的tar+compress+encrypt备份方法，评论8建议借鉴数据库的日志复制策略，评论9则分享了自建备份系统的经验。
     • 引用："I just tar+compress+encrypt a few select directories/files twice a week and keep a couple of months of rotation."
     • 引用："The cleanest, most compelling backup strategies are those employed by RDBMS products."

4. 备份与灾难恢复的区别

   • 观点：备份不等于灾难恢复，恢复时间和数据一致性至关重要。
   • 论据：评论10强调灾难恢复需要快速恢复系统，并区分了“崩溃一致性备份”和“应用一致性备份”。
     • 引用："Backup is not disaster recovery: In case of a disaster, you want to be up and running near-instantly."
     • 引用："Application consistent backups significantly reduce the chances of corruption."

5. 备份的安全性

   • 观点：备份应考虑安全性，避免依赖云服务的安全措施。
   • 论据：评论11建议使用加密工具如restic，确保备份数据对服务器不可见。
     • 引用："You shouldn't be backing up data in a way that's visible to the server. Use something like restic."

总结：

评论中强调了备份的重要性、策略的多样性以及备份与灾难恢复的区别。尽管备份需求因人而异，但共同点在于备份的可恢复性、安全性和文档化。无论是简单的本地备份还是复杂的分布式系统，关键在于确保数据的安全和快速恢复。