① 三份副本，对付的是同时失效。 一份是生产数据，两份是备份。只有一份备份时，误删、勒索加密、错误的同步操作会同时命中生产与备份——它们挂在同一台机器、同一个账号可达的路径上。

② 两种介质，对付的是同批次的系统性缺陷。 同型号同批次的硬盘、同一个控制器的固件缺陷、同一套逻辑，会在相近时间出问题。介质不同，失效机制就不同。

③ 一份异地，对付的是同一物理位置的事件。 机房断电、空调漏水、火灾、被盗，这些会一次性带走同一房间里的所有副本。异地不是"另一个机柜"，也不是"另一台服务器放在同一排"。

⚡ 致命盲区：比这三条更容易被忽略的是第四条：备份目标不能长期在线可写。勒索软件只加密它够得着的挂载点，一个常年挂载、随时可写的备份盘，本质上是第二份生产数据。

# 保留 ACL、扩展属性、硬链接；这一份不带 --delete，旧版本靠目标端快照保留

sudo rsync -aHAX /data/ backup@nas:/backup/data/

# 归档式备份：按日期命名，旧的那份不动，直接传到另一台设备

sudo tar -czf - -C / data | ssh backup@nas "cat > /backup/data-$(date +%F).tar.gz"

💡 策略权衡：--delete 能让备份与源端保持一致，但它需要的正是删除权限——与"备份账号只写不删"不能同时成立。取舍只有两种：想要一致，就允许删，把"删不掉"交给目标端的定时快照；想要不可删，就在同步这一层不带 --delete，源端删掉的文件留在备份里，定期人工清理。

① 同城第二地点。 另一栋楼、另一个校区、合作单位机房。成本最低、带宽最好，缺点是扛不住城市级事件。

② 云对象存储的归档层。 天然异地、按量付费，缺点是取回要时间、要流量费。适合"平时不用、出事才取"的数据。

③ 磁带异地存放。 单 TB 成本最低，适合大体量冷数据。代价是要有驱动器、要有轮换流程、要有人负责。

① 备份包能不能打开。 介质在、密码在、加密密钥在、工具版本还在。加密备份里，密钥丢失导致的失效，比介质损坏更常见。

② 恢复要多久。 这才是真实的 RTO。计划里写"四小时恢复"，演练一次可能发现是两天——因为带宽、因为要跨地域回传、因为恢复流程只有一个人会。

③ 恢复出来的数据能不能用。 校验和一致、抽样能打开、数据库能起来、应用能接上。

# 列出快照，确认要恢复的版本在

restic snapshots

# 抽样校验仓库完整性，不必每次全量读

restic check --read-data-subset=5%

# 先试跑，看会恢复哪些文件，不动生产目录（--dry-run 需 restic 0.17 及以上）

restic restore latest --target /tmp/restore-test --dry-run