多 VPS 企业级备份实践：1Panel + Rsync + Restic 的稳定架构设计

很多站长在刚开始维护服务器时，备份方案往往很简单：面板里创建一个计划任务，定时把网站和数据库打包，然后上传到远端服务器或对象存储。

这套方式在单台 VPS、小体积网站场景下基本够用。但一旦进入更真实的生产环境，问题就会逐渐暴露出来：

• 多台 VPS 分布在不同国家、不同机房；
• 数据库和网站附件越来越大；
• 跨国网络不稳定，传输经常中断；
• 小硬盘 VPS 本地空间有限；
• 既想保留历史版本，又不想存储空间爆炸；
• 发生故障时，希望能快速定位并恢复某一天、某一台机器的数据。

这时，如果继续依赖面板自带的远程上传，很容易遇到任务卡死、传输失败、本地磁盘被撑爆等问题。

我更推荐一种拆分式备份架构：1Panel 只负责本地打包，Rsync 负责稳定传输，Restic 负责去重、加密和历史快照管理。

这套方案的思路很朴素，但非常可靠：

让每个工具只做自己最擅长的事，而不是把所有压力都堆给面板。

一、整体架构：前端打包、管道传输、后端入库

这套备份架构可以拆成三个部分。

1. 前端：各台生产 VPS

生产 VPS 上的 1Panel 只做一件事：

在本地完成网站和数据库备份打包。

它不负责跨国上传，不走远程 SFTP，也不直接连接对象存储。

这样做的好处很明显：

• 数据库导出由 1Panel 处理，更贴近业务；
• 本地打包速度快，不依赖网络；
• 不会因为跨国网络波动导致面板任务卡死；
• 本地只保留 1 份临时备份，减少磁盘压力。

2. 管道：Rsync 负责传输

1Panel 打包完成后，再由 Rsync 把备份包推送到 OVH 这类大容量服务器。

Rsync 的优势在于：

• 支持断点续传；
• 支持压缩传输；
• 适合跨国、跨机房弱网络；
• 传输成功后可以自动清理本地备份包；
• 可以额外同步自定义目录，比如 /etc/nginx、脚本目录等。

3. 后端：OVH 作为备份大脑

OVH 服务器负责最终处理：

• 接收各台 VPS 发来的备份数据；
• 自动解压 1Panel 的 .tar.gz 包；
• 合并自定义散装目录；
• 保留最新一份明文镜像，方便日常查看；
• 使用 Restic 进行块级去重、加密和快照入库；
• 按策略自动清理历史快照。

最终的数据流大致如下：

生产 VPS
  |
  | 1Panel 本地打包
  v
/opt/1panel/backup/
  |
  | Rsync 稳定传输
  v
OVH: /data/backup/1panel_incoming/机器名/
  |
  | 自动解压 + 合并散装目录
  v
OVH: /data/backup/1panel_unpacked/机器名/
  |
  | Restic 去重加密入库
  v
OVH: /data/restic-repo

这套架构特别适合多台 VPS 汇聚到一台大容量服务器统一备份的场景。

二、为什么要保留一份最新明文镜像？

很多备份方案只强调“归档”，但忽略了日常维护中的一个真实需求：

有时候我并不是要做灾难恢复，只是想快速看一眼昨天的配置文件、数据库包或网站目录。

如果所有数据都进入 Restic 仓库，当然也能恢复，但每次都要查快照、restore 或 mount，对日常查看来说略显麻烦。

因此，这套方案在 OVH 上额外保留一份最新的明文解压区：

/data/backup/1panel_unpacked/机器名/

它的特点是：

• 每台 VPS 对应一个目录；
• 每天新备份进来前会清空旧内容；
• 然后重新解压、合并最新数据；
• 入库 Restic 后不删除这份明文；
• 第二天新备份流入时再刷新。

也就是说，它不是长期历史仓库，而是一份最新状态镜像。

真正的历史版本由 Restic 负责；
日常快速查看由明文解压区负责。

这个设计在实际使用中很舒服：
需要严肃恢复时找 Restic，需要顺手看文件时直接进解压区。

三、第一阶段：环境准备与 SSH 保活配置

下面以 Debian / Ubuntu 系统为例。

1. 所有服务器安装 Rsync

生产 VPS 和 OVH 都需要安装 Rsync：

sudo apt update && sudo apt install rsync -y

2. 仅 OVH 安装 Restic

Restic 只需要安装在后端备份服务器，也就是 OVH 上：

sudo apt install restic -y

3. 优化 SSH 保活，减少大文件传输断流

跨国传输大文件时，SSH 连接偶尔会因为网络抖动、NAT 超时或运营商链路问题断开。

可以适当增加 SSH 心跳配置。

服务端配置：/etc/ssh/sshd_config

在所有服务器上编辑：

sudo nano /etc/ssh/sshd_config

添加或修改：

ClientAliveInterval 30
ClientAliveCountMax 60

含义是：服务端每 30 秒向客户端发送一次心跳，最多允许 60 次无响应。

客户端配置：/etc/ssh/ssh_config

继续编辑：

sudo nano /etc/ssh/ssh_config

添加或修改：

ServerAliveInterval 30
ServerAliveCountMax 60

含义是：客户端每 30 秒向服务端发送一次心跳，最多允许 60 次无响应。

修改后重启 SSH：

sudo systemctl restart sshd

注意：不同系统的 SSH 服务名可能是 ssh 而不是 sshd，如果重启失败，可以尝试：

sudo systemctl restart ssh

4. 建立生产 VPS 到 OVH 的 SSH 免密信任

在每台生产 VPS 上执行：

ssh-keygen -t ed25519

一路回车即可。

然后把公钥分发到 OVH：

ssh-copy-id -p 22 root@你的OVH_IP

测试免密登录：

ssh -p 22 root@你的OVH_IP "echo '免密成功'"

如果不需要输入密码，并正常输出：

免密成功

说明配置完成。

生产环境建议使用专门的备份用户，并通过权限控制限制可访问目录。本文为了说明流程，示例使用 root。

四、第二阶段：生产 VPS / 1Panel 发货端配置

1. 在 1Panel 创建本地备份任务

进入 1Panel 后台：

计划任务 -> 创建备份任务

可以按需选择备份网站、数据库等。

建议配置如下：

• 备份账号：不要勾选第三方备份账号，只使用本地；
• 执行周期：凌晨业务低谷，例如 02:00；
• 保留份数：1 份即可。

这里的重点是：1Panel 不负责远程传输。

它只需要把网站和数据库可靠地打包到本地，例如：

/opt/1panel/backup/

后续传输交给 Rsync。

五、Rsync 多目录传输脚本：一个重要的安全细节

原始思路是：通过 Rsync 数组脚本，把 1Panel 备份包和自定义目录一起传到 OVH，并在传输完成后删除本地包。

这个方向是对的，但这里有一个很容易踩坑的地方：

--remove-source-files 会删除源端文件。
如果你把 /etc/nginx、/root/my_custom_scripts 这类真实生产目录也放进去，并同时使用 --remove-source-files，就可能把生产服务器上的配置文件或脚本删掉。

所以更稳妥的做法是：

• 对 1Panel 备份目录 使用 --remove-source-files，传完删除本地备份包；
• 对 自定义散装目录 只同步，不删除源文件。

下面给出一个更安全的版本。

2. 在 1Panel 中添加 Shell 脚本任务

进入：

1Panel -> 计划任务 -> 添加计划任务 -> Shell 脚本

执行时间建议设置在 1Panel 本地打包完成后 10 分钟，例如：

02:10

脚本如下：

3. 路径斜杠的区别

Rsync 中路径末尾是否带 / 很重要。

例如：

rsync -av /etc/nginx root@server:/backup/

会得到：

/backup/nginx/...

而：

rsync -av /etc/nginx/ root@server:/backup/

会得到：

/backup/...

也就是说：

• 不加斜杠：连同目录本身一起传；
• 加斜杠：只传目录里面的内容。

在本文场景中，自定义目录建议不加斜杠，这样在 OVH 端可以保持清晰结构。

六、第三阶段：OVH 接收端初始化

1. 创建基础目录

登录 OVH 后执行：

mkdir -p /data/backup/1panel_incoming
mkdir -p /data/backup/1panel_unpacked
mkdir -p /data/restic-repo

目录说明：

路径	用途
/data/backup/1panel_incoming	接收各 VPS 传来的原始备份包和散装目录
/data/backup/1panel_unpacked	解压和合并后的最新明文镜像
/data/restic-repo	Restic 加密去重仓库

2. 初始化 Restic 仓库

执行：

restic init -r /data/restic-repo

初始化时会要求设置仓库密码。

这个密码一定要妥善保存。Restic 仓库默认加密，如果密码丢失，即使数据还在，也基本无法恢复。

建议至少保存到：

• 密码管理器；
• 离线备份介质；
• 团队项目中至少两位负责人可访问的位置。

七、部署 OVH 多 VPS 自动入库脚本

在 OVH 上创建脚本：

nano /root/restic_backup.sh

写入以下内容：

赋予执行权限：

chmod +x /root/restic_backup.sh

八、这个 OVH 脚本的关键逻辑

这段脚本的设计重点有三个。

1. 自动识别多台 VPS

它会遍历：

/data/backup/1panel_incoming/

下面的每一个子目录。

例如：

/data/backup/1panel_incoming/crunchbits/
/data/backup/1panel_incoming/tokyo-web01/
/data/backup/1panel_incoming/us-db01/

每个目录名都会被作为 VPS 名称，并写入 Restic tag。

也就是说，未来你新增一台 VPS，只需要让它把数据传到：

/data/backup/1panel_incoming/新机器名/

OVH 脚本不需要额外改逻辑。

2. 解压 1Panel 包，合并散装目录

脚本会先处理 .tar.gz 文件：

tar -xzf "$file" -C "$vps_unpack_dir"

然后再把散装目录同步进去。

最终在解压区形成一份完整的最新镜像：

/data/backup/1panel_unpacked/crunchbits/

这里面可能同时包含：

• 1Panel 网站备份；
• 数据库 SQL 文件；
• /etc/nginx 配置；
• 自定义脚本；
• 其他你指定同步的文件。

3. 明文区保留最新一份，Restic 保留历史版本

入库命令是：

restic backup "$vps_unpack_dir" --tag "$vps_name"

入库完成后，不删除：

/data/backup/1panel_unpacked/机器名/

这样你随时可以直接查看最新文件。

但是历史版本并不会依赖这个目录，而是由 Restic 的快照系统管理。

九、配置 OVH 定时任务

编辑 crontab：

crontab -e

在底部添加：

0 4 * * * /root/restic_backup.sh >> /var/log/restic_daily.log 2>&1

建议时间设置在凌晨 04:00，是因为：

• 1Panel 可以在 02:00 开始打包；
• Rsync 可以在 02:10 开始传输；
• 给跨国传输留出足够时间；
• OVH 到 04:00 再统一解压入库。

当然，如果你的网站体积较大，或者 VPS 所在地区到 OVH 网络较慢，可以把 OVH 入库时间再延后。

十、Restic 保留策略：控制历史版本与空间占用

脚本中使用了这一行：

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

含义是：

• 保留最近 7 个每日快照；
• 保留最近 4 个每周快照；
• 保留最近 6 个每月快照；
• 清理不再被快照引用的数据块。

这是一套比较适合个人站、小型业务和多 VPS 环境的折中策略。

如果你的业务更重要，可以调整为：

restic forget --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune

不过要注意，保留周期越长，占用空间越多。
好在 Restic 是块级去重，重复文件不会每次完整存一份，所以比传统全量备份节省得多。

十一、灾难恢复：真正决定备份价值的部分

备份系统最怕的不是配置复杂，而是你从来没有恢复过。

真正可靠的备份方案，一定要能清楚回答这几个问题：

• 我有哪些历史快照？
• 某一台 VPS 的快照在哪里？
• 能不能恢复到某一天？
• 能不能只找回一个文件？
• 数据库 SQL 能不能正常导入？

下面所有操作都在 OVH 上执行。

十二、查看历史备份快照

先设置 Restic 密码：

export RESTIC_PASSWORD="你的RESTIC仓库密码"

查看全库所有快照：

restic -r /data/restic-repo snapshots

只查看某台 VPS，例如 crunchbits：

restic -r /data/restic-repo snapshots --tag crunchbits

你会看到类似这样的输出：

ID        Time                 Host        Tags
-----------------------------------------------------
a1b2c3d4  2025-01-01 04:00:01  ovh         crunchbits
e5f6g7h8  2025-01-02 04:00:01  ovh         crunchbits

其中 ID 就是后续恢复时要用的快照编号。

十三、恢复某一天的完整备份

假设你要恢复快照：

a1b2c3d4

先创建恢复目录：

mkdir -p /tmp/restore_zone

执行恢复：

export RESTIC_PASSWORD="你的RESTIC仓库密码"

restic -r /data/restic-repo restore a1b2c3d4 --target /tmp/restore_zone

恢复完成后，可以进入：

cd /tmp/restore_zone

根据目录结构找到网站文件、数据库 SQL 或配置文件。

之后可以：

• 通过 SFTP 下载到本地；
• 重新上传到生产 VPS；
• 导入数据库；
• 对比当前线上版本；
• 只复制需要恢复的部分文件。

十四、极客方式：把 Restic 仓库挂载成本地“U 盘”

如果你只是误删了一个配置文件、一张图片，没必要恢复整个快照。

Restic 支持直接挂载仓库。

创建挂载目录：

mkdir -p /mnt/restic

挂载：

export RESTIC_PASSWORD="你的RESTIC仓库密码"

restic -r /data/restic-repo mount /mnt/restic

执行后，当前终端会进入挂载状态，看起来像是“卡住”了，这是正常现象。

这时新开一个 SSH 窗口，进入：

cd /mnt/restic/snapshots/

你会看到按时间组织的快照目录。
接下来就像浏览普通硬盘一样，找到需要的文件并复制出来即可。

例如：

cp /mnt/restic/snapshots/某个时间点/某个路径/文件 /tmp/

使用完毕后，回到原来的挂载终端，按：

Ctrl + C

即可卸载。

这个功能在日常维护中非常实用，尤其适合恢复单个误删文件。

十五、日常维护建议

1. 定期检查日志

OVH 上的定时任务日志写入：

/var/log/restic_daily.log

可以定期查看：

tail -n 100 /var/log/restic_daily.log

重点关注：

• Rsync 是否正常送达；
• .tar.gz 是否正常解压；
• Restic 是否成功入库；
• forget --prune 是否执行成功；
• 是否有权限错误或磁盘空间不足。

2. 定期执行恢复演练

只备份、不恢复，是很多人最容易犯的错误。

建议至少每月做一次恢复测试：

1. 随机选择一台 VPS；
2. 随机选择一个历史快照；
3. 恢复到 /tmp/restore_zone；
4. 检查网站文件是否完整；
5. 检查数据库 SQL 是否可用；
6. 尝试恢复一个小文件。

备份系统真正让人安心的时刻，不是它每天运行成功，而是你亲手恢复成功过。

3. Restic 密码必须多地保存

Restic 的加密是很可靠的，但这也意味着：

密码丢了，数据基本就回不来了。

不要只把密码写在脚本里。

建议保存到：

• 1Password、Bitwarden 等密码管理器；
• 离线加密文档；
• 团队项目的安全交接文档；
• 至少一份不依赖当前服务器的备份介质。

4. 重要业务建议再做异地副本

OVH 作为集中备份服务器已经比单机备份可靠得多，但它仍然是一个单点。

如果业务很重要，可以进一步把：

/data/restic-repo

同步到另一处存储，例如：

• 另一台大盘 VPS；
• 家用 NAS；
• S3 兼容对象存储；
• Backblaze B2；
• Hetzner Storage Box；
• Cloudflare R2。

更稳健的备份思路可以参考 3-2-1 原则：

至少 3 份数据，使用 2 种不同介质，其中 1 份放在异地。

十六、这套方案适合哪些场景？

这套 1Panel + Rsync + Restic 架构尤其适合：

• 有多台 VPS 的个人站长；
• 跨国部署的网站集群；
• 需要统一汇聚备份的小型团队；
• 数据库和网站附件较大的业务；
• 本地 VPS 磁盘较小，不适合长期保存备份；
• 希望保留多个历史版本，但又不想浪费太多存储空间；
• 需要快速找回单个历史文件的维护场景。

它不一定是最简单的方案，但它很清晰、稳定，也很容易扩展。

新增一台 VPS 时，只需要：

1. 安装 Rsync；
2. 配置 SSH 免密；
3. 设置 1Panel 本地备份；
4. 添加 Rsync 发货脚本；
5. 使用新的机器名目录推送到 OVH。

OVH 端脚本会自动识别新目录，不需要为每台机器单独写一份入库逻辑。

总结：备份不是把文件存起来，而是建立一条可恢复的退路

这套多 VPS 备份架构的核心，不是某个单独工具有多强，而是分工足够清楚：

• 1Panel 负责本地业务打包；
• Rsync 负责跨国稳定传输；
• OVH 负责集中接收和明文镜像；
• Restic 负责去重、加密和历史快照；
• Cron 负责自动化调度。

它解决的是生产环境里非常现实的问题：

• 面板远程上传容易卡死；
• 小 VPS 本地磁盘容易爆；
• 多台服务器备份不好统一管理；
• 历史版本占用空间太大；
• 恢复流程不够清晰。

一个好的备份系统，应该让你在平时几乎感受不到它的存在；但在服务器损坏、误删文件、数据库异常、网站被攻击时，它能稳稳地给你留下一条回去的路。

从这个角度看，备份不是额外工作，而是基础设施的一部分。
越早认真设计，越能在真正出事时少一点慌乱，多一点确定性。