备份做几份、放哪里？独立开发者的 3-2-1 备份决策树

结论先行：备份用 3-2-1（3 份数据、2 种介质、1 份异地），且每份都真恢复过一次。别把备份和生产放一个爆炸半径（同机/同账号），一出事一锅端。异地存 B2/R2，一个月几毛到几块钱。

「独立开发者的选择题」第六题，是上一篇（数据库托管决策）的续命篇。数据库选错顶多浪费点预算，备份策略做错直接宣判项目死刑。 很多独立开发者把数据 Dump 到服务器本地 /backup 目录就当万事大吉，直到机器磁盘损坏或云厂商封号才发现全盘皆空。

先表态：我的备份铁律是 3-2-1 原则（3 份数据、2 种介质、1 份物理异地），配合定期自动化还原测试。异地冷备份统一走 Backblaze B2 或 Cloudflare R2，单月成本仅几毛钱，却能在灾难发生时保住项目底裤。

0、写在前面：5 套备份，差点全军覆没

先看技术圈人尽皆知的血泪教训：

• 2017 年 GitLab 删库大危机：深夜排查数据库延迟的运维工程师执行错命令，误删了主库生产数据目录；切换备库时发现备库也因为复制中断已落后数小时。慌乱中团队去翻灾备系统，发现当初布置的 5 套备份机制几乎全线瘫痪：
  • 机制 1（pg_dump 日常定时任务）：由于 PostgreSQL 客户端与服务端版本不匹配，早已静默失败数月，没有任何人收到报警；
  • 机制 2（Azure 磁盘快照）：仅对负载均衡配置打过快照，数据库盘未包含；
  • 机制 3（S3 异地同步）：传输脚本因权限异常悄然中断；
  • 机制 4（镜像备库）：误操作瞬间已把删除动作同步抹除。
    最终挽救 GitLab 命盘的，仅剩某位工程师 6 小时前手动调试时遗留的临时 LVM 卷快照。这 6 小时内全球开发者的 issue、PR 与评论永远消失。
• 2014 年 Code Spaces 被黑致公司清盘：代码托管平台 Code Spaces 的 AWS 控制台遭黑客勒索。黑客索要赎金未果后，顺着管理权限在几分钟内彻底删除了同账号下的全部 EC2 实例、EBS 卷、S3 存储桶与 RDS 镜像。因生产环境与备份共处同一个 AWS 账号，所有灾备副本瞬间归零。一家健康运营多年的公司直接在 12 小时内宣布倒闭解散。
• 2026 年自动化 Agent 误杀惨剧：某团队配置的代码自动化 Agent 获取了宿主机高权 API 凭证，由于脚本传参解析失误，直接把容器挂载目录与挂载在其下的同机备份目录一同递归清空。

这些事故给出两个不可推翻的事实：

1. 未经验证的备份只是安慰剂：脚本在跑不代表数据可用，静默损坏比没有备份更致命。
2. 同机或同账号备份等于零隔离：把备份放在同一台 VPS 的另一个分区，或者同一个云账号的不同目录，在账号失窃或整机受损时会被瞬间一锅端。

1、期望目标：独立开发者的灾备四底线

评估一套备份方案是否及格，紧扣以下四个指标：

• ✅ 可还原性（Restore Capability）：备份文件包含真实校验头，具备自动化还原演练脚本，每月至少能成功恢复到空测试库一次。
• ✅ 物理隔离（Blast Radius Isolation）：备份目的地位于完全独立的第三方法人主体或云平台（例如主机在 Vultr 或 DigitalOcean，异地存储在 Cloudflare R2 / Backblaze B2），哪怕主账号遭黑客清盘，异地备份不受任何波及。
• ✅ 恢复点目标（RPO）可量化：明确发生意外时允许丢失多长时间的数据（副业项目 24 小时、付费业务 1 小时内）。
• ✅ 成本与自动化防锈：每月存储成本控制在 1 美元以内；备份任务由守护进程调度并带退出码监测，失败时必须推送告警通知。

2、计划思考：3-2-1 架构与灾难演练

3-2-1 原则由摄影师 Peter Krogh 提出，如今已是基础设施领域的通用准则：

• 3 份副本：1 份线上生产数据 + 2 份独立备份数据；
• 2 种介质：本地热存储（主机 NVMe / 本地临时挂载点）+ 独立网络对象存储（S3 兼容协议）；
• 1 份异地：存放在不同地理区域、不同注册法人、不同云服务商的独立存储桶内，并开启对象锁定（Object Lock）防篡改。

3、工程落地：全自动化备份与验证实战

别用手动 tar 命令打游击战，下面这套组合使用工业级备份工具 restic，原生支持内容去重、客户端 AES-256 加密与 S3 远端直推。

生产脚本：/usr/local/bin/ittinker-backup.sh

在生产服务器创建该脚本，赋予执行权限 chmod +x /usr/local/bin/ittinker-backup.sh：

#!/usr/bin/env bash
set -Eeuo pipefail

# ==============================================================================
# ITTinker 3-2-1 生产自动化加密备份套件
# 包含：Postgres/SQLite 导出 + Docker 数据卷 + 环境变量配置 + Restic 增量异地推送
# ==============================================================================

export RESTIC_REPOSITORY="s3:https://<account-id>.r2.cloudflarestorage.com/prod-backups"
export AWS_ACCESS_KEY_ID="your-r2-access-key-id"
export AWS_SECRET_ACCESS_KEY="your-r2-secret-access-key"
export RESTIC_PASSWORD="YourStrongEncryptionPassphraseHere"

BACKUP_STAGING_DIR="/var/backups/staging"
TIMESTAMP="$(date +'%Y%m%d_%H%M%S')"
HEARTBEAT_URL="https://hc-ping.com/your-uuid-token"
TELEGRAM_BOT_TOKEN="your_bot_token"
TELEGRAM_CHAT_ID="your_chat_id"

notify_failure() {
  local exit_code=$?
  local err_msg="[CRITICAL] 备份任务异常中断！主机: $(hostname) 行号: $1 退出码: $exit_code"
  echo "$err_msg" >&2
  curl -s -X POST "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendMessage" \
    -d "chat_id=${TELEGRAM_CHAT_ID}&text=${err_msg}" >/dev/null || true
  exit "$exit_code"
}
trap 'notify_failure $LINENO' ERR

mkdir -p "${BACKUP_STAGING_DIR}"
chmod 700 "${BACKUP_STAGING_DIR}"

echo "[1/4] 导出 PostgreSQL 核心库数据..."
if docker ps --format '{{.Names}}' | grep -q '^postgres$'; then
  docker exec -t postgres pg_dump -U postgres -d production_db -Fc \
    > "${BACKUP_STAGING_DIR}/db_production_${TIMESTAMP}.dump"
fi

echo "[2/4] 备份 SQLite 嵌入式库..."
if [ -f "/opt/stacks/app/data.db" ]; then
  sqlite3 /opt/stacks/app/data.db ".backup '${BACKUP_STAGING_DIR}/sqlite_app_${TIMESTAMP}.bak'"
fi

echo "[3/4] 初始化与推送数据到 Cloudflare R2 / Backblaze B2..."
# 首次运行自动初始化存储桶
restic snapshots >/dev/null 2>&1 || restic init

restic backup \
  --tag "automated-daily" \
  "${BACKUP_STAGING_DIR}" \
  /opt/stacks/docker-compose.yml \
  /opt/stacks/.env \
  /etc/caddy/Caddyfile

echo "[4/4] 自动应用生命周期保留策略 (7日+4周+6月)..."
restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6 \
  --prune

# 清理本地暂存缓存
rm -rf "${BACKUP_STAGING_DIR:?}"/*

# 上报心跳探测，证明备份全链路执行完毕
curl -fsS --retry 3 "${HEARTBEAT_URL}" >/dev/null
echo "备份成功同步至异地存储，心跳已更新。"

调度配置：使用 Systemd Timer 替代不稳定的 Cron

Crontab 的默认环境变量极其残缺，且进程死锁或失败时没有任何日志留存。推荐使用 Systemd Service + Timer 进行守护：

创建服务单元 /etc/systemd/system/ittinker-backup.service：

[Unit]
Description=ITTinker Automated Restic Encrypted Backup Task
After=network-online.target docker.service
Wants=network-online.target

[Service]
Type=oneshot
User=root
ExecStart=/usr/local/bin/ittinker-backup.sh
StandardOutput=journal
StandardError=journal
Nice=19
IOSchedulingClass=2
IOSchedulingPriority=7

创建定时器单元 /etc/systemd/system/ittinker-backup.timer：

[Unit]
Description=Trigger ITTinker Backup daily at 03:30 UTC with random delay

[Timer]
OnCalendar=*-*-* 03:30:00 UTC
RandomizedDelaySec=900
Persistent=true

[Install]
WantedBy=timers.target

激活并验证定时器：

systemctl daemon-reload
systemctl enable --now ittinker-backup.timer
systemctl list-timers --all | grep ittinker-backup

RandomizedDelaySec=900 会让任务在 15 分钟内随机漂移触发，避免多台机器在同一整点瞬间打爆对象存储的 API QPS。

4、实战演练：自动化验证与空跑还原

没有验证过的备份等同于自欺欺人。搭建一条轻量级还原测试脚本 /usr/local/bin/ittinker-verify-restore.sh，在沙盒容器中校验备份有效性：

#!/usr/bin/env bash
set -Eeuo pipefail

RESTIC_REPOSITORY="s3:https://<account-id>.r2.cloudflarestorage.com/prod-backups"
REST_DIR="/tmp/restore-sandbox-$(date +%s)"
mkdir -p "${REST_DIR}"

cleanup() {
  rm -rf "${REST_DIR}"
  docker stop test-pg-verify >/dev/null 2>&1 || true
  docker rm -v test-pg-verify >/dev/null 2>&1 || true
}
trap cleanup EXIT

echo "从异地 R2 存储拉取最新快照..."
restic restore latest --target "${REST_DIR}" --path "/var/backups/staging"

LATEST_DUMP=$(find "${REST_DIR}" -name "*.dump" | head -n 1)
if [ ! -f "${LATEST_DUMP}" ]; then
  echo "❌ 校验失败：未在快照中发现可用数据库 Dump 文件！" >&2
  exit 1
fi

echo "启动临时孤岛验证容器..."
docker run -d --name test-pg-verify \
  -e POSTGRES_PASSWORD=verify_secret \
  -e POSTGRES_DB=verify_db \
  postgres:16-alpine

echo "等待临时数据库就绪..."
until docker exec test-pg-verify pg_isready -U postgres >/dev/null 2>&1; do
  sleep 1
done

echo "执行还原灌入测试..."
docker cp "${LATEST_DUMP}" test-pg-verify:/tmp/test.dump
docker exec test-pg-verify pg_restore -U postgres -d verify_db --clean --if-exists /tmp/test.dump

ROW_COUNT=$(docker exec test-pg-verify psql -U postgres -d verify_db -t -c "SELECT COUNT(*) FROM users;" | xargs)
echo "✅ 校验通过！沙盒数据表还原成功，核心用户表行数统计：${ROW_COUNT}"

对于使用 SQLite 的项目，校验更简单：只需拉取最新 .bak 文件，执行 sqlite3 backup.db "PRAGMA integrity_check;"，输出 ok 即可确信数据文件未发生底层损坏。

5、决策矩阵：RTO、RPO 与成本平衡

备份不是越多越好，而是依据业务属性在数据丢失容忍度（RPO）与恢复耗时（RTO）之间找到工程平衡：

方案架构	典型适用场景	目标 RPO (最大丢失)	目标 RTO (恢复耗时)	月存储与计算成本
SQLite + Litestream	单机微型 SaaS、个人博客	< 1 秒 (WAL 实时同步)	< 2 分钟 (快速拉取最新快照)	< $0.5 / 月 (走 R2 免费出口)
Postgres + Restic 每日异地	早期 MVP、日单量较小的产品	24 小时 (按日落盘)	10-20 分钟 (手动或脚本回放)	< $1.0 / 月 (B2 / R2 基础存储)
WAL-G 归档 + 基础备份	成长型业务、有真实付费客群	5 分钟 (按事务日志归档)	5-15 分钟 (支持 PITR 任意点回滚)	$3 - $8 / 月 (存储 WAL 增量)
全托管云数据库 (DO / Supabase)	团队作战、无专职运维角色	1 分钟 (平台内置全自动备份)	2-5 分钟 (控制台一键克隆)	$15 - $25 / 月 (包含管理溢价)

在 Docker 容器化环境中，Volume 卷的备份操作规范请参阅 /posts/docker-volume备份与迁移实战/；服务器磁盘健康度巡检可结合开源仓库中的脚本工具维护：

# 检查当前存储卷剩余容量，防止备份过程因磁盘打满造成系统卡死
curl -fsSL https://raw.githubusercontent.com/richardson-ittinker/ittinker-scripts/main/vps-health-monitor/vps-health-monitor.sh | bash

6、排错避坑：备份失效的五种典型隐患

• 静默失败（Silent Errors）：许多开发者写 pg_dump | gzip > backup.gz。一旦 pg_dump 遇到密码错误或连接断开直接报错退出，管道右侧的 gzip 依然会正常压缩空标准输入并输出一个几十字节的空压缩包，给外层退出码返回 0。必须在脚本头部声明 set -Eeuo pipefail，一旦管道任何环节失败立刻中断并报警。
• 凭证同归于尽：将备份加密私钥明文保存在生产机 /root/.secret 且没有任何离线抄写。一旦机房服务器物理损坏，异地虽有加密备份，密码却永远随原机火化。正确做法是将私钥存入 1Password / Bitwarden 密码管理器，并生成离线纸质应急手册。
• 存储桶只写不删导致天价账单：未在 R2 / B2 设置生命周期规则（Lifecycle Rule），每日打满 2GB 备份包，三年累积数 TB 冷数据，每月被按存储总量扣费。务必借助 restic forget --prune 或在云控制台配置 30 天自动清除策略。
• 跨公网传输超时爆满本地磁盘：打包了数十 GB 的 Docker Volume 缓存直接丢进 /tmp 目录，导致根目录瞬间 100% 占满，整个生产环境只读宕机。暂存目录应指定独立持久化路径，并在写盘前使用 df -h 检查可用空闲。
• 勒索病毒顺藤摸瓜污染异地：一旦宿主机被攻陷，黑客直接从当前环境变量读取云存储的读写凭证，进而下发 s3:DeleteBucket 抹除所有冷备份。防御手段是在 Backblaze B2 或 AWS S3 上开启不可变对象锁定（Object Lock / Legal Hold），设定写入后 30 天内禁止任何 API 执行覆盖或删除。

7、高频 FAQ

Q：有了 VPS 供应商提供的每日整机快照，还需要做应用级 3-2-1 备份吗？
A：必须做。VPS 厂商的整机快照有两个天然死穴：第一，快照与服务器同属一个服务商账号，一旦账号因风控、支付卡失效或网络争端遭暂停，快照一并无法提取；第二，快照属于底层块设备热拷，PostgreSQL 这类数据库在写事务密集时打整机快照，还原时极易引发页损坏。应用层逻辑导出的 dump 文件才是最终兜底利器。

Q：Backblaze B2 与 Cloudflare R2 在异地备份场景下怎么选？
A：两者都是极佳选择。Backblaze B2 每 GB 存储成本略低（约 $0.006/GB/月），适合 GB 级以上的中大型归档；Cloudflare R2 的最大优势在于出口流量费为零，且对低频小体积读取完全不计网络费用。个人项目数据量在 10GB 以内的，直接选 Cloudflare R2，日常备份验证拉取没有任何网络支出。

Q：生产数据库每晚备份时，会造成网站访问卡顿吗？
A：合理使用导出参数就不会。PostgreSQL 的 pg_dump 运行在 READ COMMITTED 事务隔离级别下，只会读取提交版本，绝不会锁住表的读写操作；针对 SQLite，务必使用官方专用的 .backup 命令行或 API，不要在运行中直接用 cp 拷贝正在进行写操作的 .db 文件，否则拷贝出的副本大概率发生页索引撕裂。

Q：备份文件推送到公有云对象存储安全吗？
A：只要遵守客户端预加密原则即可确保高枕无忧。在推送至云端之前，数据已在本地内存或临时目录经过 restic 的 AES-256 算法加密，远端对象存储服务商看到的仅是一堆高强度不可逆的二进制块，在无解密口令的情况下不存在任何明文泄漏可能。

---

延伸阅读：容器数据挂载与迁移详见 /posts/docker-volume备份与迁移实战/；边缘网络防护与域名配置详见 /posts/cloudflare免费功能速查/ 与 /posts/cloudflare加速配置实战/；异地冷备推荐绑定 Backblaze B2 或 Cloudflare R2，配合 Vultr 计算实例构筑低成本高韧性架构。