实用的VPS备份策略（3-2-1规则）

由ApexVPS团队撰写 • 最后更新：2026年7月 • 7分钟阅读

可靠的VPS备份策略是五分钟恢复和糟糕一周之间的区别。服务器会故障，磁盘会损坏，部署会出错，一条命令输错就可能清空目录。Cloudflare学习中心和大多数基础设施团队都指向同一个简单的纪律：3-2-1规则。本指南介绍如何将其应用于真实的虚拟服务器、使用哪些工具，以及如何安排和测试所有内容，以便在需要时恢复真正起作用。

3-2-1规则的含义

3-2-1规则是一个有着数十年历史的备份原则，无论服务器位于何处都适用：

• 3份副本您的数据——实时副本加上至少两份备份。
• 2种不同的介质或存储系统——确保单一故障无法同时损坏两份副本。
• 1份异地副本——在物理或逻辑上与您保护的主机分离。

在VPS上，这通常意味着您的运行服务器、本地备份仓库以及推送到异地远程存储的加密副本。关键在于冗余，且没有共享的单一故障点。

VPS上需要备份的内容

逐块备份整个磁盘既浪费又缓慢。一个良好的备份计划应聚焦于三类真正难以重建的数据。

应用数据与文件

上传的文件、网站根目录、容器卷及任何用户生成的内容。常见路径包括/var/www、/srv、/home以及您的Docker卷目录。如果您自托管文件服务器或wiki等应用，您的不可替代内容就在这些目录中——参见我们的VPS自托管指南了解这些目录的通常布局。

数据库

切勿在服务运行时直接复制数据库文件——可能会捕获到写入一半的损坏状态。请导出一致的转储。对于MySQL或MariaDB：

mysqldump --single-transaction --routines --triggers \
  -u backup -p mydatabase > /srv/backups/mydatabase.sql

--single-transaction参数可为InnoDB表提供一致快照且无需锁定。对于PostgreSQL，请改用pg_dump：

pg_dump -U postgres -Fc mydatabase > /srv/backups/mydatabase.dump

系统与服务配置

让服务器具备独特性的文件：/etc（nginx、systemd单元、cron、SSH配置）、软件包列表、TLS证书和防火墙规则。故障后凭记忆重建这些内容正是备份所要避免的繁琐工作。

选择您的备份工具

三种工具几乎覆盖所有VPS场景。根据您对去重和加密的重视程度进行选择。

restic——加密、去重的快照

restic是一种现代的单二进制备份工具，默认进行加密和去重。初始化仓库一次，然后对其运行备份：

# One-time: create an encrypted repository
restic init --repo /srv/backups/restic

# Back up files and your database dump
restic -r /srv/backups/restic backup /etc /var/www /srv/backups/mydatabase.sql

# List what you have
restic -r /srv/backups/restic snapshots

BorgBackup——去重归档

BorgBackup提供类似的去重和压缩功能，但工作流程略有不同：

borg init --encryption=repokey /srv/backups/borg
borg create --stats /srv/backups/borg::'{hostname}-{now}' /etc /var/www

rsync——简单文件镜像

当您仅需快速将文件镜像到其他主机时，通过SSH使用rsync难有敌手：

rsync -aAX --delete /var/www/ [email protected]:/backups/www/

-aAX参数保留权限、ACL和扩展属性；--delete使镜像与源保持同步。rsync本身不保留版本历史，因此许多团队将其与restic或borg搭配使用。

使用cron自动化调度

需要记得运行的备份往往不会被运行。将步骤写入脚本，使其可执行，并通过cron调度。用以下命令编辑crontab：

crontab -e

然后添加类似这样的行：

# Full file + config backup every night at 02:15
15 2 * * * /usr/local/bin/vps-backup.sh

# Database dump every hour on the hour
0 * * * * /usr/local/bin/db-dump.sh

记录输出，并让脚本在失败时以非零状态退出，以便接入您的套餐所附带的监控与提醒功能。静默的备份失败比没有备份更糟糕，因为它让人误以为一切安全。

保留真正的异地副本

3-2-1中的“1”是多数人忽略的部分。存放在所保护服务器本地的备份会随服务器一同消失。请将加密副本推送到独立位置——对象存储、远程SFTP主机或其他提供商。restic和borg均可直接写入远程仓库，例如通过SFTP：

restic -r sftp:[email protected]:/backups/restic backup /var/www

由于restic和borg在数据离开VPS前即已加密，远程主机永远无法看到明文。按策略清理旧快照，以免存储无限增长：

restic -r /srv/backups/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

每次务必测试恢复

未经过测试的备份只是一种传闻。在临时位置定期执行恢复演练，并确认文件和数据库完好归来：

# Restore the latest snapshot into a scratch directory
restic -r /srv/backups/restic restore latest --target /tmp/restore-test

# Verify repository integrity
restic -r /srv/backups/restic check

# Re-import a database dump into a scratch database
mysql -u root -p restore_test < /srv/backups/mydatabase.sql

如果恢复成功且数据匹配，你就有了策略。如果没有，你只是在一个周二的下午而不是在真正的中断期间学到了这一点。

快照只是其中一层，不是完整策略

每个ApexVPS套餐都包含自动备份——Starter Pro每日快照，Business每小时快照——在糟糕的部署或意外删除后，它们对于快速回滚确实非常实用。但请如实看待它们的定位：它们只是驻留在我们平台上的便捷第一道防线，不能替代3-2-1规则所要求的异地、独立验证副本。请将平台快照视为快速的本地恢复点，并自行运行restic或borg任务来满足规则中的异地与恢复测试部分。无论是自托管Nextcloud这类应用还是运行生产数据库，这种分层做法才是让系统从“碰运气”走向“有韧性”的关键。

您的 VPS 备份策略清单

综合起来，完整备份策略如下。完全执行一次，编写脚本，让 cron 自动执行：

• 识别重要内容 — 应用程序文件、数据库转储以及 /etc 下的配置。
• 选择工具 — 使用 restic 或 BorgBackup 进行加密、去重、版本化备份；使用 rsync 进行简单镜像。
• 一致性地转储数据库 — 使用 mysqldump --single-transaction 或 pg_dump，切勿直接复制实时文件。
• 自动化 — 使用 cron 安排脚本，并对任何非零退出代码发出警报。
• 将一份副本推送到异地 — 加密、存储在独立存储上，并制定合理的保留策略。
• 定期测试恢复 — 恢复到临时位置并确认数据完好无损。

完成这六件事，3-2-1 规则就不再是理论，而是成为您基础设施可以依赖的习惯。与事故发生中发现唯一副本就在刚死掉的磁盘上相比，前期一小时的设置微不足道。

常见问题

提供商的快照能算作备份策略吗？

快照是有用的一层，但不是完整策略。我们的每日和每小时快照可以防止大多数短期错误，但它们的存储位置与您的服务器在同一平台。完整的 3-2-1 备份策略仍然需要您控制的独立异地副本，以及您实际测试过的恢复。

我应该多久备份一次 VPS？

备份频率应根据您可以承受丢失的数据量来匹配。静态文件和配置可以每日备份，而活跃数据库通常值得每小时转储。使用 cron 自动化计划，这样备份永远不必依赖记住运行它们。

VPS 备份的最佳工具是什么？

restic 和 BorgBackup 都是极好的选择：它们对备份进行去重、压缩和加密，并支持异地仓库。rsync 适用于简单的文件镜像，而 mysqldump 或 pg_dump 处理数据库导出。许多设置结合了数据库转储和 restic 或 borg 运行。

我如何知道我的备份实际有效？

按计划测试恢复。恢复到临时目录，验证文件内容和校验和，并将数据库转储导入临时数据库。从未恢复过的备份只是满怀希望地猜测，而不是恢复计划。