备份保留策略：GFS 轮换，删哪些留哪些一次定好

我是小够。见过两种极端：一种是从不删备份，磁盘满了才发现三年前的备份还躺着；另一种是只留最新一份，哪天发现数据库三天前就坏了，最新备份里全是坏数据。备份保留策略就是解决这个问题的：留几份、留多久、删哪些，定成规则自动执行。

GFS 轮换是什么

GFS = Grandfather-Father-Son（祖父-父亲-儿子），借用了三代同堂的叫法：

• Son（子代）：每天一份，保留 7 天
• Father（父代）：每周一份（比如周日），保留 4 周
• Grandfather（祖父代）：每月一份（比如每月 1 号），保留 12 个月

这样任意时刻你手里有：最近 7 天的每天版本、最近 4 周的每周版本、最近 12 个月的每月版本。想恢复到"上周三"，有；想恢复到"三个月前"，也有。

为什么这样设计

• 绝大多数恢复需求是"最近几天的数据"，每天一份覆盖
• 偶尔需要"上个月的好版本"（比如坏数据潜伏了很久），每月一份兜底
• 总量可控：7 + 4 + 12 = 23 份，而不是 365 份

落地：脚本里加三行

备份脚本按日期命名是关键：

DATE=$(date +%Y-%m-%d)
tar -czf /backup/site-$DATE.tar.gz /var/www

保留策略用 find 按时间删：

# 删 7 天前的日备份（但周日和每月1号的不删，逻辑自行调整）
find /backup/daily -name "*.tar.gz" -mtime +7 -delete
find /backup/weekly -name "*.tar.gz" -mtime +28 -delete
find /backup/monthly -name "*.tar.gz" -mtime +365 -delete

更省事的办法：备份时直接分三个目录放，删除规则各管各的，逻辑清晰不出错。

小够的建议

• 保留策略要和恢复演练一起做：留了 12 个月的备份，一年后才发现解压失败，等于白留
• 数据库和文件可以不同策略：数据库变化快，日备份多留；静态文件变化慢，周备份就够
• 云端备份同样适用：对象存储的生命周期规则就是干这个的，配一次不用管

备份的价值不在"有"，而在"恢复时拿得到、打得开"。保留策略就是保证这一点的规则，别偷懒。

不同业务的保留策略示例

保留策略没有标准答案，看业务定。小够给三个常见场景的参考：

个人博客：日备留 7 天、周备留 4 周、月备留 6 个月。博客数据变化慢，6 个月的月备足够了。

小电商/业务站：日备留 14 天、周备留 8 周、月备留 12 个月。订单数据丢不得，日备多留一倍。

测试/实验机：周备留 4 周就够了。测试机的数据丢了重搭，保留策略可以激进一点，省磁盘。

原则：数据越重要、变化越快，保留越久、粒度越细。

云端同样要配保留

对象存储的备份别只管传不管删，配生命周期规则：

• 30 天后转低频存储（便宜）
• 90 天后删除

rclone 传上去的文件，云端按规则自动清理，本地脚本不用管云端那头。两边各管各的保留，逻辑清晰。

保留策略的三个坑

1. 只删旧的不验新的：保留 30 天的备份，结果第 30 天发现全是坏包。保留策略必须和恢复演练一起做
2. 日备和周备混在一起：删的时候分不清，写脚本时就分目录放，daily/、weekly/、monthly 各管各的
3. 法务要求：某些业务（电商订单、用户数据）可能有合规保留要求，先问法务再定删除周期，别删了不该删的

常见问题

Q：备份占地方，能不能只留 3 天？ A：看 RPO。3 天意味着"3 天前的数据丢了就找不回来"。个人博客可以，业务站不行。先定 RPO，再定保留。

Q：月备和周备内容重复，浪费空间？ A：用 borgbackup 这类去重工具，重复数据只存一份，保留 12 个月也不心疼。工具选对，保留策略可以大方点。

Q：保留策略要写进文档吗？ A：要。写下来：留几份、删哪些、谁负责检查。换人接手、自己半年后回来看，都靠这份文档。