这篇指南带你完整跑通 Restic 的增量备份（一种只备份变更数据的备份方式）流程：从安装、初始化加密仓库、执行去重备份，到最重要的恢复验证，全程给出可以直接复制的命令。很多管理员备份做到”能出快照”就停了，真正灾难来临时才发现恢复不了，而 Restic 的价值恰恰在于既节省存储，又能可靠恢复。
如果你的网站或业务跑在 Hostease 的 [VPS](https://cn.hostease.com/vps/)（[虚拟专用服务器](https://cn.hostease.com/vps/)，一种通过虚拟化技术划分出独立资源的服务器实例）或[独立服务器](https://cn.hostease.com/dedicated-server/)上，数据库、上传目录、配置文件都是需要保护的资产。Restic 是跨平台的开源备份工具，支持本地目录、SFTP、S3、对象存储等多种后端，适合作为中小企业的第一套可靠备份方案。
一、为什么增量备份需要专门工具
传统做法是把整个目录打包成 tar.gz，每天定时跑一次。缺点很明显：每天都要遍历全部文件，占用大量 CPU 和磁盘；重复数据被反复存储，备份体积快速增长；加密和校验也要自己手工处理。Restic 采用内容寻址存储（一种根据数据内容计算指纹来定位文件的存储方式），把文件切成固定大小的数据块，每个块用哈希值作为唯一标识。备份时只上传不存在的块，这就是去重（deduplication），首次全量备份后，后续增量备份通常只占用很小空间。
举个例子：一个 50GB 的站点目录，首次全量备份写入 50GB，之后每天只改几个配置文件、新增少量上传文件，当天的增量备份可能只有几百 MB 甚至更小。这样的效率是传统 tar 方案无法比拟的，也意味着你可以把备份频率从”每周”提高到”每小时”而不用担心存储成本。
增量备份的另一个关键点是快照管理。Restic 用 snapshot（快照，某一次备份的完整时间点状态）概念记录每次备份，每个快照都指向完整的文件树，恢复时可以精确回到任意时间点，而不是像传统方式那样要连续解压多次增量包再拼接。
二、安装 Restic 并初始化仓库
以 Ubuntu 22.04 / 24.04 为例，用系统包管理器安装即可，官方仓库版本通常足够新。
sudo apt update sudo apt install -y restic restic version # 确认安装成功，例如 restic 0.16.4 compiled with go1.21
如果你的发行版包版本太旧，可以到 Restic 官方 GitHub Release 页面下载二进制包，解压后放到 /usr/local/bin 并赋予执行权限。安装完成后先初始化仓库。仓库（repository）是 Restic 存储备份数据的存储位置，初始化时需要设置一个加密密码。
mkdir -p /backup/restic-repo restic init --repo /backup/restic-repo # 首次执行会提示设置 repository password（仓库密码），务必妥善保存
这里会提示你两次输入密码。这个密码用于加密仓库数据，丢失之后即使仓库文件还在也无法恢复任何数据，所以一定要用密码管理器保存，或写入受权限保护的密码文件。更安全的做法是把密码放到一个只有备份用户可读的文件里，避免每次交互输入，也方便后续 cron 自动化。
umask 077 echo '你的-强-仓库-密码' > /etc/restic-pw chmod 600 /etc/restic-pw # 密码文件权限只允许 root 读写，避免被其他用户读取
初始化后可以用 restic snapshots 查看当前空仓库，确认没有异常。仓库目录的访问控制也要收紧，避免无关进程或用户读取。如果你有多台服务器共享一个备份节点，建议参考 SSH 访问控制审计来限制登录和密钥权限，防止备份仓库成为攻击入口。
三、配置排除规则并执行首次全量备份
备份前要明确”什么需要备份、什么不该备份”。临时文件、缓存、日志、以及备份仓库自身通常都要排除，否则会白白浪费存储并污染快照。Restic 通过 –exclude 参数和排除文件实现。
restic --repo /backup/restic-repo --password-file /etc/restic-pw backup /var/www \ --exclude='*.log' \ --exclude='/var/www/cache' \ --exclude='/var/www/tmp' \ --exclude-caches \ --verbose # --exclude-caches 跳过 .cache 目录，--verbose 显示每个文件的处理进度
这里备份了 /var/www 目录，排除了日志、缓存和临时文件。如果目录里文件非常多，可以把排除规则写到单独文件里，用 –exclude-file 引用，方便维护。首次备份是全量，会遍历所有文件并分块存储，耗时取决于数据量和磁盘速度。
除了目录，MySQL 或 MariaDB 这类数据库不能简单备份数据目录，因为备份期间可能有写入导致数据不一致。正确做法是先导出 SQL 再备份导出文件，或者用专业工具做一致性的数据库快照。数据库的一致性问题如果处理不当，恢复时会遇到复制延迟或数据丢失，相关内容可以参考 MariaDB 复制延迟排查，提前理解一致性和复制机制有助于设计正确的备份策略。
四、增量备份与去重验证
第一次备份完成后，后续备份就是增量。同样一条 backup 命令，Restic 会自动识别未变化的块并跳过，只存储新增或修改的部分。你不需要手动指定”增量模式”，工具默认就是这样工作。
restic --repo /backup/restic-repo --password-file /etc/restic-pw backup /var/www \ --exclude='*.log' --exclude-caches # 第二次及以后执行就是增量备份，只上传变化的块 restic --repo /backup/restic-repo --password-file /etc/restic-pw snapshots # 列出所有快照，确认每次备份都生成新的 snapshot ID restic --repo /backup/restic-repo --password-file /etc/restic-pw stats --mode restore-size # 查看仓库内数据总量与去重后的实际占用，验证去重效果
restic stats 是验证去重效果最直观的方式。–mode restore-size 显示如果完全恢复需要多少数据，另一个输出会显示仓库实际存储大小，两者差距越大说明去重越有效。
如上图所示，首次全量备份后，后续每次增量备份只处理发生变化的块。增量备份的执行效率还受[服务器性能](https://cn.hostease.com/blog/server/)影响，如果站点访问量高、进程占用高，备份可能拖慢业务。此时可以结合 PHP-FPM 性能调优或 Nginx 限流配置优化服务器负载，给备份任务留出稳定资源。
去重是 Restic 增量备份的核心优势，但要注意：去重只在同一个仓库内生效。如果你为不同服务器建立了独立仓库，它们之间无法共享去重数据。建议把多台服务器的备份规划到合适粒度，既方便管理又能最大化去重收益。
五、加密与仓库安全配置
Restic 仓库默认全程加密，包括数据块、文件名、目录结构，都是经过 AES-256 加密的，密钥由仓库密码派生。这意味着即使仓库文件被窃取，没有密码也无法还原内容，这对存放敏感数据的备份尤为重要。
除了加密，还可以通过环境变量 RESTIC_REPOSITORY 和 RESTIC_PASSWORD_FILE 简化命令输入，减少密码在命令行残留的风险。
export RESTIC_REPOSITORY=/backup/restic-repo export RESTIC_PASSWORD_FILE=/etc/restic-pw restic snapshots # 设置环境变量后，后续命令无需重复指定 --repo 和 --password-file
仓库安全还有几件必须做：定期更换访问密码、对仓库所在主机做权限隔离、避免把备份密钥和仓库放在同一台可能被入侵的机器上。如果你把备份放到远程对象存储或另一台服务器，传输和访问控制同样要收紧，这部分可以参考前面提到的 SSH 访问控制审计。加密配置本身并不复杂，麻烦的是”把密钥弄丢”，所以务必建立密钥的异地备份机制。
六、恢复验证：备份最重要的一步
备份的价值只有通过恢复演练才能确认。很多管理员从不做恢复测试，直到故障发生才发现备份文件损坏或命令写错。Restic 提供了几种恢复方式，最简单的是直接恢复到目录。
restic --repo /backup/restic-repo --password-file /etc/restic-pw restore latest \ --target /mnt/restore-test # 将最新快照恢复到 /mnt/restore-test 目录 restic --repo /backup/restic-repo --password-file /etc/restic-pw restore\ --target /mnt/restore-test --path /var/www/uploads # 指定快照 ID 和路径，只恢复 uploads 目录
恢复前建议先校验仓库完整性，用 check 命令扫描所有数据块并验证哈希，提前发现损坏。
restic --repo /backup/restic-repo --password-file /etc/restic-pw check # 校验仓库完整性，返回 no errors were found 表示正常
上图展示了从加密快照恢复为可验证数据文件的完整路径：先校验仓库，再恢复到测试目录，最后核对文件完整性。对于数据库备份，恢复后还要验证 SQL 能正确导入、数据完整。
如果业务依赖 Redis 缓存，恢复时要注意缓存数据与数据库的一致性，避免恢复出”数据库是旧数据、缓存却是新数据”的错位，相关内容可以参考 Redis 持久化与恢复。恢复演练应该形成固定流程：每月至少完整恢复一次到测试目录，核对关键文件是否齐全、服务能否正常启动。做一次成功的恢复演练，比备份一百次不验证更有价值。
七、定时备份与保留策略
手工执行备份不可靠，要交给 cron 或 systemd timer 自动化。同时要用保留策略（retention policy）控制快照数量，避免仓库无限膨胀。
30 2 * * * export RESTIC_REPOSITORY=/backup/restic-repo RESTIC_PASSWORD_FILE=/etc/restic-pw && \ restic backup /var/www --exclude='*.log' --exclude-caches && \ restic forget --keep-hourly 24 --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune # 每天 02:30 备份，然后保留 24 个每小时、7 个每日、4 个每周、6 个每月快照并清理旧数据
restic forget 控制保留策略，–prune 参数会真正删除被遗忘快照对应的数据块并释放空间。定时任务要把输出重定向到日志文件，方便排查失败原因。设置好之后至少观察两轮，确认备份确实生成、forget 确实清理了旧快照。数据库备份可以在这个基础上增加导出步骤，先导出再备份，保证一致性。
总结
Restic 增量备份的核心收益是去重节省存储、内置加密保证安全、快照机制支持任意时间点恢复。正确落地要记住四个要点：第一，用内容寻址的去重设计取代传统整目录打包；第二，配置好排除规则并初始化加密仓库；第三，坚持自动化定时备份并执行保留策略；第四，也是最重要的，定期做恢复演练验证备份可用。对于 Hostease 上的业务站点，一套配置正确的 Restic 备份能让你在服务器故障、误删或勒索软件攻击时快速恢复数据，把业务中断的影响降到最低。