先搞清楚小团队是怎么翻车的

先搞清楚小团队是怎么翻车的

我经历过和见过的备份事故，几乎没有一次是硬盘物理损坏这种标准场景。真正让人通宵救火的，是下面这几类：

• 备份和源在同一台机器上：脚本把数据库导到同机的 /data/backup，磁盘一满，数据和备份一起消失。
• 备份文件从来没有被打开过：跑了两年，第一次恢复才发现 dump 是 0 字节，因为脚本报错被 || true 吞掉了。
• 直接 rsync 数据目录：拷贝运行中的 /var/lib/postgresql，恢复出来起不来，或者落后半天。
• 密钥只掌握在一个人手里：负责备份的同事离职，加密仓库的密码随之失联。

因此，小团队的备份方案，第一目标不是“完整”，而是可恢复、可验证、不依赖某个人。

用 3-2-1 定骨架，把异地那份做成删不掉的

3 份数据、2 种介质、1 份异地，这个原则本身没错，关键在于实施时让异地那一份具备防篡改能力。

• 本地一份：生产机的每日 dump 或云盘快照，用来快速回滚。
• 内网一份：一台便宜 NAS 或备用机，用 restic 推到内网 SFTP。日常恢复从这里取，速度最快。
• 异地一份：对象存储（B2、OSS、R2 都行）。用独立云账号，开版本控制和对象锁（WORM），给备份脚本一个只有写权限、没有删除权限的 Access Key。这样即使生产账号被盗或被勒索软件加密，历史备份也删不掉。

具体到命令和工具

能少自研就少自研。restic 是我最推荐的一档：单文件二进制、自带加密去重、支持几乎所有对象存储。

restic -r s3:https://s3.us-west-004.backblazeb2.com/my-bucket backup /srv/app /etc/nginx --exclude '*.log' --exclude-caches

保留策略用 restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune，别无限堆，仓库会越来越慢。

数据库单独处理，不要混进文件备份：

• PostgreSQL 用 pg_dump -Fc -Z6 -f /backup/app-$(date +%F).dump appdb，小团队每天一次全量基本够用；单库超过 50G 再上 pgBackRest 做 WAL 归档。
• MySQL 用 mysqldump --single-transaction --quick，别用 --lock-tables 锁住线上表。
• 调度用 systemd timer 而不是裸 cron：Persistent=true 能在关机