云备份与 3-2-1 原则：实用指南

备份为何会失败（以及 3-2-1 原则如何解决）

大多数数据丢失事件并非由罕见的奇异故障引起，而是来自那些平淡无奇的日常情况：在错误的目录里执行了 rm -rf、断电后数据库损坏、勒索软件加密了它所能触及的一切，或是某块磁盘悄无声息地报废。它们的共同点在于：所谓的"备份"要么根本不存在，要么存放在同一台机器上，要么从未真正经过测试。

3-2-1 原则是业界标准的应对之策，而且它刻意保持简单：

• 3 份数据副本（一份实时副本加两份备份）
• 2 种不同类型的存储介质或技术
• 1 份副本保存在异地

如果你诚实地遵循它，那么任何单点故障——无论是硬件故障、人为失误还是恶意软件——都无法同时摧毁这三份副本。本指南将展示如何在真实的 Linux 服务器上，使用快照、对象存储和 restic 备份工具落地 3-2-1 原则，并着重介绍如何将异地副本保留在沙特境内，以满足 PDPL 的数据驻留合规要求。

将 3-2-1 映射到真实基础设施

下面是一个典型 Web 应用或企业邮件工作负载的具体布局：

这满足了全部三个数字：三份副本、两种不同的技术（块快照与对象存储）、一份异地。至关重要的是，异地副本位于一套不同的存储系统中，因此生产块存储层的故障无法波及并损坏它。

第一步：快照——快速，但不够

快照会在某个时间点捕获整个服务器卷。它是从糟糕的发布或失败的升级中恢复的最快方式，因为你可以在几分钟内将整台机器回滚。

在 Skyline 云服务器或 VPS 上，你可以在任何有风险的变更之前从控制面板手动创建快照，也可以安排自动快照。需要注意的重要一点是：存放在同一服务商处的快照是副本 #2，而不是你的异地副本。它能防范你自己的失误，却无法抵御账户级别或区域级别的事故。切勿把快照当作你唯一的备份。

第二步：应用一致的数据库转储

快照是崩溃一致的，但不一定是应用一致的。对于数据库，应进行规范的逻辑转储，这样你就可以恢复单张表，而无需回滚整台服务器。

针对 MySQL/MariaDB：

mysqldump --single-transaction --quick --routines --triggers \
  --all-databases | gzip > /var/backups/db-$(date +%F).sql.gz

针对 PostgreSQL：

pg_dumpall -U postgres | gzip > /var/backups/pg-$(date +%F).sql.gz

--single-transaction 标志能在不锁写的情况下，为 InnoDB 表提供一份一致的快照。请将这些转储写入异地备份任务会拾取的目录中。

第三步：使用 restic 和对象存储创建异地副本

正是这份副本让整套策略真正成立。restic 是一款出色的开源备份工具：它会去重、压缩，并在任何数据离开服务器之前在客户端加密。最后这一点非常重要——你的数据在接触网络之前就已加密，因此存储服务商永远看不到明文。

针对一个 S3 兼容的对象存储桶进行安装和初始化：

# Install restic (Debian/Ubuntu)
sudo apt-get update && sudo apt-get install -y restic

# Point restic at your in-Kingdom object storage bucket
export RESTIC_REPOSITORY="s3:https://objects.example-region.com/my-backup-bucket"
export AWS_ACCESS_KEY_ID="<your-access-key>"
export AWS_SECRET_ACCESS_KEY="<your-secret-key>"
export RESTIC_PASSWORD="<a-long-random-passphrase>"

# Initialize the repository once
restic init

现在运行你的首次备份，把数据库转储和 Web 根目录都包含进来：

restic backup /var/www /etc /var/backups

首次运行之后，restic 只会上传发生变化的数据块，因此后续备份既快速又经济。

自动化与清理

添加一个每日定时任务和一项保留策略，让仓库不会无限增长：

# /etc/cron.d/restic-backup
30 2 * * * root /usr/local/bin/restic-backup.sh

#!/usr/bin/env bash
# /usr/local/bin/restic-backup.sh
set -euo pipefail
source /root/.restic-env   # exports the variables above

restic backup /var/www /etc /var/backups --tag daily
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

这会保留 7 个每日、4 个每周和 6 个每月的恢复点——这是一个在覆盖范围与对象存储成本之间取得平衡的合理默认值。

第四步：加固以抵御勒索软件

一份攻击者能够删除的备份算不上备份。勒索软件越来越多地把目标对准备份仓库。这里有两种实用的防御措施：

• 分离凭据：服务器使用的对象存储密钥最好是仅追加/仅写入的，不允许删除。请在一个独立且更可信的上下文中运行 restic prune。
• 不可变性 / 对象锁定：在支持的存储桶上启用一次写入多次读取（WORM）保留策略，使备份在设定的期限内无法被覆盖或删除。

这能把你的异地副本变成真正的最后一道防线。

第五步：测试恢复——人人都跳过的一步

未经测试的备份只是一种期望，而非一项计划。请安排一项定期的恢复演练：

# List available snapshots
restic snapshots

# Restore a specific snapshot into a scratch directory
restic restore <snapshot-id> --target /tmp/restore-test

# Verify repository integrity
restic check

确认恢复出来的数据库确实能够导入，并且应用能够启动。设置一个日历提醒，每月做一次。你第一次发现某份备份无法恢复，绝不应该是在一次真实的故障中。

为何境内很重要

如果你处理沙特阿拉伯境内人员的个人数据，那么 PDPL 和 NCA 的指引会促使你将数据——包括备份——保留在境内，除非你有合法的传输依据。你的异地副本仍然属于个人数据。将其托管在 Skyline Cloud 上，能为你提供境内数据驻留、供 restic 使用的 S3 兼容对象存储，以及当你身处事故之中、急需答案时的阿拉伯语支持。

立即开始

你可以在几分钟内搭建起一套完整的 3-2-1 方案——一台云服务器、快照，以及一个境内的对象存储桶。立即创建你的 Skyline Cloud 账户，构建一套你真正可以依赖的备份策略。