快照和备份不是一回事：差异与误用

一、快照和备份到底差在哪

一句话区别：快照是「某个时间点的镜像」，备份是「一系列时间点的副本集合」。这个定义差异衍生出后面所有的实际差别。

具体展开：

快照（Snapshot） 是对某一时刻的完整或增量状态做的记录。它记录的是「磁盘上那一刻的字节状态」，恢复时把整个镜像铺回去，得到的机器和拍照那一刻几乎完全一致。快照通常是单点存在的——你今天做了一份快照，下个月再做一份，旧的那份要么被删、要么还占着空间，但它们是彼此独立的个体，不是链条。

备份（Backup） 是按时间序列累积的副本集合，通常有保留策略（保留 7 天、保留 12 份之类），并且可以配置为全量 + 增量混合。它记录的是「一段时间内的变化历史」，恢复时可以选择恢复到任意一个保留点。

最关键的一点区别在存储位置。 快照默认存在和原盘同一个存储系统上——你在一块 RAID 盘上打快照，快照也在这块 RAID 上。这意味着快照防的是「误删文件、误改配置、装了坏软件、系统起不来」这类逻辑层错误，但防不住「磁盘坏了、RAID 阵列挂了、机房着火」这类物理层故障。物理故障发生时，原始数据和快照会一起消失。

查看 iwebfusion 当前月价与库存

这个区别是本文的核心，后面所有内容都是它的展开。

二、快照的工作机制：COW 与增量链

现代虚拟化平台的快照几乎都用写时复制（Copy-On-Write，COW）。理解它的机制，就理解了快照的性能特征和容量计算方式。

COW 的工作过程是这样的：做快照的瞬间，系统记录下「原始块在磁盘上的位置」这个映射关系，这个映射表就是快照本体，原始数据完全不动。之后任何一次写入操作，系统先检查目标块是否出现在某个快照的映射表里：

- 如果不在任何快照里（新块），直接写，新数据覆盖原位置。

- 如果已经在某个快照里（脏块），系统先把原数据复制到快照专属的存储区（cow 空间），然后才允许覆盖。

所以关键结论是：快照本身很小，它只保存「状态指针」，真正的数据在第一次被覆盖时才被复制走。

这解释了三件事：

第一，快照创建极快。 无论你的磁盘是 20 GB 还是 6 TB，创建快照都只是写一个映射表，耗时通常在秒级以内。快照不是备份的「快速版本」，它是完全不同的技术。

第二，快照的空间占用随时间增长。 快照刚做完时几乎不占空间；随着机器运行、写入越多，被复制出去的数据块越多，快照越占空间。所以「刚做完快照时看剩余空间很充足」这个观察是误导的。

第三， 快照链会产生性能损耗。每次写入都要多一次查表，某些实现还有锁竞争。这也是为什么连续做几十个快照的机器，写入性能会明显下降。

用命令看看自己机器上的实际状态：

# 查看当前挂载的块设备和快照占用（ZFS 示例）
zfs list -t snapshot

# 列出所有数据集及其快照的占用
zfs list -r -t snapshot -o name,used,refer

# LVM 快照示例
lvs -a -o +snap_percent

查 justg 在售套餐与库存

别把快照链留太长。 一个实践原则：保留不超过 7 天内的快照，且总数不超过 5 个。更早的快照应该导出成备份（转成独立的备份格式存到别处），然后删掉原快照。

三、快照的空间占用怎么算

这是很多人低估的地方：以为快照就是「多占一份磁盘」，实际上因为 COW 和增量链的关系，占用会随时间推移往下滑。

规则一：快照的初始占用接近零。 刚做完快照那一刻，copied 空间通常是 0 或极小的元数据开销。

规则二：占用量 ≈ 快照创建后被修改过的数据量。 如果你的机器每天写入 20 GB 数据，三天后做的快照会占大约 60 GB（前提是这三天内的写入都覆盖了快照记录的原块）。

规则三：增量链会让占用叠加。 如果你连续做了三个快照，第一个快照的 60 GB 会一直占着，第二个快照又要复制一部分被再次修改的块，第三个同理。这三个快照占的总空间远大于「三次写入量」。

用真实配置做个算账。库里 sixtynet 的存储型套餐磁盘配置差异明显：

套餐	折月价	磁盘	磁盘单位成本	端口	月流量
sixtynet LAX-STARTER	16.67 美元	40 GB NVMe	0.417 美元/GB	2000 Mbps	5000 GB
sixtynet LAX-MICRO	33.33 美元	80 GB NVMe	0.417 美元/GB	4000 Mbps	10000 GB
sixtynet LAX-Storage-500G	33.33 美元	500 GB NVMe	0.067 美元/GB	10000 Mbps	10000 GB
sixtynet LAX-Storage-1TB	58.33 美元	1000 GB NVMe	0.058 美元/GB	10000 Mbps	15000 GB
云途 HK.DS.S	800 元	6000 GB SAS HDD	0.133 美元/GB	2000 Mbps	40000 GB
云途 HK.DS.P	750 元	1024 GB SSD	0.732 美元/GB	2000 Mbps	40000 GB

查 racknerd 在售套餐与库存

磁盘单位成本的极差超过 12 倍（0.058 vs 0.732 美元/GB）。做备份规划时这个数字非常关键——你的备份文件存在哪，直接决定了备份这件事的成本。

具体算：假设你要给一台 500 GB 磁盘的机器做全量备份，备份文件需要另外 500 GB 空间。

- 放在 sixtynet LAX-Storage-1TB（1000 GB 盘）上，磁盘单位成本 0.058 美元/GB，额外 500 GB 的边际成本按这个单价摊。

- 放在云途 HK.DS.P（1024 GB 盘）上，单位成本 0.732 美元/GB，同样 500 GB 的边际成本按这个单价摊。

两个单价相除是 12.6 倍——同一个备份动作，放在不同套餐上的账面成本差一个数量级。如果备份必须和原机同盘（不推荐，但有时不得不），选大盘高单位成本的机器会显著推高成本——这正是 LAX-Storage 系列存在的理由，它的单位成本是全库最低的 0.058 美元/GB。

更稳妥的做法是异机备份：备份文件放到另一台机器上，用 rsync 或者对象存储。这台机器的磁盘单位成本再高也只是临时的中转。

四、同盘故障：为什么快照救不了你

这是本文最重要的一节，也是「快照不等于备份」的核心理由。

场景：你的系统盘是一块 500 GB 的 NVMe，挂在 RAID 1 上（两块盘镜像）。你在今天上午 10 点做了一份快照。下午 3 点，RAID 控制器报告其中一块盘故障。

RAID 1 的机制是：只要还有一块盘是好的，数据就完整。控制器会自动用好盘重建坏盘。所以这次故障其实没有导致数据丢失——这是 RAID 的价值所在。

场景二：上午 10 点做快照，下午 3 点 RAID 阵列整体损坏（控制器故障、两块盘同时坏、或者机房级故障）。 这时原始数据和快照在同一块存储介质上，一起消失。你的快照救不了你。

场景三：机房级事故。 磁盘被偷、服务器被销毁、整个机柜断电。这和场景二同理。

这三种情况的共同点：快照和原数据在同一个故障域里。快照能防的，只有「数据内容层面的错误」：

- 误删了文件、误删了数据库表

- 系统更新搞崩了，配置文件被覆盖

- 装了有问题的软件，SELinux 或 AppArmor 配置被改坏

- 挖矿程序或恶意脚本破坏了系统文件

- 误操作执行了 rm -rf

换句话说：快照防「人」和「软件」造成的错误，不防「硬件」和「机房」造成的损失。

而后者恰恰是最致命的。 硬件故障是必然事件，只是时间问题。一台服务器的年化硬件故障率在百分之几到百分之几之间，对一台要跑三年的机器来说，不出故障的概率不到九成。你不能把「三年不出事」当成可靠的数据保护方案。

# 确认你的快照和原盘是否在同一个存储池里（ZFS 示例）
zfs get pool,origin tank/data

# 看所有 vdev 的拓扑关系
zpool status -v tank

查 spinservers 在售套餐与库存

zpool status -v 的输出会明确列出每个 vdev 是 mirror、raidz 还是别的结构。如果你的快照池和数据池在同一个 vdev 组里，那它防不了盘级故障——这就是本文要传达的核心结论。

五、全量备份与增量备份：怎么选

备份有两种基本形态，成本和恢复速度的取舍正好相反。

全量备份（Full Backup）：每次都复制全部数据。优点是恢复简单——把最新的那份铺回去就完事，不依赖任何其它备份。缺点是占空间、耗时间。

增量备份（Incremental Backup）：只复制上次备份后变化的部分。它自己是一个「差量补丁」，必须依赖前面的那个全量备份才能恢复。优点是省空间省时间，缺点是恢复链条脆弱。

还有第三种形态叫差异备份（Differential Backup）：每次都复制「相对全量备份」的所有变化。恢复时只需要最近的全量 + 最近的一次差异，中间的不需要。它的空间占用介于全量和增量之间，恢复链条比增量短。

用真实价格算一笔账。假设你要备份 500 GB 数据，全量备份每次耗时 2 小时（按 1000 Mbps 端口、NVMe 磁盘的实际速度估算），增量备份每次 20 分钟。

方案 A：每周一次全量，每天一次增量，保留 30 天。

项目	数量	单次耗时	合计耗时
全量	4 次/月	2 小时	8 小时
增量	28 次/月	20 分钟	9.3 小时
合计			17.3 小时

zenlayer 官网机型与实时报价

方案 B：每周一次全量，每天一次差异，保留 30 天。 差异备份的耗时随时间递增（相对上次差异的增量），取平均 40 分钟：4 × 2 小时 + 28 × 40 分钟 = 8 + 18.7 = 26.7 小时。占用空间比纯增量多，但恢复链只有两环。

方案 C：每天全量，保留 7 天。 耗时 30 × 2 小时 = 60 小时，但恢复最快（拿最新一份直接恢复，且任意一天都有独立全量）。

选哪个的判断标准是你能接受多长的恢复时间：

恢复目标	推荐方案	恢复耗时估算
分钟级（服务不能停太久）	每日全量 + 保留 7 份	2 小时以内
小时级（可容忍几小时）	每周全量 + 每日差异	2.5 小时
天级（可接受隔天恢复）	每周全量 + 每日增量	2.3 小时

注意上表有个反直觉的地方：全量恢复并不一定比增量恢复慢。铺一份 500 GB 全量到 NVMe 上是顺序写，速率可观；而增量恢复要「读全量 + 逐个应用差量」，链条上任何一环损坏就全废。在时间紧张的场景，全量备份 + 保留多份往往比复杂的增量链更可靠。

六、恢复耗时实测：别信宣传，自己测

「备份 5 分钟恢复」这种说法，只在特定条件下成立。真正需要你测的是从「发现故障」到「服务恢复可用」的全链路时间，而不只是数据铺回去的时间。

测法很直接：在测试机上做一次真实的恢复演练。

# 1. 记下备份文件的大小和数量（这是恢复耗时的关键输入）
ls -lh /backup/path/
du -sh /backup/path/

# 2. 实测复制速率（这决定恢复时间的下限）
dd if=/backup/path/last-full.img of=/dev/null bs=1M count=1000 oflag=direct
# dd 的输出最后会给出平均速率，据此估算铺回 500 GB 需要多久

# 3. 完整恢复演练（推荐用 LVM 快照或临时卷做，别直接覆盖生产）
lvcreate -L 500G -n restore_test vg0
dd if=/backup/path/last-full.img of=/dev/restore_test bs=4M status=progress
lvchange -an vg0/restore_test   # 记得清理

# 4. 数据库类的恢复要用逻辑恢复工具，不能直接铺物理镜像
mysqldump --single-transaction db > /backup/db.sql
mysql -u root -p db < /backup/db.sql

恢复演练必须包含验证环节，不然你测的只是「文件复制成功」，不是「服务能起来」：

# 恢复后验证数据库一致性
mysqlcheck --all-databases --check-upgrade -u root -p

# 验证网站关键页面能正常响应
curl -s -o /dev/null -w "%{http_code}\n" https://example.com
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/wp-login.php

# 验证文件数量和关键文件是否完整
find /var/www -type f | wc -l

查 cloudcone 在售套餐与库存

演练频率：至少每季度一次，且必须有一份不在生产机上做的完整恢复。只有在你真的从零恢复过一次之后，才知道恢复过程里有哪些隐藏依赖（比如某个配置文件不在备份范围内、某个数据库扩展没装、某个密钥在别的地方）。

七、数据库备份：物理备份和逻辑备份的区别

前面说的都是文件层面的备份。数据库是特殊的存在：它的文件不能直接复制后就用，因为复制的那一刻文件可能处于「写了一半」的状态。

物理备份（如 xtrabackup、Percona 的热备份）复制的是数据库的数据文件和数据字典，优点是大库速度快（接近文件系统速度），缺点是跨大版本不兼容——用 MySQL 8 的工具备份的数据，无法直接恢复到 MySQL 5.7。

逻辑备份（如 mysqldump）导出的是 SQL 语句，优点是跨版本、跨平台、可读可审查，缺点是大库慢，而且恢复时间与库大小成正比。

对大多数个人站长和中小业务，逻辑备份完全够用。以一个 5 GB 的数据库为例，mysqldump 大约需要 3 到 5 分钟，恢复时间也在同一量级——这个成本完全可以接受。

# 单库逻辑备份，带事务一致性
mysqldump --single-transaction --quick --routines --triggers \
  --databases mydb | gzip > /backup/mydb-$(date +%F).sql.gz

# 恢复
gunzip -c /backup/mydb-2026-11-05.sql.gz | mysql -u root -p

# 验证备份文件是否是完整的 SQL（看结尾有没有完成标记）
tail -3 /backup/mydb-2026-11-05.sql.gz | zcat

关键点：备份必须包含 --routines --triggers。默认的 mysqldump 不导出存储过程和触发器，恢复后你的定时任务可能悄悄失效，而这种问题要等到业务逻辑跑错时才暴露。

更可靠的方案是物理备份 + 逻辑备份双轨：物理备份保证大库恢复速度，逻辑备份保证跨版本迁移的可能。

digitalocean 官网机型与实时报价

数据库备份还有一个容易忽略的点：备份文件本身要加密。数据库备份里通常包含用户的密码哈希、邮箱、手机号等敏感信息。备份文件如果和数据库在同一台机器上，那它的安全性等于数据库的安全性——而数据库通常是暴露在外的。

八、跨区域存储：备份应该放在哪

回到第四节的核心问题：备份必须放在和原机不同的故障域里。具体要跨开哪些维度：

第一层：跨磁盘/阵列。 备份放在同一台服务器的另一块盘上，能防单盘故障，防不了整机故障。这是最低要求。

第二层：跨机器。 备份通过内网同步到另一台 VPS，能防单机故障，也防不了机房故障。

第三层：跨机房/跨地域。 备份存在另一个城市的机房，能防机房级事故（断电、火灾、地震）。

第四层：跨服务商。 存在完全无关的第三方（对象存储、另一家服务商），能防服务商级别的整体故障。

至少要做到第二层。 第一层是底线，第四层是预算允许时的最优解。

# 用 rsync 做异机同步（加 --delete 保持镜像一致，加 --bwlimit 避免占满带宽）
rsync -avz --delete --bwlimit=50000 \
  /var/backups/ [email protected]:/backup/

# 加了 --bwlimit 后，rsync 会在网卡上主动限速，不影响在线业务
# 用 screen 或 tmux 让长任务断开后继续跑
tmux new -s backup
# 在 tmux 里执行上面的命令，Ctrl+b 然后按 d 脱离，tmux attach -t backup 回来

带宽控制是必须的。 备份流量如果不限制，会把端口占满，在线业务立刻变慢。库里 sixtynet LAX-MICRO 的端口是 4000 Mbps 折月 33.33 美元、云途 HK.DS.M 是 1000 Mbps 折月 350 元——如果你在这两台上跑备份，记得限速。按 1000 Mbps 算，500 GB 全量备份要传 4000 秒，约 67 分钟。

异机备份的额外收益：它天然是一份独立的、位于不同故障域的副本，等于同时满足了「跨机器」和「增量同步」两个需求。你可以用 rsync --link-dest 做高效的增量：它只传输变化的文件，未变化的文件用硬链接指向上一份备份。

查 hostwinds 在售套餐与库存

# 增量备份：只传变化的文件，未变的用硬链接共享
rsync -avz --delete --link-dest=/backup/2026-11-04 \
  /var/backups/ [email protected]:/backup/2026-11-05/

九、常见的误用

误用一：把「有快照」当成「有备份」。 这是最普遍的问题。快照是单点、默认同盘、默认无保留策略、无异地副本。它是「应急回滚工具」，不是「备份方案」。

误用二：备份文件存在同一台服务器上。 备份和原数据在同一个故障域里，等于没备份。哪怕存在另一块盘上，也只能防单盘故障。

误用三：备份从不验证。 备份任务显示成功不等于备份可用。数据库备份最常见的问题是「备份文件是空的」或者「只备份了部分表」。必须做校验：

# 检查备份文件非空且格式正确
gzip -t /backup/mydb-2026-11-05.sql.gz && echo "gzip 完整"
zcat /backup/mydb-2026-11-05.sql.gz | tail -5   # 应看到 Dump completed

# 做一次真实的恢复到临时实例（最严格的验证）
mysql -u root -p -e "CREATE DATABASE restore_check;"
zcat /backup/mydb-2026-11-05.sql.gz | mysql -u root -p restore_check
mysql -u root -p -e "SELECT COUNT(*) FROM restore_check.mytable;"

误用四：快照做太多了。 快照占空间、拖慢写入、吃 COW 空间。留一堆半年前的快照，除了占地方没有任何价值。合理做法是快照只留最近的几个（用于快速回滚），长期历史交给备份。

误用五：用 rsync 备份数据库文件。 直接 rsync 数据库的数据目录，复制到的是某个中间状态的文件，恢复后可能报「表损坏」或者丢最近的数据。数据库必须用 mysqldump 或 xtrabackup。

误用六：把备份任务和业务放在同一台机器上跑，且不限速。 备份任务在凌晨跑，但访客的时区可能正好在你的凌晨。备份占满端口导致业务变慢，而你在监控里看到的只是「延迟升高」，很难立刻联想到备份。

误用七：以为云服务商控制台里的「备份」包含了所有数据。 要看清它备份了什么——只备份数据盘、不备份系统盘、或者不备份 /etc 和 /home 下的东西，是很常见的限制。

误用八：恢复演练从来没做过。 备份文件存在、任务成功、定时检查都过——但真出事时才发现恢复要 6 小时，而你以为只要 20 分钟。

误用九：备份了数据，忘了备份配置。 数据文件恢复了，但 Nginx 配置、防火墙规则、SSH 密钥、定时任务、数据库连接字符串、环境变量——这些都在 /etc 和 /opt 里，手工重建要花几小时。备份范围要包含配置，方式是把配置也放进版本管理：

# 用 git 管理配置目录（注意不要把密钥提交进仓库）
cd /opt/myapp && git add nginx/ app.conf systemd/
git commit -m "记录生产配置"
git push origin main

# 恢复时先拉配置，再恢复数据
git clone [email protected]:you/prod-config.git /tmp/prod-config
sudo cp -r /tmp/prod-config/nginx/* /etc/nginx/
sudo nginx -t && sudo systemctl reload nginx

误用十：以为「快照能回滚」就等于「数据不会错」。 快照能让你回到过去，但如果错误的数据已经在快照之前被写入了业务表（订单金额算错、库存扣成负数），回滚整个磁盘并不能修正它。这类逻辑错误必须靠应用层的审计和数据修复——快照解决不了。

查看 interserver 当前月价与库存

误用十一：备份频率和恢复目标不匹配。 你要求 RTO 是 1 小时（1 小时内恢复服务），但备份是每周一次、每天一次增量。最坏情况下你要回退到一周前的全量再叠加几十个增量——恢复时间以天计。备份频率必须由恢复目标反推，不是凭感觉定。

十、给不同规模的人的具体方案

个人站长 / 单机小站： 用面板的自动快照功能，保留最近 7 个（覆盖一周内的误操作），再加一条异地 rsync 到另一台机器。数据库用 mysqldump 每周一次。整个方案的成本可以压到每月几块钱——RosCloud-01 折月 19.99 美元（2 核 1 GB、20 GB 盘、500 Mbps、1024 GB 流量）完全能当备份机，它的价格最低而流量额度足够跑同步。关键动作是每季度做一次完整恢复演练。

中小业务站 / 团队： 三层组合——本机快照（保留 7 天）+ 异机 rsync（每日增量，保留 14 份）+ 数据库每日 mysqldump 逻辑备份。异机可以选一台配置相近的机器，参考 sixtynet LAX-MICRO 折月 33.33 美元（4 核 4 GB、80 GB NVMe、4000 Mbps、10000 GB 流量），它的流量额度足够做每日同步。同时做每季度的完整恢复演练，把 RTO（恢复时间目标）实测出来写进文档。

对可用性要求高的业务： 跨地域 + 跨服务商。备份放在另一个大区的机器或对象存储里，配合数据库的主从复制。sixtynet 的产品线在这一点上给了明确选项——LAX（洛杉矶）、IRVINE（尔湾）、Residential（住宅）是不同机房位置，选一台非洛杉矶的机器做备份节点，能防掉机房级事故。注意云途 HK.DS.S 配的是 SAS HDD（6000 GB，单位成本 0.133 美元/GB），做备份节点容量充足但磁盘性能一般，更适合存冷数据而非频繁增量的写入。

查看 itldc 当前月价与库存

给所有规模的一条硬性规则：备份的最终目的是「能在需要的时候恢复出来」。所以每一次备份，都应该存在一个「能成功恢复它」的证明。哪怕只是每周在一个临时实例上恢复一次数据库，也比从来不验证强一百倍。

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

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

• 主要访客在国内、在意打开速度：先确认回程线路，再谈配置。看 iwebfusion 当前机型与价格
• 跑游戏服或实时业务：看上行抖动与防御能力，普通套餐往往不达标。看 justg 当前机型与价格
• 只是开发测试、临时用：按小时或月付，用完就删，别买年付。看 racknerd 当前机型与价格

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

十一、常见问题

快照和备份到底该选哪个？ 两个都要，但角色不同。快照负责「快速回滚」——改坏了配置、装挂了软件，五分钟内恢复现场，代价是占本机存储、默认同盘、没有异地副本。备份负责「灾难恢复」——磁盘坏了、机房出事，代价是恢复慢（可能几小时）、需要演练、没有实时性。两者的成本结构完全不同，不存在二选一。

做快照会不会影响性能？ 少量快照（3 到 5 个）几乎无感。COW 的额外开销是每次写入多一次查表。但快照链越长、机器写入越多，COW 空间占用和写入开销上升，明显的性能下降通常出现在快照数量超过十个之后。

备份应该多久做一次？ 取决于你的「能接受丢失多少数据」。RPO（可容忍的数据丢失窗口）是 24 小时，就做每日备份；是 1 小时，就每小时或用 binlog 增量同步。个人站的现实答案是每周一次数据库全量加每日文件同步，这个组合能把 RPO 压到 24 小时以内。

快照能替代数据库备份吗？ 不能。数据库有自身的写入一致性要求，快照拍到的是一个中间状态的文件集合，恢复后可能需要做崩溃恢复，而且快照默认不包含事务日志的完整状态。用 mysqldump 做逻辑备份才是正解。

异机备份传过去会不会影响线上业务？ 会，除非你限速。rsync 的 --bwlimit 参数可以按 KB/s 限制传输速率。按 1000 Mbps 算，传 500 GB 需要约 67 分钟；限制到 100 Mbps 就是 11 小时。用 --bwlimit 把它控制在不影响业务的速率上，必要时在业务低峰期再跑。

备份文件需要加密吗？ 需要。数据库备份里通常含有用户密码哈希、邮箱、手机号等敏感信息。异机传输用 SSH（rsync over SSH 默认加密）就覆盖了传输过程；存储在目标机上的文件仍然需要加密，可以用 gpg 或 gpg-agent 加密后再落盘。

保留多少个历史版本合适？ 通用规则是保留 30 天，特殊规则是保留 7 个日备 + 4 个周备 + 12 个月备（GFS 保留策略）。关键在于覆盖「误删后立刻发现」到「误删后一个月才发现」这个时间跨度。

怎么知道我的备份任务真的在跑？ 三层验证：看任务退出码、看备份文件的大小和时间戳是否更新、做一次真实恢复。第三层是最容易做也最常被跳过的一步。