一、韩国VPS备份到底要不要做
先给答案：要做，而且优先级排在「加内存」和「升带宽」前面。 因为前两件事你买错了只是浪费钱，备份没做则是数据没了。
但很多人对备份有误解，先把这个误解拆掉。 备份不是「多存几份文件」，备份的唯一目的是在出事的时候能恢复出可用的系统。 一个从来没验证过能不能恢复的备份，严格来说不是备份，是一份让你感觉安全的文件。
这个区别决定了后面所有内容的重点：不看「备份了多少」，看「多久能恢复出来、恢复出来的东西能不能用」。
再算一笔风险账。 一台 VPS 承载的东西通常包括：网站程序、上传的媒体文件、数据库里的业务数据、以及各种配置和密钥。这四类东西的恢复难度差别很大：
- 网站程序，重新部署一遍就行，最容易恢复；
- 上传的文件，只要有备份就还在，没有就是永久损失；
- 数据库，必须用专门的工具导出，而且导出文件的格式和兼容性有讲究；
- 配置和密钥，最容易丢，因为它们通常不在你每天想的范围内——换机、迁移、重装时才会发现没有。
先把这四类分开，你就知道自己的备份该做多重。 只备份数据库不备份上传文件，等于放弃了最不可再生的那部分数据。
判断要不要做备份，最后看一个问题：如果这台机器现在磁盘坏了、机房说数据找不回来，你能在多长时间内让业务重新上线? 这个时间就是你的 RTO（恢复时间目标），而你的备份方案必须能在这个时间内跑完。
二、快照和备份有什么区别
这两个词经常被混用，但它们是两种完全不同的东西，选错了会出事。
快照是「某一时刻的磁盘状态」，备份是「一份可以拿走的独立数据」。 差别在三个地方：
第一，恢复粒度不同。 快照恢复的是整个系统或整块磁盘，你没法只从快照里取出某一个文件。 备份可以单独取出一个文件、一个表、一段配置。
第二，存放位置不同。 快照通常存在提供方自己的存储上，和你的机器在同一个体系内。备份可以放在任何地方——另一台机器、对象存储、你自己的电脑。
第三，跨平台能力不同。 快照几乎必然绑定在提供方的系统里。而备份是一份通用格式的文件，几年后你换到完全不同的机器上，它照样能用。
这个差别在「你换商家」的时候最明显。 快照跟着商家走，商家跑了或者换了系统，快照可能就取不出来了。备份是你自己的，谁也拿不走。
那到底该用哪个？ 实用答案是：快照用来做「快速回滚」，备份用来做「灾难恢复」。 两者不是二选一，是分工。
快照的典型用法是：改配置之前先打一个。 改坏了，五分钟内回滚，不用重装。这个场景下快照的恢复速度是分钟级的，而用备份恢复是小时级的。
备份的典型用法是：机房故障、磁盘损坏、误删、或者勒索软件。 这时候你需要的不是「回到十分钟前」，而是「回到昨天，并且能搬到别的机器上」。
所以一份合格的备份方案里，两样都要有。 但如果你的预算或者精力只够做一样，优先做备份，因为它的适用场景更广，而快照只是省时间。
三、备份要存几份才安全
这一节给一个可以照着做的规则，不用相信「三二一」这种口号。
先看 3-2-1 规则是什么意思： 至少 3 份数据副本，存放在 2 种不同介质或 2 个不同位置，其中 1 份在异地。
这条规则的价值不在数字，在于它逼你覆盖三种失效模式：
| 失效模式 | 哪一份副本能救你 |
|---|---|
| 误删文件或数据损坏 | 最近的版本副本 |
| 磁盘或硬盘物理损坏 | 同机器或同存储上的另一份 |
| 机房故障、数据中心失火 | 异地的那一份 |
| 勒索软件或恶意程序加密 | 未挂载的离线副本 |
这四种失效模式对应四种不同的保险，所以「几份」这个问题不能只用一个数字回答。 你要问的是：我的备份能挡住哪几种？
落到韩国 VPS 这个具体场景，常见的组合是这样：
- 第一份：机器本地的每日备份（快照或本地备份目录）。挡住误删和单文件损坏，但机器整个没了它也一起没了。
- 第二份：异地的每日备份（另一台机器或对象存储）。挡住机房故障。这一份是必须跨物理故障域的。
- 第三份：每周一次的离线或不可变副本。挡住勒索软件。关键是「离线」——只要副本一直挂在机器上，它就会被一起加密。
再说一个存储位置上的现实约束：韩国机房到国内其他机房的网络延迟和带宽是有限制的。 这意味着异地备份的传输本身可能成为瓶颈。所以选择异地位置时要考虑两件事：一是线路质量（传输会不会中断），二是流量额度（备份数据本身要占流量）。
这一点有具体影响，值得单独说。 一台 100 GB 的机器如果每周做一次全量备份，每次传 100 GB，一个月就是 400 GB 流量。 按公开商品库里的单价：云途 DS.ES.C 是 40000 GB 月流量、每 TB 流量 17.92 元，HK.DS.S 是 40000 GB、每 TB 流量 20.48 元，HK.DS.M 是 10000 GB、每 TB 流量 35.84 元。换算下来，400 GB 备份流量在 DS.ES.C 上约 7 元，在 HK.DS.M 上约 14 元。 备份流量不是零成本，这笔要算进预算。
四、异地备份往哪里放
这一节给三个可选方向，并说清各自的前提条件。
方向一：另一台 VPS 做备份接收端。 具体做法是第二台机器上跑一个备份服务（rsync over SSH、或者 restic/borg 这类工具），第一台机器定时推过去。
优点： 成本低、可控性强、数据格式通用、恢复速度快（内网拉取）。缺点： 你得自己保证第二台机器的安全（密钥管理、端口暴露、磁盘加密），而且它自己也需要被备份，否则你只是把风险挪了个位置。
方向二：对象存储（兼容 S3 协议的那种）。 备份工具把数据推到对象存储桶里。
优点： 存储成本通常低于再买一台机器；对象存储自带版本管理和跨区域复制，做「异地」这一步很自然；支持不可变存储桶（WORM） 可以直接挡住勒索软件。
缺点： 恢复时要下载全部数据，恢复速度取决于你的网络，不适合「5 分钟恢复」这类严苛的 RTO；流量费用可能超预期，特别是从对象存储拉回的时候。
方向三：自己电脑或 NAS。 适合个人用户、数据量不大。
优点： 成本几乎为零，数据完全在自己手里。缺点： 你的电脑会关机、会坏、会有网络问题，所以它不能是唯一的一份。 而且从家用宽带上传大文件的速度往往很慢。
至于「放哪里的机房」，这一节只讲客观事实，不替任何人做判断：
- 放国内机房：上传下载速度快（物理距离近、带宽足），但这属于跨境传输，需要考虑合规和数据出境的问题，你自己判断。
- 放日本或新加坡：距离近、延迟低，是兼顾速度和数据位置的常见选择。
- 放美国西海岸：距离远、延迟高，但带宽和流量额度通常更充裕，单价也可能更低。
- 放另一个韩国机房：延迟最低，但如果原机房和目标机房在同一个运营商的同一张网络里，你要考虑「同一张网同时故障」的情况，跨运营商会更稳。
具体机房位置、线路类型和流量价格，以各商家官网当日报价为准。
五、数据库怎么备份
这一节是最该先做好的，因为数据库是唯一「丢了就真没了」的东西。
MySQL 的标准做法是 mysqldump，核心命令长这样：
# 导出单个数据库
mysqldump -u 用户名 -p 数据库名 > backup.sql
# 导出并压缩，体积小很多
mysqldump -u 用户名 -p 数据库名 | gzip > backup.sql.gz
# 导出所有库
mysqldump -u 用户名 -p --all-databases | gzip > all.sql.gz关键是加对参数。 上面这条命令是最朴素的版本，生产环境建议加上这几个：
# 加上锁表、触发器、事件、单事务，保持数据一致性
mysqldump -u 用户名 -p \
--single-transaction --quick --lock-tables=false \
--routines --triggers --events \
数据库名 | gzip > backup.sql.gz--single-transaction 是 InnoDB 表的一致性快照， 它让备份不影响线上读写；--quick 是逐行读取，避免大表一次性载入内存把机器撑爆。 这两个参数在 1 GB 2 GB 的小机器上尤其重要，因为不加 --quick 的话，导出大表可能直接把机器内存吃光。
把这套命令写进计划任务，每天凌晨自动跑：
# 每天 03:17 导出并保留 7 天
17 3 * * * /usr/local/bin/backup-db.sh >> /var/log/backup-db.log 2>&1为什么是 03:17 而不是 03:00？ 因为整点的计划任务在很多机器上是同一时刻执行的，错开几分钟能避开磁盘 IO 和网络的拥挤时刻。 这个细节在有备份任务的机器群上是有意义的。
还有两件事必须做：
第一，备份文件不要只留在本机。 至少要推一份到异地。第二，备份文件要有保留策略。 常见的做法是保留「每日 7 份 + 每周 4 份 + 每月 6 份」，这样你既有最近的精细粒度，也有跨越几个月的长期回溯点。
还有一个容易被忽略的细节：大表导出时加锁的问题。 mysqldump 默认会锁表，在写入频繁的表上，这一锁可能持续几秒到几十秒，期间业务写入会排队等待。--single-transaction 的作用正是在这里——它用一致性快照代替锁表，让备份过程几乎不阻塞线上写入。 但它有个前提：只对 InnoDB 引擎的表有效，MyISAM 表仍然会被锁。 所以如果你的库里还有 MyISAM 表，要么转成 InnoDB，要么接受锁表窗口。
最后说一个关于备份格式的实用建议：保留压缩后的 .sql.gz，不要只保留压缩包。 因为压缩包在传输中断时可能损坏，而解包出来的 .sql 是你真正要用的东西。 定期在备份机上把压缩包解开跑一遍语法检查，能提前发现静默损坏。
# 验证备份文件是否损坏（能完整解包且能读到结尾即为正常）
gzip -t /backup/db-2026-11-11.sql.gz && echo "压缩包完整"
# 解压后检查 SQL 语法是否有明显错误（读到最后一行不报错即可）
gunzip -c /backup/db-2026-11-11.sql.gz | tail -50关于加密：备份文件里通常包含用户数据，敏感度不比数据库本身低。 加密应该在推送之前完成，也就是在源机器上加密好再传，这样异地存储端即使被读，也拿不到明文。
六、文件怎么备份
文件备份比数据库简单，但坑更多，因为「哪些文件该备份」经常想不清楚。
第一类：必须备份的。 用户上传的图片、附件、下载的安装包、任何由用户产生且不可再生的内容。判断标准很简单：这个东西丢了，能不能重新生成？不能，就是必须备份。
第二类：可以不备份的。 可以从代码仓库重新拉下来的东西、可以从源站重新下载的缓存、系统包（apt install 能装回来的）。备份这些只是浪费空间和带宽。
第三类：介于两者之间的。 配置文件。它们的价值不在文件本身，在于「当时的版本」。 建议进版本库，而不是靠备份保命。
推荐的备份工具是 rsync，关键参数是这几个：
# 增量同步到异地，保留权限和时间戳，删除目标端多余文件
rsync -avz --delete \
--exclude='*.log' \
--exclude='cache/' \
/var/www/ 用户名@备份机:/backup/www/--delete 要谨慎用。 它让目标端和源端保持一致（删掉源端已经没有的文件），但如果你在某台机器上误删了一个目录然后立刻跑同步，这个误删会传播到所有备份副本。 更稳的做法是先不用 --delete，定期人工核对，或者加一个保留窗口参数。
如果数据量大到 rsync 每次要跑很久，考虑增量方案： restic、borg、rsnapshot 这类工具只传变化的部分，能把「每次全量」变成「全量加增量」。 在带宽和流量都受限的韩国机房环境里，这不只是省时间，是决定你的备份方案能不能落地。
这一节还要补一个常见的取舍：备份文件的权限和属主。 rsync 的 -a 参数会保留权限、时间戳、属主属组、符号链接，这正是我们要的。但如果你从 root 权限备份一个属主是某个网站用户的目录，传到备份机后属主可能变成了 root（因为目标机上没有那个用户）。后果是恢复时文件属主错乱，网站可能因为读不到文件而报 500。
解决办法是恢复时显式指定属主，或者在恢复完成后统一 chown：
# 恢复后把网站目录的属主改回来
chown -R www-data:www-data /var/www/你的站点
# 确认目录权限（目录需要 x 权限才能进入，文件需要 r）
ls -ld /var/www/你的站点还有一个必须知道的事实：rsync 的传输是增量的，但它是「按文件比较」而不是「按数据块比较」。 这意味着一个 10 GB 的日志文件即使只追加了 1 MB，rsync 也会重传整个 10 GB。 所以大文件应该做轮转（logrotate），不要让它无限增长。 这是备份流量优化的关键一环。
七、备份频率和保留期怎么定
这一节给一个具体的规则表，你可以按自己的业务改。
先定频率，原则是「你的损失容忍度决定频率」。 常见的四档：
| 业务类型 | 建议频率 | 单次数据量 | 一次恢复的损失窗口 |
|---|---|---|---|
| 个人博客、静态站 | 每天一次 | 小 | 24 小时 |
| 企业官网、内容站 | 每天一次 + 每周全量 | 中 | 24 小时 |
| 电商、订单系统 | 每 4 小时一次 | 中 | 4 小时 |
| 论坛、UGC、聊天室 | 每 1 小时一次 | 大 | 1 小时 |
| 数据库为主的核心业务 | 实时 binlog + 每日全量 | 大 | 几分钟 |
再看保留期，原则是「保留期要覆盖你发现问题的时长」。 如果你的备份只留 7 天，而你是在三个月后才发现数据被悄悄改错了，那这 7 天里任何备份都救不了你——因为问题在那次备份之前就已经存在了。所以对有合规或审计要求的业务，保留期要按最长的事故发现周期来定，而不是按磁盘成本。
一个实用的组合是「每日 + 每周 + 每月」三层：
# 每日备份保留 7 天
find /backup/daily -type f -mtime +7 -delete
# 每周备份保留 4 份（每周日归档一次）
find /backup/weekly -type f -mtime +28 -delete
# 每月备份保留 12 份
find /backup/monthly -type f -mtime +365 -delete还有一个和频率强相关的成本项要算清楚：备份本身要占流量。 按第三节的算法，假设每次全量备份 50 GB、每天一次，一个月就是 1500 GB 传输量。 在 HK.DS.M（10000 GB 额度、每 TB 流量 35.84 元）上，这 1500 GB 约占 1.47 TB，折合约 53 元；在 DS.ES.C（40000 GB 额度、每 TB 流量 17.92 元）上，同样的量折合约 26 元。
这个数字的意义是：备份频率不只是技术选择，它直接影响你的月度账单。 增量备份能大幅压低这个成本，这也是第八节要讲自动化的原因。
还有一个容易被忽略的频率问题：备份要避开业务高峰。 一个 50 GB 的全量导出在 1 Gbps 的端口上跑满需要 400 秒，在 2 Gbps 上也要 200 秒，这期间会实打实地吃掉你的流量额度和磁盘 IO。把备份排在凌晨业务低谷，比什么优化工具都有效。
最后说一个关于频率的取舍原则：频率越高，备份窗口越短，但每次备份之间的重叠也越多。 一天备份 24 次（每小时一次）意味着你的保留策略里会有一堆内容高度重复的副本，存储成本上升但恢复价值不增。 真正需要高频备份的，只有那些「每小时损失超过一次备份成本」的业务。
具体价格以官网当日报价为准。
八、备份成本怎么算
这一节把成本拆成四项，让你能算清楚一台机器一个月的备份要花多少。
成本项一：备份存储。 如果用对象存储，按存储量和请求数计费；如果用第二台 VPS，它的月费就是你的存储成本。 参照公开商品库：HK.DS.M 是 350 元/月、32 GB 内存、480 GB 硬盘；拿它当备份接收端，一个月 350 元能装下你大部分站点的备份。
成本项二：传输流量。 第三节和第七节已经算过，这里给一个汇总：
| 方案 | 数据量 | 频率 | 月传输量 | 按 DS.ES.C 单价折算 | 按 HK.DS.M 单价折算 |
|---|---|---|---|---|---|
| 全量备份 | 50 GB | 每天 | 1500 GB | 约 26 元 | 约 53 元 |
| 全量 + 增量 | 50 GB + 约 15% | 每天 | 2250 GB | 约 39 元 | 约 79 元 |
| 只做增量 | 约 8 GB | 每天 | 240 GB | 约 4 元 | 约 9 元 |
这张表说明了一件事：增量备份在流量上是划算的，因为传的数据量少了一个数量级。前提是你的工具真的支持增量，且你的数据有大量未变化的部分。
成本项三：时间成本。 备份方案要有人写、有人测、有人定期检查。这一项不会出现在账单上，但它是所有成本里最容易被低估的。 一个写完就没人管的备份脚本，通常在半年后以「备份任务静默失败」的形式爆发。
成本项四：机会成本。 更隐蔽的一项：备份占用磁盘和带宽，而你的机器内存和流量是有限的。 一台 480 GB 硬盘的机器，如果本地保留 30 份 50 GB 的备份，磁盘就满了。 这是很多人「磁盘莫名其妙不够用」的真正原因。
把这四项加起来，你能算出一台机器的备份成本大概在每月几十到几百元的量级（取决于数据量和方案），相对于数据丢失的代价，这个投入是合理的。
最后提醒一条容易忽略的账：备份不是一次性投入，是持续的订阅。 你在计算「备份方案值不值」的时候，要按至少一年的持续成本来算，而不是按第一次做备份的成本。因为一年后你还要继续付这个钱。
九、怎么把备份自动化
这一节给一个可以直接照抄的自动化骨架。
自动化的核心是三件事：定时执行、失败要报警、定期验证。 第三件最容易被省掉，也最重要。
第一步，定时执行。 用系统的计划任务：
# 每天 03:17 全量备份数据库
17 3 * * * /usr/local/bin/backup-db.sh >> /var/log/backup.log 2>&1
# 每周日 04:23 全量同步文件
23 4 * * 0 /usr/local/bin/backup-files.sh >> /var/log/backup.log 2>&1第二步，失败必须报警。 这是整套自动化里最重要的一个设计。静默失败的备份比没有备份更危险，因为它给你虚假的安全感。 最小可行方案是让脚本在失败时发一封邮件或者推一条消息：
#!/bin/bash
# backup-db.sh 的核心逻辑
set -euo pipefail
OUT="/backup/db-$(date +%F).sql.gz"
mysqldump -u backup -p"$DB_PASS" --single-transaction --quick \
--routines --triggers --events "$DB_NAME" | gzip > "$OUT"
# 校验：文件存在且不为空
if [ ! -s "$OUT" ]; then
mail -s "备份失败：$OUT" [email protected] < /dev/null
exit 1
fi
# 推送到异地
rsync -avz "$OUT" backup@备份机:/backup/db/
# 清理超过 7 天的
find /backup -name 'db-*.sql.gz' -type f -mtime +7 -delete注意那个 [ ! -s "$OUT" ] 检查。 磁盘满的时候 mysqldump 会失败并写出一个空文件或者半个文件，如果没有这个检查，你的备份目录里会躺着一堆看起来存在、实际不可用的文件。
第三步，定期验证。 这就是第十节要展开的恢复演练。
再补两个自动化里常见的坑：
坑一，时区不对。 服务器时区和你本地时区不一致时，「每天凌晨 3 点」的含义就变了。跑一次 timedatectl 确认时区。
坑二，多个备份任务同时跑。 如果你既有数据库备份又有文件备份，都排在 03:00，它们会同时抢占磁盘 IO 和网络带宽，把备份时间拉长到超出你的时间窗口。错开时间点，同步错峰。
坑三，备份任务跑在错误的用户下。 如果计划任务用 root 跑，备份出来的文件属主是 root；如果用普通用户跑，可能读不到某些系统目录。 常见的做法是用 root 跑导出，但脚本内部对普通用户目录做权限处理，并且明确设置备份目录的权限为 700。
坑四，把 SSH 私钥直接写在脚本里。 脚本里明文保存密钥，一旦这个脚本被上传到任何地方（或者被日志系统收集），私钥就泄露了。 正确做法是用 ssh-agent 或者 ~/.ssh/config 里的 IdentityFile 配合密钥文件权限 600。
坑五，备份脚本没有退出码检查。 脚本里的命令如果失败了但脚本整体返回 0，外层的计划任务会以为这次备份成功了。 上面脚本里的 set -euo pipefail 就是为这个准备的：任何一条命令失败，整个脚本立刻退出并返回非零。
按你的情况，下一步该看哪家
上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：
- 做跨境或店群、需要多 IP：优先看 IP 类型与换 IP 政策，别只看配置。看 justg 当前机型与价格
- 主要访客在国内、在意打开速度：先确认回程线路，再谈配置。看 vpckr 当前机型与价格
- 只是开发测试、临时用：按小时或月付，用完就删，别买年付。看 zji 当前机型与价格
价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。
十、备份检查清单和恢复演练
最后一节是行动清单，也是整套备份方案的验收标准。
清单第一部分：四件必须做的事。
第一，列出你的四类数据并逐类确认备份状态。 程序、文件、数据库、配置密钥。每一类都要能回答「它在哪一份副本里」。 有一类答不上来，就是缺口。
第二，做一次真实的恢复演练。 这是整套清单里唯一不能跳过的。在备用机器或者本地虚拟机上，把最新一份备份完整恢复一遍，然后访问它。 记录下整个过程花了多长时间——这个数字就是你的实际 RTO。
第三，确认备份不在本机。 检查一下你的备份目录是不是和网站目录在同一个磁盘上。如果是，那它挡不住磁盘故障，只挡得住误删。
第四，设好告警。 确认失败通知能真的到达你（发个测试邮件试试），并确认告警渠道不是和服务器放在一起的。
清单第二部分：四个可以量化的验收指标。
| 指标 | 合格线 | 怎么测 |
|---|---|---|
| 备份成功率 | 最近 30 天 100% | 看任务日志 |
| 恢复耗时 | 满足你的 RTO | 演练时掐表 |
| 异地副本存在性 | 至少 1 份在另一台机器 | 登进备份机看文件 |
| 备份新鲜度 | 不超过 24 小时 | 看最新文件的修改时间 |
清单第三部分：给你三个具体动作。
动作一，今天就做一次恢复演练。 哪怕只是在本地虚拟机上恢复一份数据库，也比只做备份不做验证强一百倍。
动作二，把备份从本机推一份出去。 如果你现在的备份全在服务器本地，今晚就补上这一步。
动作三，下单或者续费前先算一遍备份成本。 参照公开商品库的档位：云途 HK.DS.M 是 350 元/月、10000 GB 月流量、每 TB 流量 35.84 元；DS.ES.C 是 700 元/月、40000 GB 流量、每 TB 流量 17.92 元；HK.DS.S 是 800 元/月、40000 GB 流量、每 TB 流量 20.48 元。如果你的机器流量额度本来就吃紧，备份流量必须提前算进去，而不是等月底被限速时才发现。
最后一句话，也是这一篇的核心：备份的完成标准不是「备份任务跑成功了」，而是「有人在需要的时候成功恢复过它」。
具体价格以官网当日报价为准。
喜欢 
高兴
鬼脸
呵呵
无聊
伤心
