日本VPS备份怎么做

一、先算清备份的真实成本，别等出事才发现

大部分人做备份时只看到一个问题：我的数据在哪。实际上要算三笔账：占多少磁盘、占多少流量、花多少钱。

先看磁盘单价。目前有真实结构化价格数据的在售机型，磁盘单价差异非常明显：

机型	月费	内存	系统盘	月流量	内存单价	磁盘单价	流量单价
RosCloud-01	19.99美元	1 GB	20 GB	1024 GB	19.99美元/GB	1.00美元/GB	19.99美元/TB
RosCloud-02	29.99美元	2 GB	40 GB	2048 GB	14.99美元/GB	0.75美元/GB	15.00美元/TB
RosCloud-03	39.99美元	4 GB	80 GB	3072 GB	10.00美元/GB	0.50美元/GB	13.33美元/TB
RosCloud-04	49.99美元	4–8 GB	160 GB	4096 GB	6.25美元/GB	0.31美元/GB	12.50美元/TB
LAX-Storage-500G	400.00美元/年	4 GB	500 GB	10000 GB	8.33美元/GB	0.07美元/GB	3.41美元/TB
LAX-Storage-1TB	700.00美元/年	8 GB	1000 GB	15000 GB	7.29美元/GB	0.06美元/GB	3.98美元/TB
云途 HK.DS.P	750.00元/月	64 GB	1024 GB	40000 GB	11.72元/GB	0.73元/GB	19.20元/TB
云途 HK.DS.S	800.00元/月	128 GB	6000 GB	40000 GB	6.25元/GB	0.13元/GB	20.48元/TB

zenlayer 官网机型与实时报价

同一个「1 GB 磁盘」的成本，从 0.06 美元到 1.00 美元，相差十六倍多。这意味着同样一份 100 GB 的备份，放在不同机器上，隐含成本完全不同。

流量单价也是一笔账。把备份传到异地要消耗流量。RosCloud-01 的流量单价 19.99美元/TB，LAX-STARTER 折合 3.41美元/TB，差了近六倍。如果你的备份方案是「每天从日本机器推一份到另一台机器」，那么源机器的出站流量是要计费的。

算一个具体例子。假设你的站点实际占用 20 GB 磁盘，每天做一次增量压缩后传 5 GB，一个月就是 150 GB。按 RosCloud-01 的 19.99美元/TB 算，150 GB 约合 0.147 TB，流量成本约 2.93 美元；按 LAX-STARTER 的 3.41美元/TB 算，同样 150 GB 约合 0.147 TB，成本约 0.50 美元。一个月差 2.4 美元，一年差 29 美元。

再算存储侧的账。100 GB 备份在 RosCloud-01 上按 1.00美元/GB 的磁盘单价算是 100 美元的空间价值（虽然这类低价机通常没有额外存储可买，只能用同机盘的剩余空间）；在 LAX-Storage-500G 上，按 0.07美元/GB 算是 7 美元。差距是 93 美元。

这个结论是：备份方案的选择必须和机器的选型放在一起做，而不是选完机器再随便定个备份方式。如果你打算做长期的异地备份，那么一台磁盘单价低、流量单价低的机器在总账上明显更划算。

但必须强调一句：上面算的是「空间和流量的隐含成本」，不是备份服务的报价。独立的对象存储、异地服务器的存储空间，都以各服务商当日页面显示的价格为准，上面的数字只是帮你判断量级用的。

二、快照与备份不是一回事，机制差别决定用途

这是最常见的概念混淆，也是备份策略出错的第一步。

快照是块设备层的时间点镜像。它的原理是在写入磁盘数据块之前，先把即将被覆盖的旧数据块原样复制到快照存储区，然后才写入新数据。这个过程叫 copy-on-write。它的特点是：快。一次快照通常几秒到几十秒完成，和数据量关系不大。缺点是它占的是整机磁盘空间，而且必须能访问到原机器，快照通常挂在原机器或同一存储池上。

备份是文件或应用层面的数据副本。它的原理是把文件读出来、压缩、加密、传到别的地方。特点是：慢，耗时与数据量成正比，而且会产生持续的网络流量和 CPU 消耗。优点是副本独立存在，可以在完全不同的机器甚至不同机房恢复。

这两者的差别在故障恢复时会变成生死之别：

维度	快照	备份
位置	原机器或同存储池	异地、独立账号
机器被人为破坏后能否用	不能	能
恢复速度	快，通常几分钟	慢，与数据量和带宽相关
恢复粒度	整机全量	可只恢复某个文件或某个库
对流量的消耗	几乎为零	按传输量计
能否验证内容正确	弱	强，可以解压校验

查 justg 在售套餐与库存

最关键的一行是第二行。勒索软件、误删整盘、账号被盗后删库，这些场景下原机器的快照可能一起被加密或被删——因为攻击者拿到的是 root 或面板权限，快照管理接口通常也在同一个权限体系下。异地备份是唯一能在这种情况下救你命的东西，而快照不是。

所以正确的结构是：快照负责「快速恢复」，备份负责「灾难恢复」。两者不能互相替代。

备份还必须分三种形态，这是第二个常被忽略的层次：

- 全量备份：完整复制所有数据。最简单，恢复时间确定，存储成本最高。

- 增量备份：只复制上次备份后变化的数据。存储省，但恢复时要按顺序依次应用所有增量。

- 差异备份：复制上次全量之后所有变化的数据。存储比增量多，但恢复只需要全量加一次差异。

实用的组合是：每周一次全量，每天一次增量，保留 30 天。这个组合的存储成本大约是「全量 + 6 到 7 天的增量」，恢复时最多需要应用 7 个增量链。

三、异地存储怎么选：三种方案的机制与代价

异地备份要解决的核心问题不是「放在哪」，而是「放在一个你的账号被封时你还能拿回来的地方」。

方案一：另一台同厂商 VPS 拉取。

机制：在第二台机器上跑一个接收端，本机用 rsync 或 rclone 推送。

代价：接收端机器要一直开着，成本是持续的两台机器钱。

优点：实现简单，数据完全自己控制，恢复速度快（内网或近线路）。

适用： 有两台机器、且第二台的流量单价低的情况。

方案二：对象存储（S3 兼容、OSS 兼容这类）。

机制：备份客户端直传对象存储桶，本机不留副本。

代价：按存储容量和请求次数计费，按服务商当日页面报价。

优点：存储成本通常远低于第二台机器的整月机器费，且天然异地、天然多副本。

关键： 桶的凭据必须只具备写入和列举权限，恢复用的凭据单独保存，不要和日常应用在同一台机器上。

方案三：第三方专用备份服务。

机制：服务商的客户端直接拉取，支持增量、保留策略、时间点恢复。

代价：按数据量计费。

优点：支持时间点恢复，这是前两种方案都不具备的——你能恢复到「误删发生前 10 分钟」。

选型时按这三条判断：

1. 恢复时间目标（RTO）是多少？ 如果你的业务允许停机 4 小时，那么传一份全量的笨办法就够。如果要求 15 分钟内恢复，必须有增量或时间点恢复能力。

2. 恢复点目标（RPO）是多少？ 如果能接受丢一天数据，每日备份够。如果要求几乎不丢数据，得靠持续复制或日志归档。

3. 预算形态是固定还是浮动？ 对象存储是按量计费的，数据涨了账单就涨；异地机器是固定成本，容量大到用不完也不额外花钱。数据量稳定的小站点用对象存储，数据量大且稳定的用异地机器更划算。

日本节点的一个具体提醒：日本机房出故障或线路出问题时，备份也传不回来——如果备份目的地和源站都在日本，地理上的「异地」就是假的。**异地备份的地点至少要和源站跨一个大区，跨出日本是最稳的选择。

还有一个容易被忽略的现实约束：备份的传输时间本身就是恢复时间的一部分。假设你的站点占 20 GB，每天压缩后传 5 GB。从日本到另一个大区的实际可用带宽取决于两端的线路和时段：按 100 Mbps 的稳定吞吐算，5 GB 大约需要 7 分钟；按晚高峰时段 20 Mbps 算，需要 34 分钟；遇到跨境链路的抖动，实际可能更久。这意味着如果你的备份任务和你的备份窗口重叠，恢复时间会明显拉长。要缩短这个数字，有三条路：压缩率高一些的算法、加密前压缩、或者把传输窗口固定在低峰时段并验证这个时段的实际吞吐。

带宽计费类型也要提前确认。有些服务商对入站流量免费、对出站流量收费，备份属于典型的出站流量；而日本节点面向国内用户时常用的是按流量或按带宽上限计费的套餐，两种计费下备份策略的取舍完全不同。按带宽上限计费的机器，备份推送会占用端口带宽，可能挤压业务流量；按流量计费的机器则直接变成账单上的数字。在做备份方案之前，先搞清楚你那台机器是哪种计费方式，这决定了备份应该在什么时候跑。

查看 zgovps 当前月价与库存

最后补一条容易被忽略的备份对象：配置本身。应用代码通常在 Git 里，但 Nginx 站点配置、systemd 服务单元、防火墙规则、crontab、SSH 配置这些东西往往只存在于那台机器上，而且改完没人记得改了什么。把它们和数据库放在同一个备份包里——恢复时才发现少一份配置，前面的演练就全白做了。**

四、恢复演练：不演练的备份等于没有备份

这是整套流程里价值最高、也最容易被跳过的一步。

备份成功的判据不是「备份任务显示成功」，而是「用备份恢复出来的东西是对的」。两者之间隔着解压、权限还原、数据库导入、服务启动，每一步都可能失败。

完整的恢复演练要做四件事：

第一，定一个固定的演练周期。建议每季度一次，或者每次有重大变更之后。演练要选在低峰时段，但要真的断开生产。

第二，在备用机器上恢复。不要在原机上恢复，因为原机上可能有残留状态，让你误以为恢复成功。

# 1. 检查备份文件完整性，先不解压就能验证
sha256sum -c backup_20260115.tar.gz.sha256

# 2. 解压到独立目录，不覆盖任何现有路径
mkdir -p /mnt/restore_test && tar -xzf backup_20260115.tar.gz -C /mnt/restore_test

# 3. 对数据库做导入测试到独立库名，不覆盖生产库
mysql -u root -p -e "CREATE DATABASE restore_test CHARACTER SET utf8mb4;"
mysql -u root -p restore_test < /mnt/restore_test/db/dump.sql

# 4. 核对表数量和关键表的行数
mysql -u root -p -e "SELECT COUNT(*) FROM restore_test.wp_posts;"

第三，测量真实恢复时间。从开始执行恢复脚本到服务可用，全程计时。这个数字才是你的 RTO。把整个流程写成脚本，让机器执行而不是手工操作，因为恢复的时候你手会抖，而且慢。

第四，检查权限与属主。备份时用 root 打包、恢复时以别的用户运行，是最常见的「文件都在但服务起不来」的原因。打包时用 --numeric-owner 保留数字 UID/GID，恢复时才不会错位。

# 打包时保留属主数字 ID，避免跨机器 UID 不一致
tar -czpf backup_$(date +%Y%m%d).tar.gz /var/www /etc/nginx --numeric-owner

演练的验收标准写成数字：

验收项	合格线
备份文件校验和通过	100% 一致，零差异
解压耗时（100 GB 数据）	< 40 分钟
数据库导入耗时	< 30 分钟
服务恢复可用（首字节）	< 300 毫秒
文件属主与权限错误数量	0 个
从备份到完全可用的总耗时	< 2 小时

查看 景文互联 当前月价与库存

如果总耗时超过 2 小时，你的备份方案就是「理论上有、实际用不上」。因为真出事的时候，你能接受的操作窗口往往只有几小时。

五、成本、频率与保留期的换算表

备份成本是三个数的乘积：单份数据量、备份频率、保留份数。

按增量后的实际数据量算，一份 20 GB 站点的典型配置：

策略	单份平均大小	每月实际占用	保留期	期末总占用
每日全量、留 7 份	20 GB	约 600 GB	7 天	140 GB
每日增量 + 每周全量、留 30 天	5 GB 增量 + 20 GB 全量	约 350 GB	30 天	约 250 GB
每周全量、留 4 份	20 GB	约 80 GB	28 天	80 GB
只做每日全量、留 30 份	20 GB	约 600 GB	30 天	600 GB

查看 backwaves 当前月价与库存

结论一：加增量比加频率更省。每日全量留 7 份，期末占 140 GB；每日增量加每周全量留 30 天，期末占约 250 GB，但恢复点目标从「7 天」提升到「1 天」。多花 110 GB 空间，把 RPO 从 168 小时压到 24 小时。

结论二：保留期超过 30 天的价值快速衰减。绝大多数误删、误操作、账号异常在 30 天内被发现。留 90 天的唯一好处是应对「慢速加密勒索」，代价是存储翻三倍。

结论三：异地副本不要只留一份。同一个存储桶里的多副本，能防硬件故障，防不住账号泄露。账号泄露的防护手段是启用对象存储的 MFA 删除保护——这是配置项，不是备份策略的一部分，但必须配。

算一笔月度总账：假设你的站点占 20 GB，用每日增量加每周全量、保留 30 天的策略，平均占用 350 GB。若放在一台年付 400.00美元、折合 33.33美元/月的 4 GB 80 GB 磁盘的机器上做本地备份，350 GB 显然放不下，只能用对象存储，这部分以服务商当日报价为准。若用一台年付 700.00美元、折合 58.33美元/月的 8 GB 1000 GB 磁盘机型，本地能装下大部分，流量单价 3.98美元/TB，每天传 5 GB、月传 150 GB 的外传成本约 0.58 美元。这台机器同时要跑业务，所以它的磁盘单价 0.06 美元/GB 才是这笔备份账里真正的大头。

六、自动化：让备份成为默认动作而不是任务

手工备份一定会被忘记。忘记一次，备份链就断了，而断掉的链往往在你需要它的时候才被发现。

推荐的自动化结构：三层，每层解决不同问题。

第一层：文件级定时备份。用 cron 调 rsync 或 rclone，脚本要具备三个特性：带时间戳命名、生成校验和、失败时退出码非零。

#!/bin/bash
# /usr/local/bin/backup.sh —— 每晚 03:17 执行
set -euo pipefail
STAMP=$(date +%Y%m%d_%H%M)
DEST=/data/backup
SRC=/var/www

# --delete 只在目标机本地盘上用；传到远端时不要带，避免误删远端备份
rsync -a --numeric-owner --info=stats2 \
  --exclude='*.log' --exclude='cache/' \
  "${SRC}/" "backup@backup-host:${DEST}/${STAMP}/"

sha256sum "${DEST}/${STAMP}/data.tar.gz" > "${DEST}/${STAMP}/data.tar.gz.sha256"

第二层：数据库备份。数据库必须单独备份，且要保证一致性。用 mysqldump 的 --single-transaction 参数，这样 InnoDB 表的备份不会锁表。

mysqldump --single-transaction --quick --routines --triggers \
  -u backup_user -p'你的密码' yourdb | gzip > ${DEST}/db_${STAMP}.sql.gz

第三层：快照。每日一次快照，配合每周一次全量。快照存在的意义是「备份链本身出问题时的快速回滚点」。

cron 时间不要整点。整点（如 0 3 * * *）是所有人都在用的时间，异地存储在那个时间点会有流量尖峰，推送变慢甚至超时。改成 17 3 * * * 这样的非整点，避开尖峰。

必须做的两件事：

给备份任务加监控。备份脚本的输出要能被外部监控采集到。如果脚本失败没人知道，那它就不是自动化，是自动化地失败。

# 在脚本末尾，成功时发送成功信号，失败时告警
if [ $? -eq 0 ]; then
  curl -s "https://监控地址/成功"
else
  curl -s "https://监控地址/失败"
fi

查 digitalvirt 在售套餐与库存

做一次「备份失败」的演练。故意让备份脚本失败一次，确认告警真的会到你手上。没验证过的告警通道等于没有。

七、什么情况下不该用某些备份方案，以及替代做法

这一节按公开事实讲不适用场景，不评判任何商家好坏。

场景一：数据量小、每天变动很少，比如一个只有几十篇文章的静态博客。

依据：全量 100 MB 每天传一次，一个月才 3 GB 流量，按最低的 3.41美元/TB 算不到 0.01 美元，为了这点钱搭一套复杂的增量链不值得。

替代方案：直接用 Git 存内容，配置文件和数据库用每日全量脚本，不需要增量逻辑。版本控制本身就是备份，还自带历史记录。

场景二：数据库体积大、更新频繁，比如几百万行的业务库。

依据：mysqldump 的耗时随数据量线性增长，100 GB 库的导出可能超过一小时，导出的 SQL 文件是几十 GB 的文本。

替代方案：改用物理备份或数据库原生的复制机制，而不是逻辑导出；同时用流复制做异地热备，主库故障时可以直接切。

场景三：机器是按流量计费的短期实例，用完就删。

依据：流量单价在 RosCloud-01 是 19.99美元/TB，LAX 系列折合 3.41美元/TB；短期机上传备份既慢又不划算，而且机器随时会被回收。

替代方案：备份目标直接用对象存储，本机不留副本；或者把状态存在可迁移的镜像或容器卷里。

场景四：源站和备份目的地在同一个机房或同一个大区。

依据：机房级故障或线路中断时，备份同样取不回来，地理隔离形同虚设。

替代方案：备份目的地选在另一个大区。公开资料里 zgovps 的数据中心布局包含美国洛杉矶、荷兰诺德韦克和日本大阪，justg 的公开简介里覆盖东京、首尔与莫斯科，恒创科技的公开简介里说明产品部署在香港、美国、日本与韩国的数据中心——跨机房选项是现成的，选一个不在日本的目标即可。

场景五：业务要求零停机恢复。

依据：文件级备份恢复时原文件必然被覆盖，数据库导入期间服务不可用，这与零停机的要求直接冲突。

替代方案：做主从复制，读写分离，恢复时切换流量；或者用支持时间点恢复的服务，配合应用层的双写或灰度切换。

场景六：IP 资源受限、需要频繁更换机器的业务。

依据：备份和恢复都依赖稳定的目标标识，频繁换 IP 时，备份任务的目标地址、证书、凭据都要跟着改，配置的连续性成本很高。

查看 恒创科技 当前月价与库存

替代方案：把备份目标做成与源机无关的独立存储桶，用域名而不是 IP 指向它，避免地址变化导致任务中断。

八、四类人的备份方案，一句话结论

第一类：个人博客、企业官网这类内容型站点，数据量在几 GB 以内。

用 Git 存代码和内容，数据库每天全量导出一次传到对象存储，保留 7 份，机内再留一份最近 3 天的本地副本。每季度手动演练一次恢复，验收标准是「从拉取备份到页面能打开不超过 30 分钟」。这类站点的 RPO 容忍度很高，方案可以很轻。

第二类：WordPress 商城、会员系统这类有真实业务数据的站点。

采用「每日增量加每周全量、保留 30 天」，备份到异地对象存储，启用 MFA 删除保护。每月做一次完整的恢复演练，必须实测总恢复时间小于 2 小时。应用层再配一份数据库的 binlog 归档，把 RPO 压到分钟级。注意：数据库备份必须用 --single-transaction，否则导出时锁表会影响线上。

第三类：跑游戏服、直播推流、实时业务的用户。

这类业务的恢复目标不是「数据不丢」，而是「尽快拉起来」。策略是快照为主、备份为辅：每天一次快照保证快速回滚，配合每周全量异地备份防止整机被毁。恢复演练的重点不是恢复数据，而是恢复服务——演练时测的是「从快照启动到服务接流量需要多久」。同时这类业务通常流量消耗大，备份的外传流量成本要单独算进账。

第四类：跨境电商、多 IP、多机房的用户。

查看 hostkvm 当前月价与库存

用配置管理工具保证所有机器的备份策略一致，备份目的地统一到一个与 IP 无关的对象存储桶。每台机器独立备份、独立保留，不要合并成一个包——合并包在恢复时无法只恢复其中一台。多机场景下最重要的一条是：备份凭据不能和业务凭据共用同一套，否则一台机器被拿下，全部备份同时失守。

九、一份可以直接抄的执行清单

按这个顺序做一遍，覆盖率就够用了。

第一步：盘清要备份什么。

# 看磁盘实际占用，确认哪些目录是有价值的
du -sh /var/www/* 2>/dev/null | sort -rh | head -20
# 确认数据库体积
du -sh /var/lib/mysql

排除掉日志、缓存、编译产物这些可再生内容，剩下需要保留的通常只有站点目录、数据库、配置文件三样。

第二步：定三个数字。RTO 写具体分钟数，RPO 写具体小时数，保留期写具体天数。这三个数字决定了后面所有配置。

第三步：实现并验证一次。先手动跑一次完整的备份加恢复，确认链路通。

第四步：接进 cron。非整点执行，失败返回非零退出码，输出写日志文件。

# 加进 crontab
crontab -e
# 实际写入：
17 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

第五步：接告警。外部监控采集备份日志，失败时通知到你实际会看的地方，并做一次失败演练验证通道。

第六步：做恢复演练并计时。在备用机上恢复，记录总耗时，对照第四节那张验收表逐项打勾。

查 vollcloud 在售套餐与库存

第七步：每季度重复第六步。间隔太长会忘记流程，环境变化后备份脚本可能已经悄悄失效。

按你的情况，下一步该看哪家

上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：

• 只想搭个站、预算优先：先看价格最低那档够不够用，别为用不上的配置付钱。看 zenlayer 当前机型与价格
• 做跨境或店群、需要多 IP：优先看 IP 类型与换 IP 政策，别只看配置。看 justg 当前机型与价格
• 主要访客在国内、在意打开速度：先确认回程线路，再谈配置。看 zgovps 当前机型与价格
• 跑游戏服或实时业务：看上行抖动与防御能力，普通套餐往往不达标。看 景文互联 当前机型与价格

价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。

十、常见问题

日本VPS备份应该选快照还是文件备份？

两者都要，用途不同。快照解决「快速回滚」，文件备份解决「整机没了还能活」。判据是灾难类型：误删文件用备份，磁盘坏了用快照，机器被整机删除或账号被封只能用异地备份。只做快照是最危险的配置，因为攻击者拿到 root 后可以删掉快照。

备份应该存在同一台服务器上吗？

不应该，但可以留一份本地副本做快速恢复。本地副本解决的是「文件被误删」，异地副本解决的是「机器没了」。只做本地备份等于没做备份，这是最常见也最贵的错误。

rsync 备份时加不加 --delete？

本地盘之间同步时加，用来清掉目标端已删除的文件；传到远端时不要加，否则目标端一次同步失败就可能把远端的旧备份清空。这是备份脚本里最容易造成不可逆损失的一个参数。

数据库备份多久做一次合适？

看 RPO 要求。允许丢一天就每天一次，要求接近实时就得配 binlog 归档或流复制。无论频率如何，备份时的 --single-transaction 不能省，否则 InnoDB 表在导出期间会被锁表，备份本身会影响线上业务。

异地备份的目标应该选在哪里？

至少跨出源站所在大区，跨出日本最稳。判断标准不是「哪个机房好」，而是「源站出问题时这个目标还能不能访问」。同机房或同大区的两个机房在机房级故障面前等于一个。

备份文件加密吗？

异地传输的备份必须加密，至少传输层用 TLS，存储层如果服务商支持也开静态加密。更严格的做法是自己加密后再传，密钥单独保存——因为存储服务的账号一旦泄露，对方能删也能读，不加密等于没保密。

备份任务显示成功，但恢复出来是空的，怎么排查？

三个方向查：一是校验和，比对 sha256sum -c 的结果，备份文件损坏是最常见的原因；二是权限，用 --numeric-owner 打包并检查恢复后的属主；三是打包时机，检查脚本是不是在服务还在写入时打包的，数据库用导出而不是直接打包数据目录。