ops/storage: Backup considerations

Author: taoky

docs/ops/storage/backup.md

@@ -15,7 +15,7 @@
 - 使用 `tar` 归档数据目录。
 - 使用 `rsync` 同步数据目录。
 - 使用数据库的 dump 工具（例如 `mysqldump`）备份数据库。
-- 使用 [Btrfs](./filesystem.md#btrfs-snapshot) 或 [ZFS](./zfs.md#snapshot) 的快照与 send/receive 功能。
+- 使用 [Btrfs](./filesystem.md#btrfs-snapshot)、[ZFS](./zfs.md#snapshot) 或 LVM 提供的快照功能。Btrfs 与 ZFS 提供了 send/receive 功能以便网络传输。
 - 使用 `rclone` 同步到云存储（例如 OneDrive、S3 对象存储等）。
 - 使用诸如 [Duplicity](https://duplicity.gitlab.io/)、[BorgBackup](https://www.borgbackup.org/) 等备份工具。
 - 特定平台可能有专用的备份工具，例如虚拟化平台 Proxmox VE 的 [Proxmox Backup Server](https://proxmox.com/en/products/proxmox-backup-server/overview)。
@@ -24,7 +24,37 @@
 
     快照是文件系统的特性，如果文件系统损坏，那么快照就都无法正常读取。而 RAID 只能在硬盘故障数量小于对应等级限制时才能保证数据完整性，无法防止在诸如误删除、自然灾害等情况下数据的丢失与损坏。
 
-以下从上述方法列表引申开来，介绍一部分工具的使用方法与技巧。
+以下首先介绍设计备份时需要注意的问题，之后从上述方法列表引申开来，介绍一部分工具的使用方法与技巧。
+
+## 备份的注意事项 {#backup-considerations}
+
+除了简介中提到的 3-2-1 原则以外，备份的设计还需要关注**版本管理**与**数据一致性**。
+
+版本管理的问题很容易理解：如果备份的版本只有一份的话，那么一旦数据被误删除，并且触发了备份，那么被删除的数据就没法用正常方法找回了。不过如果数据很大的话，存储每份版本就会需要大量的磁盘空间，因此在选型时需要考虑使用支持增量备份或去重的方案。
+
+而数据一致性的问题在不少时候会被忽视。
+
+!!! note "崩溃一致性"
+
+    很多时候，我们希望即使程序崩溃、系统断电，程序维护的数据内部状态仍然是一致的。这被称为崩溃一致性（crash consistency）。一般来讲，数据库都实现了崩溃一致性。
+
+即使应用实现了崩溃一致性，如果备份工具直接复制对应的文件，那么得到的文件也有可能是不一致的——这个文件可能前半部分在 A 状态，后半部分在 B 状态。因此，备份数据库一般都使用数据库软件提供的 dump 工具导出 SQL，而不是直接用 rsync 等工具简单复制数据库对应的存储文件。
+
+如果需要备份的文件有一致性的要求，并且不方便使用专用的工具，那么也可以使用文件系统的快照功能避免上述提到的问题。
+
+最后，在有条件的情况下，需要验证备份的有效性，避免出现备份损坏或不完整的情况。
+
+!!! example "反面例子"
+
+    2017 年，GitLab 由于操作失误，在错误的数据库主机上执行了命令导致数据丢失。尽管设置了各种备份，他们没能够第一时间有效恢复：
+
+    - LVM 备份每天执行一次，上一次执行还是手动在 6 小时之前做的；备份的数据会加载到 staging 环境里面，但是 webhook 数据会被删除。
+    - 常规备份每天执行一次，但是没人知道备份到了哪里；等到找到的时候发现备份结果只有几个字节。
+    - PostgreSQL 的备份因为版本不兼容，实际上一直运行失败，啥都没备份。
+    - Azure 的磁盘快照没有给数据库服务器开启。
+    - S3 的备份也是空的。
+
+    于是最后，五重备份只留下了一个 6 小时前、没有 webhook 数据的备份。
 
 ## Rsync