跨平台免费开源数据备份工具选型与恢复演练实战

数据备份这件事，干运维和开发十几年，我听过最多的一句话就是“我这些东西不重要，不用备”，然后紧接着就是硬盘掉盘、笔记本进水、误删目录之后的两天沉默。这篇东西不聊情怀，就是把 Windows、MacOS、Linux 三个平台上我实际用过、也确实能在 GitHub 上找到源码的免费开源数据备份工具挨个摊开讲一遍，顺带把选型逻辑、参数含义、定时策略、恢复演练这些平时文档里不太写的东西补上。无论你是刚买第一台笔记本的学生、只想给自己电脑做份保险的普通用户，还是手里管着几十台服务器、要给业务数据留后路的运维，下面的内容都能直接抄作业。

需要先说清楚的是，备份和同步是两件不同的事。同步负责让两个地方的内容保持一致，改错了会一起错；备份负责把某个时间点的状态固定下来，事后能倒回去。很多人的“备份方案”其实是同步盘，误删之后两边一起消失，这类惨案我见得太多了。所以第 1 节我会先把概念框架搭清楚，再进入工具环节，否则工具选得再花哨，方向错了照样白干。

1. 备份方案设计前必须先想明白的三件事

1.1 全量、增量、差异，三种策略到底怎么选

全量备份最直观，每一次都把选定的数据完整复制一份，恢复的时候拿最新那份直接用，不存在依赖链。它的代价是空间和时间线性增长，一个 500GB 的目录每周全备一次，一个月就是 2TB。差异备份是“上次全量之后变化的内容”，恢复需要“最近一次全量 + 最近一次差异”两份。增量备份是“上次任意一次备份之后变化的内容”，恢复时需要“最近一次全量 + 之后所有增量”，链条越长，中间任何一个文件坏掉，整条链就断了。

现代工具基本都走另一条路：基于内容分块的增量。Restic、Borg、Kopia、Duplicati 都是这个思路，把文件切成小块，算指纹，只有指纹没出现过的块才上传。这样既拿到了增量的体积优势，又不用维护依赖链，任意一次快照都能独立恢复。代价是首次备份之后要做一次完整的“索引重建”式扫描，几十万个小文件时这一步很慢，机械硬盘上跑几个小时很正常。

我自己的组合通常是：系统盘用快照类工具（Timeshift、Clonezilla）保证能整机回滚，个人和工作数据用内容分块类工具（Restic、Borg）做版本化，最后再加一层异地副本。三层各管一段，互不干扰。

1.2 3-2-1 原则，以及它在个人电脑上的落地版本

经典的 3-2-1 是：3 份数据副本，存放在 2 种不同介质上，其中 1 份在异地。对企业来说这是底线，对个人来说可以简化成“本机一份 + 移动硬盘一份 + 远端一份”。介质多样性的意义在于防同类故障，两台机器上都用同批次的某品牌固态，固件层面的问题可能同时爆发；一份放内置盘、一份放机械移动硬盘、一份放远端，故障模式就完全不同了。

“异地”这两个字很多人理解得太窄，以为必须跨城市。实际上只要不和你电脑处在同一物理空间就行，办公室抽屉里的硬盘、父母家的柜子、朋友家的书架上，都算。真正要防的是火灾、水浸、盗窃这类同时带走所有副本的事件，概率低但后果不可逆。

有一条经验值得单独说：不要把唯一副本放在同一台机器的另一个分区上。分区表损坏、整盘加密出问题、勒索软件加密所有可写卷，这三种情况会同时干掉 C 盘和 D 盘的备份。移动硬盘也不要在备份完成后一直插着，勒索软件扫盘的时候可不管你是备份盘还是数据盘，备份做完拔线是最土也最有效的隔离手段。

1.3 选工具前先回答四个问题

第一个问题：你要备份的是整机系统还是数据文件。整机回滚对工具的要求完全不同，需要处理引导记录、分区表、未使用空间，Clonezilla、Timeshift 这类才是正解，用文件级工具去恢复系统盘纯属自找麻烦。

第二个问题：目标端是什么。只有一块移动硬盘，和手上有对象存储、NAS、SFTP 服务器，能选的工具范围差很多。Restic、Kopia、Duplicati 对远端协议的支持非常宽，rsync 和 FreeFileSync 更偏向“点对点”。

第三个问题：能不能接受命令行。Borg 和 rsync 的核心体验在终端里，Duplicati、FreeFileSync、KopiaUI、Vorta 提供了图形界面，给不熟悉命令行的同事装机器，我一般直接上图形化工具，省掉后面一半的沟通成本。

第四个问题：恢复要多久，谁来做。备份方案的价值在恢复那一刻才兑现。如果你的方案需要写三条命令、装两个依赖、手动挂载才能恢复，那你在慌乱状态下大概率会出错。我现在的标准是：任何一套方案落地后，都要在非故障状态下完整演练一次恢复，把命令写成脚本存在备份盘根目录，文件名就叫restore-how-to.txt。

2. 十个工具逐一拆解：能力边界与适用场景

2.1 Restic：单文件二进制，跨三平台体验最统一

Restic 用 Go 写的，编译出来就是一个可执行文件，扔进 PATH 就能跑，不依赖运行时、不需要安装服务。仓库后端支持本地目录、SFTP、REST 服务端、S3 兼容存储、对象存储等一大票目标，同一套命令换个仓库地址就能换后端，这是它最舒服的地方。

它的设计里有两个点值得展开。一是加密是默认行为，不是可选项，仓库用 AES-256 加 Poly1305-AES 做认证加密，密码丢了数据就真的没了，这不是吓唬人。二是去重粒度是内容级的，用 Rabin 指纹做滚动分块，平均块大小在 1MB 上下，你把同一个文件复制到三个目录，仓库里只存一份。

适合谁：手上同时有 Windows 台式机、MacBook 和几台 Linux 服务器，希望用同一套命令和同一套心智模型管所有机器的人。它的快照模型（restic snapshots列出的是一个个时间点）对“我三天前那个版本还在不在”这类诉求特别友好。

一个坑要先讲：Restic 的缓存默认放在用户目录下，仓库大的时候这个缓存能长到几个 GB，MacBook 用户会看到“系统数据”莫名其妙膨胀。用--cache-dir指到别处，或者定期restic cache --cleanup清一下，能省不少空间。

2.2 BorgBackup：去重和压缩效率的标杆，但有平台限制

Borg 是 Python 生态里的老牌选手，去重、压缩、加密三件套都做得很扎实。压缩算法可以从 lz4、zstd、zlib、lzma 里选，文本和代码类数据用 zstd 能压到三成左右，日志类更高。加密支持 repokey 和 keyfile 两种模式，前者把密钥存在仓库里（用你的口令保护），后者单独存一份密钥文件，安全性更高但要多管一个文件。

Borg 的短板在平台。服务端基本只跑在类 Unix 系统上，Windows 上没有原生服务端，Windows 机器想用 Borg，要么在 WSL 里跑客户端连远端仓库，要么走 Cygwin。另外 Borg 的远程访问依赖 SSH 加borg serve，对没有 SSH 环境的纯家庭用户不算友好。

它还有个大杀器：borg mount可以把仓库挂载成 FUSE 文件系统，直接像浏览目录一样翻历史快照，找回单个文件的时候比解包快得多。Vorta 是它的图形前端，Linux 和 Mac 上都有，配好之后定时任务不用自己写。

2.3 Kopia：图形界面和策略管理做得最完整的后起之秀

Kopia 同样是 Go 写的，定位和 Restic 接近，但在“给人用”这件事上明显更用心。KopiaUI 提供了完整的图形界面，仓库创建、快照浏览、恢复、定时策略都在界面里配，不用记命令。命令行版本kopia也没落下，脚本化完全没问题。

它的策略系统是我见过最细的之一：可以按目录单独设置保留策略，比如“代码目录保留最近 30 天每小时快照”“照片目录保留每周快照一年”，还有全局的压缩、加密、忽略规则。仓库后端支持本地、SFTP、WebDAV、S3、B2、Azure、GCS，以及通过 rclone 接入更多目标。

kopia snapshot verify会按比例随机抽样校验块的可读性和哈希值，这在长时间运行的备份仓库里很有价值，因为静默损坏（磁盘没报错，但数据已经变了）是最难发现的问题。适合愿意花半小时配一次策略，然后长期不用管的用户。

2.4 Duplicati：浏览器界面最亲切，但要注意它的历史包袱

Duplicati 是 .NET 写的，跨平台，启动之后开一个本地 Web 界面（默认在本机 8200 端口），所有配置在浏览器里点。支持 AES-256 加密、增量、去重、多种远端后端，还能把备份配置导出成文件，方便在多台机器上批量部署。

它的优势是门槛低，装完点几下就能跑起来，对不熟悉命令行的用户非常友好。它还有个“测试恢复”的功能，能在备份之后自动验证一部分文件，这个设计挺好。

但有一个必须说的问题：Duplicati 2.0 长期处于测试版状态，社区里报告过本地数据库（SQLite）损坏导致备份集无法读取的案例，尤其在异常断电、进程被强杀之后。我的建议是，如果用 Duplicati，一定保证机器有稳定的供电，不要让备份进程被任务管理器强杀，并且在另一台机器上保留一份独立的方案作为兜底。别把唯一的备份交给单一工具。

2.5 rclone：云存储的万能瑞士军刀

严格来说 rclone 不是备份工具，是“把数据搬到各种存储”的通用工具，支持的对象存储和网盘协议数量大概是同类的几倍。它的核心命令是rclone copy和rclone sync，前者只增不减，后者会让目标端和源端完全一致，用错一个命令就会把远端备份删干净，这是新手最容易踩的坑。

针对备份场景，正确用法是做一层crypt加密 remote，套在目标存储外面，再配合rclone copy加--backup-dir参数。--backup-dir会把被覆盖或删除的文件挪到带日期的目录里，相当于给 sync 加了个回收站。这个参数我认为是 rclone 做备份时必须加的。

它还有个隐藏用法：rclone 可以作为 Restic 和 Kopia 的后端，也就是“本地仓库 + rclone 推送远端”的两段式结构。本地仓库负责快速备份和恢复，rclone 负责把仓库整体搬到远端，两段解耦，哪边出问题都不影响另一边。

2.6 rsync：二十年不过时的增量传输基石

rsync 的价值在于它的增量传输算法：把源文件分块算滚动校验和，和目标端比对，只传差异部分。跨网络传输大文件、只改了几 MB 的场景，它的效率到现在也没被超越。-a归档模式、-z压缩、--delete删除目标端多余文件、--exclude排除规则，这几个参数组合起来能覆盖八成日常需求。

用它做版本化快照有个经典技巧：--link-dest。把上一次快照目录作为参照，没变化的文件不复制实体，而是创建硬链接指向上一份。100 份快照的磁盘占用可能只比一份多一点，但每份看起来都是完整的目录树，随时能直接打开。Timeshift 的 RSYNC 模式本质上就是这个思路的产品化。

Windows 上 rsync 没有官方原生版本，习惯的做法是在 WSL 里跑，或者用 Grsync 这种 GTK 前端（Linux 为主）。Mac 自带 rsync，但版本偏老（2.6.9），需要新特性的话得自己装一份更新的。

2.7 Timeshift：Linux 系统回滚的第一选择

Timeshift 解决的是“系统被我改坏了想回到昨天”的问题，不是“我的文件丢了想找回来”。它支持 BTRFS 和 RSYNC 两种模式：BTRFS 模式依赖子卷快照，几乎瞬间完成、几乎不占额外空间；RSYNC 模式用硬链接快照，兼容性更好，任何文件系统都能用。

关键点在于它默认排除/home。很多人装完 Timeshift、配了定时任务，以为万事大吉，结果误删了主目录里的文档，打开快照一看什么都没有。要备份家目录得手动勾选，而且要注意家目录通常很大，硬链接快照对文件数量敏感，几十万小文件的话首次快照会跑很久。

我的用法是：Timeshift 只管系统盘，保留策略设为每天 3 份、每周 2 份、每月 1 份，配合 BTRFS 模式。数据文件交给 Restic。两者职责分开，恢复路径也清晰，系统坏了用 Live USB 启动跑 Timeshift 恢复，文件丢了用 Restic 挑单个快照恢复。

2.8 UrBackup：多机器集中管理的客户端服务端方案

UrBackup 是典型的 C/S 架构：一台机器装服务端，其他机器装客户端，服务端统一管理备份策略、查看状态、触发恢复。客户端覆盖 Windows、Linux、Mac。它有两种备份类型，文件备份（按目录备份，支持增量、去重、符号链接）和镜像备份（整卷镜像，Windows 上借助卷影复制服务，能拿到开机状态下的分区镜像）。

这个架构的价值在规模。家里三台电脑、公司二十台办公机，逐台配置备份策略是灾难，UrBackup 在服务端配一次策略，客户端装完自动注册、自动开始备份，状态一屏看完。它还支持“客户端主动拉取”模式，适合客户端在内网、服务端在另一侧的部署。

要注意的是镜像备份的兼容性：Windows 客户端上做整卷镜像需要卷影复制服务正常，Linux 上做镜像需要在客户端本机有足够权限。特别在意整机恢复的场景，我一般还是推荐 Clonezilla 这种离线方案，UrBackup 的镜像更适合“系统还能启动，但需要偶尔备一份”的日常场景。

2.9 FreeFileSync：图形界面里的同步与版本化利器

FreeFileSync 是跨平台的图形化文件同步工具，Windows、MacOS、Linux 都有包。它支持双向同步、镜像同步、更新同步三种模式，配好之后一键跑完，还有 RealTimeSync 组件可以监控目录变化自动触发同步。

它有个容易被忽略的功能：版本化备份。在同步设置里开启版本化，指定一个版本目录，被覆盖或删除的文件会自动挪进去，而不是直接消失。这就把“同步”变成了“带历史的同步”，虽然不如内容分块工具的版本管理精细，但对“误删了还能捞回来”这个核心诉求已经足够。

给非技术同事配电脑备份的时候，FreeFileSync 是我的首选之一：图形界面、中文、配置能存成文件、双击就跑。缺点是它不做去重，每次都是完整的文件级复制，硬盘占用增长比较快，适合数据量在几百 GB 以内的场景。

2.10 Clonezilla：整盘镜像和裸机恢复的终极手段

Clonezilla（再生龙）是一个基于 Linux 的启动环境，专门做磁盘和分区的镜像、克隆。它用 partclone 系列工具按文件系统识别已用块，只复制有效数据，NTFS、ext4、XFS、BTRFS、FAT 这些主流文件系统都支持，比 dd 全盘逐字节复制快得多、镜像也小得多。

它的使用方式是离线启动：做一个 U 盘启动盘，从 U 盘引导，选择“device-image”模式把整块盘存成镜像到外置硬盘或网络位置，或者选“device-device”模式直接两块盘对拷。想把整块系统盘克隆到外置硬盘或者大容量 U 盘，这就是最标准的做法，引导记录、分区表、隐藏分区一起带走，恢复之后开机就能用，不需要重装系统再倒数据。

用它的场景很明确：新机器到手先做一份原厂镜像、换硬盘前给旧盘做一份、系统要折腾之前留个后路。缺点是必须关机启动，没法在线备份，而且增量能力弱，大容量盘每次都是接近全量。我通常半年做一次整盘镜像，日常版本化交给 Restic。

3. 十个工具横向对比与场景匹配表

这张表只能给个大方向，实际选择还要看数据量和恢复窗口。举个具体例子：数据量 200GB、每天变化 2GB、要求当天能恢复。用 Restic 首次备份可能要两小时，之后每天十几分钟；用 FreeFileSync 每次都是完整比对，30 分钟左右，但没有历史版本管理。两种都能选，取决于你更在意“磁盘占用”还是“配置简单”。

4. 实操：用 Restic 搭一套跨三平台的备份流程

4.1 安装与仓库初始化

三平台装 Restic 都很快。Windows 上用包管理器最省事：

winget install restic.restic

Mac 上：

brew install restic

Debian 系 Linux 上：

sudo apt update && sudo apt install restic -y

装完第一件事是初始化仓库。仓库可以放在本地目录、外接硬盘、SFTP 或对象存储上，先拿外接硬盘练手：

export RESTIC_REPOSITORY=/mnt/backup-drive/restic-repo export RESTIC_PASSWORD_FILE=/root/.restic-pass restic init

注意：RESTIC_PASSWORD_FILE指向的密码文件权限要设成 600，并且和仓库分开存放。仓库和密码放同一块盘上，等于把保险柜和钥匙一起丢了。

初始化只需要做一次。如果仓库已经存在，重复执行init会报错退出，这是好事，说明它不会覆盖已有数据。仓库目录里会看到config、data、index、keys、snapshots几个子目录，data是真正存块的地方，snapshots存的是每次快照的元信息。

4.2 首次全量备份与排除规则

首次备份最容易出问题的地方是排除规则没写好，把缓存、临时文件、虚拟机镜像一起塞进去了，仓库体积瞬间膨胀。Restic 支持从文件读取排除规则：

cat > /etc/restic-exclude.txt <<'EOF' /home/*/.cache /home/*/.local/share/Trash /var/cache /var/tmp /home/*/node_modules /home/*/.gradle/caches /home/*/.docker EOF

然后执行首次备份：

restic backup /home /etc \ --exclude-file=/etc/restic-exclude.txt \ --exclude-caches \ --tag daily \ --verbose

--exclude-caches会识别并跳过带有缓存标记的目录，比自己一条条写规则省事。--tag给这次快照打标签，后面按标签筛选和保留策略时很有用。

首次备份完之后，第二天的备份只会传变化的部分，速度会快很多。判断增量效果可以对比两次备份的输出里 “Files: x new, y changed, z unmodified” 这几行，如果每次都显示大量 new，说明排除规则没生效。

4.3 保留策略与空间回收

Restic 不会自动清理旧快照，需要显式指定保留规则。常见的组合是保留最近 7 天每天一份、最近 4 周每周一份、最近 6 个月每月一份、每年一份：

restic forget \ --keep-daily 7 \ --keep-weekly 4 \ --keep-monthly 6 \ --keep-yearly 1 \ --prune

forget只是删除快照记录，--prune才会真正回收不用的数据块，这一步比较慢，几十 GB 的仓库可能跑十几分钟。不要在每次备份后都执行 prune，数据块频繁删了又写会降低去重效果，也增加磁盘压力。我的做法是每天备份、每周 prune 一次。

想知道空间回收的效果，用restic stats --mode raw-data看原始数据量，和du -sh看实际占用对比，差距就是去重带来的收益。

4.4 三平台的定时任务写法

Linux 上用 systemd timer 最干净。先写服务单元：

# /etc/systemd/system/restic-backup.service [Unit] Description=Restic backup [Service] Type=oneshot Environment=RESTIC_REPOSITORY=/mnt/backup-drive/restic-repo Environment=RESTIC_PASSWORD_FILE=/root/.restic-pass ExecStart=/usr/bin/restic backup /home /etc --exclude-file=/etc/restic-exclude.txt --tag daily ExecStartPost=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6

再写一个 timer 每天凌晨两点触发：

# /etc/systemd/system/restic-backup.timer [Unit] Description=Run restic backup daily [Timer] OnCalendar=*-*-* 02:00:00 Persistent=true [Install] WantedBy=timers.target

Persistent=true很关键，它保证机器关机错过时间点之后，开机时会补跑一次。

Mac 上用 launchd，把 plist 放到~/Library/LaunchAgents/下，StartCalendarInterval指定时间，ProgramArguments里写命令和参数。Windows 上用任务计划程序，触发器设置为每天，操作用powershell.exe调一个装好环境变量的脚本。三平台思路一样：环境变量写死在脚本里，不要依赖登录用户的 profile。

4.5 校验与恢复演练

restic check分两档：默认只校验仓库结构和元数据，加--read-data-subset=5%会抽样读取一部分数据块做哈希校验。建议每月跑一次抽样校验，仓库大的话用 1% 到 5% 的比例平衡时间和覆盖度。

恢复演练是整套流程里最容易被跳过、也最不该跳过的一步。找一个空目录，恢复一个快照里的单个文件：

restic snapshots --tag daily restic restore latest --target /tmp/restore-test --include /home/user/docs/report.xlsx

--include支持路径匹配，恢复单个文件不用把整个快照展开。恢复完之后打开文件确认内容完整，这一步花五分钟，能帮你发现“密码不对”“排除规则把重要目录误杀”这类致命问题。

5. 大容量场景：Clonezilla 做整盘镜像与裸机恢复

5.1 启动盘制作与镜像存储位置选择

Clonezilla Live 的镜像可以从项目发布页下载，写 U 盘用 Rufus（Windows）、balenaEtcher（三平台都行）或dd。U 盘容量不用大，2GB 足够，但注意写入会清空 U 盘。

从 U 盘启动进入菜单后，第一步是选语言和键盘布局，然后是“start Clonezilla”进入主流程。存储位置有几个选项：本地外接硬盘、SSH 服务器、Samba 共享、NFS。个人场景我建议直接接一块容量大于源盘已用空间的移动硬盘，最省事，不依赖网络。

容量计算要提前做。镜像大小约等于源盘的“已用空间”乘以压缩率，Clonezilla 对 NTFS 和 ext4 的压缩率大致在 0.5 到 0.7 之间。一块 1TB 的盘用了 400GB，压缩后大概 200 到 280GB，移动硬盘留足一倍余量比较稳。

5.2 镜像过程的两个关键选择

走到“选择模式”这一步时有几组选项要留意。第一组是device-image还是device-device，前者生成镜像文件，后者两块盘直接对拷，做换盘迁移时后者更快，做归档时前者更合适。

第二组是savedisk（整盘）还是saveparts（单个分区）。整盘会把引导记录、EFI 分区、恢复分区一起打包，恢复之后直接能开机；单分区只保存指定分区的内容，恢复后需要自己修复引导。没有特殊理由一律选整盘，多占的那点空间和少折腾的时间比起来不值一提。

第三组是压缩方式和分卷大小。默认的gzip兼容性最好，-z1速度最快压缩比最低，-z9反过来。镜像要放到 FAT32 格式的移动硬盘上时，单文件不能超过 4GB，需要在高级选项里设置分卷大小，比如 4096MB，让它自动切分。这个坑我踩过一次，跑到 80% 报错退出，白等两个小时。

5.3 恢复时的注意事项

恢复流程和备份类似，选restoredisk或restoreparts，指定镜像目录和目标盘。有两个点要特别注意。

一是目标盘容量必须大于等于源盘，哪怕已用空间很小也不行，因为要还原分区表。换到更大容量的盘没问题，换到更小的盘会直接失败。

二是恢复之后第一次开机可能遇到引导问题。UEFI 机器上，如果原来用的是 Windows 引导管理器，恢复后一般能正常启动；如果是双系统，可能需要进 BIOS 重新指定启动项，或者用启动修复工具处理一遍。恢复完成后先别急着格式化移动硬盘，等确认系统能正常开机、数据都在，再清理镜像。

6. 常见问题与排查技巧实录

6.1 备份速度慢得离谱

最常见的三个原因：小文件太多、机械硬盘随机读写瓶颈、目标端网络延迟高。几十万个小于 10KB 的文件，任何内容分块工具都跑不快，因为主要时间花在元数据操作上。这种情况下先用tar打包再备份会快很多，代价是恢复单个文件要先解包。

机械硬盘上做首次备份，几百 GB 跑一整夜很正常。判断瓶颈位置的方法是看系统资源监视：磁盘队列长度长期满载说明是本地 IO 瓶颈，网络吞吐打满说明是网络瓶颈，CPU 占用高说明压缩算法太重，把 lzma 换成 zstd 或 lz4 能立竿见影。

提示：备份任务不要和虚拟机、大型编译、视频渲染抢资源。把备份时间安排在凌晨，或者临时调低进程优先级，能避免很多“备份跑一半被拖死”的情况。

6.2 权限、符号链接、长路径这几类错误

Linux 上备份系统目录时，权限错误是高频问题。普通用户读不了/etc下某些文件，备份会打印一堆 warning。解决办法是用 root 跑，但要确认备份仓库目录的权限也设置正确，否则 root 创建的仓库普通用户读不了。

符号链接的处理各家不同。Restic 默认把符号链接本身存下来（存的是链接目标路径），不跟随。如果你的数据里有链接到别处的大目录，需要显式加--follow之类的参数，不然备份出来是个空链接，恢复时指向一个不存在的位置。

Windows 上的长路径问题至今还在。路径超过 260 字符时，部分工具会直接失败。排查方式是看日志里有没有 “path too long” 或者 “cannot open” 后面跟着一长串路径。解法一般是开启系统的长路径支持，或者让备份工具用\\?\前缀的路径写法，具体看工具文档。

6.3 备份出来的数据不一致

数据库文件、虚拟机磁盘、正在运行的容器卷，这几类数据是典型的“热文件”，备份过程中还在被写入，抓到的快照是撕裂的。Restic、Borg 这类工具都提供了一致性机制：Restic 在 Linux 上可以用--use-fs-snapshot调用 LVM 或 BTRFS 快照，Windows 上 Duplicati 和 UrBackup 会用卷影复制服务。

虚拟机磁盘最省事的做法是备份前先关机或做一次快照，把快照文件备份走。数据库的话，导出成逻辑备份再备，虽然慢但一致。这个原则可以概括成：备份的是文件，但要求一致性的东西必须用它们自己的机制产出快照。

6.4 常见问题速查表

7. 我踩过的坑和几条硬经验

第一条，不要把备份脚本放在被备份的目录里。有一次我把脚本放在家目录下的scripts文件夹，然后某次清理误删了整个目录，脚本和备份数据一起没了。现在所有备份脚本统一放在/opt/backup-tools或者系统盘之外的位置，另外单独复制一份到备份仓库根目录。

第二条，备份日志要留，但不要无限增长。日志能帮你发现问题，比如“每周三的备份都比平时慢一倍”这种异常。但如果日志写进被备份的目录，而且每天几 MB，一年就是一两 GB 的无用数据。我现在的做法是把日志写到/var/log/backup/，用 logrotate 保留 30 天，并且这个目录在排除列表里。

第三条，验证的频率要高于备份的频率的预期。备份每天跑，验证每月跑一次，这个比例比较合理。验证包括三件事：抽查数据块哈希、随机恢复一个文件并打开、确认保留策略符合预期。第三件事经常被忽略，有人配了--keep-daily 7，结果一周之后发现只剩 7 份，想找一个月前的版本，早就被清理了。

第四条，密码管理要比数据本身更上心。加密仓库的密码丢了，工具帮不了你，任何恢复服务也帮不了你，因为密钥不在服务商手上。我的做法是：密码写在纸上锁进抽屉，同时用密码管理器存一份，再确保有一位可信任的人知道密码放在哪里。听起来夸张，但数据全丢的那一刻，这几种冗余都是有意义的。

第五条，恢复路径要短。理想状态下，任何一份备份都能在 30 分钟内恢复出关键文件，不需要现场装软件、查文档、回忆参数。如果你的方案做不到，就该考虑简化。工具的选择上，能在图形界面里点几下恢复的（KopiaUI、FreeFileSync、Duplicati），比需要敲三条命令的，在紧急情况下成功率更高。

第六条，别指望单一工具覆盖所有需求。整机回滚、文件版本化、异地副本，这三件事的性质不同，用同一个工具硬扛通常会在某个维度上妥协。我的组合是 Clonezilla 做半年度整盘镜像、Restic 做每日文件版本化、rclone 把仓库推到远端做异地副本。三层各自的恢复路径独立，任何一层出问题都不至于全军覆没。

还有个小技巧顺手提一下：备份硬盘的目录结构最好按“工具名/机器名/日期”组织，恢复的时候一眼能找到对应的仓库，不用翻配置文件确认哪个目录是哪台机器的。这种命名规范看起来不起眼，但等你手上有五六块备份盘、七八台机器的时候，能省下大量猜测的时间。