Linux 备份策略与工具：rsync、tar、borg 到底怎么选

在运维圈有句话：备份不做，事故必到。硬盘会坏、机房会淹、手会滑——唯一能让你睡安稳觉的，是一份可靠且验证过的备份。但"备份"两个字背后门道很多：全量还是增量？本地还是异地？直接拷文件还是逻辑导出？这篇文章先把 3-2-1 法则讲透，再带你用 rsync、tar、borg/restic 三种工具实际备一次，并强调一个被 90% 人忽略的真理：没演练过的恢复，等于没备份。

一、3-2-1 备份法则

这是业界金标准：3 份数据副本、2 种不同介质、1 份异地（离线或云端）。含义是：你手里至少要有原始数据 + 两份备份；备份不要都放同一块硬盘；其中一份要离你的机器远一点（比如对象存储、另一台远程服务器），这样本地火灾/勒索软件也带不走它。很多人只做"同机复制"，本质是零备份——硬盘一挂全没了。先有法则，再选工具，顺序不能反。

二、rsync：文件级同步与硬链接快照

rsync 是 Linux 备份的瑞士军刀，增量传输、只传变化的部分，极省带宽。最经典的玩法是用 --link-dest 做"硬链接快照"：每天一份新目录，没变的文件用硬链接指向昨天的文件，既保留多版本又几乎不占额外空间。排除缓存用 --exclude。推到远程走 SSH（ed25519 密钥优先）。危险操作 --delete 会删除目标端多余文件，务必先用 -n 演练再真正执行，否则可能清空目标目录。

rsync -a /data/ /backup/2026-08-06/
rsync -a --delete --link-dest=/backup/2026-08-05/ /data/ /backup/2026-08-06/
rsync -a -e "ssh -p 22" /data/ user@host:/backup/
rsync -avn --delete /data/ /mirror/

三、tar：最朴素的归档打包

tar 把一堆文件打成一个 .tar.gz，适合一次性全量归档或随人带走。zcvf 创建压缩包，xvf 解包，-C 指定解包位置，--exclude 排除目录。它简单可靠、几乎所有系统都自带，是"懒人备份"的首选。缺点是增量能力弱（要靠 -g 快照文件），大目录反复打包也费 CPU。小网站、配置文件、一次性迁移，用 tar 最顺手。

tar zcvf backup_$(date +%F).tar.gz /etc /home
tar xvf backup_2026-08-06.tar.gz -C /tmp/restore
tar zcvf backup.tar.gz --exclude='*.cache' /home

四、borg / restic：去重 + 加密

当你备份量变大、又想异地存到不可全信的云盘，borg 和 restic 是当代答案。它们分块去重——相同内容只存一份，备份越多次反而越省空间；并且客户端加密，哪怕仓库在别人服务器上，别人也看不到你的数据。borg 用 repokey 模式，restic 支持 SFTP/对象存储等多种后端。备份完记得 prune 清理旧快照、check 校验完整性，防止静默损坏。

borg init --encryption=repokey /mnt/backup/borg-repo
borg create --stats /mnt/backup/borg-repo::$(hostname)-$(date +%F) /etc /home
borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=6 /mnt/backup/borg-repo
restic init --repo /mnt/backup/restic-repo
restic backup /etc /home

五、数据库必须逻辑备份

这是新手最容易翻车的地方：直接 tar 数据库的数据目录文件，恢复时往往打不开，因为运行中的数据库文件是不一致的。正确做法是用逻辑导出：MySQL 用 mysqldump，PostgreSQL 用 pg_dump，它们生成的是可重放的 SQL，能在任意同版本实例恢复。记得加 --single-transaction 保证一致性。把导出的 .sql 再纳入上面的 rsync/tar 流程，才是完整方案。

mysqldump -u root -p --single-transaction --routines --events mydb > mydb_$(date +%F).sql
pg_dump -U postgres mydb > mydb_$(date +%F).sql

六、自动化：让备份自己跑

手动备份迟早会忘。把它交给 cron 或 systemd timer：比如每天凌晨 2 点跑一次 rsync 快照。关键是把输出重定向到日志，并保留策略写清楚（每日/每周/每月各留几份）。备份脚本开头加 set -euo pipefail，任一步失败就退出，避免生成"半成品备份"还以为成功了。自动化 + 日志，备份才真正可靠。

0 2 * * * rsync -a --delete --link-dest=/backup/prev /data/ /backup/current/ && ln -snf /backup/current /backup/prev

七、最关键的：演练恢复

备份的终极检验只有一个：恢复。很多团队从不演练，真出事才发现备份文件损坏、权限丢失、或者根本不兼容。建议至少每季度做一次真实恢复：从备份里还原一个文件、起一个临时库导入 .sql、对比差异。把"恢复步骤"写成文档，和备份脚本放一起。记住：能恢复，才叫备份；恢复不了，那只是你自我安慰的一堆字节。

八、常见翻车现场

汇总高频坑：只留一份本地备份（违反 3-2-1）；--delete 没演练就执行，误清空目标；直接拷数据库文件而非逻辑导出；仓库口令弄丢（borg/restic 无口令=永久不可恢复，务必存密码管理器）；备份了从不校验，位翻转累积到恢复时才发现。避开这些，你的数据才真正安全。

补充与延伸：备份的终极检验是"恢复"

业界有句老话：没演练过的备份等于没备份。太多人配好 rsync 或 borg 就以为高枕无忧，直到真的硬盘坏了，才发现要么目标盘也是同一块物理盘的另一个分区（一起完蛋），要么口令忘了打不开仓库，要么备份的是空目录。所以请务必定期做一次"从零恢复"演练：找台空闲机器，把备份还原出来，确认文件、数据库、权限都对。只有当恢复跑通过，那份备份才真正算数。这个动作看似多余，却是你在灾难面前唯一的底气。

再往深想，备份策略要和"业务能容忍什么"对齐。RPO（恢复点目标）决定你多久备一次——电商订单可能要实时复制到备库，个人博客每天一次就够了；RTO（恢复时间目标）决定你要多快的恢复手段——冷归档便宜但要几小时，热备贵却能分钟级拉起。先用这两个指标框定需求，再去选工具，就不会在"rsync 简单但占空间"和"restic 高效但要学"之间反复纠结。备份不是技术炫技，而是用最低成本买一份安心。

最后是一个心态提醒：备份最难的从来不是第一次设置，而是"长期坚持"。任务跑着跑着因为磁盘满、证书过期、网络变了而静默失败，是最常见的事。务必给备份任务配上失败告警（邮件或监控），并且每隔一段时间手动确认最新一份备份的日期。数据不会提醒你它快没了，提醒这件事，只能靠你自己设的护栏。把"验证备份有效"写进你的月度清单，它会在某天救你一命。

补充一个冷备份的性价比思路：对象存储（如 S3 兼容桶）是个人或小企业做异地备份的便宜选择。restic/borg 都能直接把仓库推到远端桶，每月几毛钱换一份"机房着火也不怕"的安心，比再买一台 VPS 实惠。配合生命周期规则把旧快照自动转冷存储，成本还能再降。异地不一定是另一座城市，只要是"和你的主数据不在同一故障域"就行。

还有一点：数据库备份别只靠文件拷贝。MySQL 要用 mysqldump 或 xtrabackup 做逻辑/物理导出，PostgreSQL 用 pg_dump，MongoDB 用 mongodump——这样得到的才是能直接还原的干净数据，而不是可能处于不一致状态的裸文件。把"先停写或加锁再拷"或"用官方 dump 工具"写进你的备份脚本，恢复时才不会傻眼。文件级备份适合代码和静态资源，数据库一定要走专用导出通道。

把备份当成你运维体系里最不起眼却最重要的一环。它平时默默无闻，只在灾难降临的那天证明自己的价值。今天花半小时把自动备份加好、演练一遍恢复，未来某个深夜你可能就会庆幸自己做了这件事。与其在丢数据后追悔，不如现在就把这道护栏焊死。