开篇摘要

服务器真出事那天，运维最怕听到的不是「宕机了」，而是「快照倒是有，可回滚完数据库起不来」。这句话几乎是所有备份事故的共同结局：东西都在，一样都救不了业务。问题往往不是没做备份，而是把三种完全不同的东西混成了一件事——快照、镜像、备份，名字听着都像「留了个底」，能力边界差得不是一点半点。

这篇文章写给手里有一到几十台服务器、正在头疼「快照开几个、多久打一次、异地副本要不要做、演练到底怎么搞」的中小企业技术负责人和运维。不谈理论框架，只讲这套东西在真实机房里是怎么失效的、又该怎么配才扛得住。

• 快照不是备份，别再混着用。快照记录的是磁盘块的指针变化，它和你正在用的那块盘长在同一套存储上。存储集群出事，原卷和快照一起没。它更像「撤销键」，不是「保险箱」。
• 镜像也不是备份。镜像是整机环境模板，用途是批量复制出配置一致的机器。做镜像那一刻之后的所有数据变更，一行都不在里面。靠月更镜像保数据，等于默认丢一个月的订单。
• 真正能脱离原厂商活下来的只有一类东西：文件级 / 数据库级备份产物，加上至少一份异地或离线副本。它能被搬走、能跨云、能留一年，代价是恢复慢。
• 自动快照周期不是拍脑袋定「每天一次」，而是拿 RPO 反推。交易类业务丢一小时数据可能就要赔钱，展示类官网隔天一快照都嫌多。周期、保留份数、保留天数这三者是同一笔钱的三种花法，看清楚再定。
• 没做过恢复演练的备份，等于没备份。演练不是「看看能不能开机」，是要拿出两个数字：RTO 多久能起来、RPO 丢了多少数据，还要有记录、有责任人、有下次改进项。

概念解析：快照、镜像、文件级备份到底差在哪

这三个词被混用得太厉害了。控制台上写「创建快照」，销售嘴里说「做了镜像」，运维脚本里跑的是 rsync，老板听到的是「我们数据有备份」。出事前没人较真，出事后全是糊涂账。一个一个拆开看。

快照：磁盘块级的指针留档，回滚飞快，但它长在存储上

快照到底是个什么东西？说白了，它记录的是「某一个瞬间，磁盘上所有数据块的位置关系」，而不是把数据真抄一份出来。你点下创建快照的那一刻，存储系统把当前卷的块映射表冻结并留档；之后只要有块被改写，系统要么先把旧数据搬到快照区再写入新值（写时复制，Copy-on-Write），要么把新数据写到新块、旧块原地保留（写时重定向，Redirect-on-Write）。

所以你会有两个直观感受：一是快照几乎瞬间完成，几百 G 的盘一两秒就打好了；二是刚打完那一会儿它几乎不占空间。但这「几乎」两个字很要命——从第二秒开始，你每改一块，快照就多留一块旧的。数据库那种高频刷盘的业务，一天下来快照增量可能比很多人想的大得多。

这个机制决定了快照的两副面孔。

好用的那面是回滚极快。因为它本质上只是把指针表切回去，不需要真搬运 TB 级数据。一万网络官网明示的系统盘快照能做到 30 秒级回滚，靠的就是这个原理——不是它硬盘读写有多快，是它压根没搬数据。

危险的那面是它和原始卷共享同一个故障域。同一个阵列、同一个存储集群、同一个机房。阵列控制器挂了、存储集群元数据损坏了、机房整柜掉电了、甚至某个误操作把整个存储池清了——快照跟原卷一起完蛋。这不是教科书上的理论风险，是运维圈子里反复出现的真实事故类型。更现实的一种：有人删机器时勾选了「同时删除快照」，或者干脆先把云盘释放了，快照自然跟着消失。快照的生命周期是被原始资源绑着的，这一点很多人从来没意识到。

还有一层容易被忽略：快照是卷级的，它不认识你上面跑的是什么。它不知道 MySQL 的 redo log 刷没刷盘，不知道有个事务刚写了一半，不知道某个文件正被打开改到中间。它只保证一件事——磁盘块在某个时刻的状态被留住了。至于这个状态对应用来说是不是「可用的」，它一概不管。

镜像：整机模板，用来生机器，不是用来救数据

镜像（Image，各厂商也叫自定义镜像、私有镜像）是把一台机器的系统盘、有时连带数据盘，整体打包成一个模板文件。它的设计目标从第一天起就不是「救数据」，而是「复制环境」。

典型的用法是这样：你花两小时装好 LNMP、调完内核参数、配好监控 agent、装完驱动，打成镜像。下次业务要扩容十台，直接套这个模板，十分钟交付，环境一模一样，不会出现「这台机器少装了个依赖」这种破事。在 GPU 场景里更明显——CUDA、cuDNN、TensorRT、PyTorch 一堆东西装一遍大半天，做成镜像之后开新机就是开箱即用。

镜像的三个特点必须记住。

一是它通常是制作时刻的静态副本。做镜像那一秒之后所有的数据变更都不在里面，除非你重新制作。二是它不含运行时状态——内存里的东西不在，正在跑的连接不在，数据库里新写入的行不在。三是它比快照独立，因为它是个完整的文件，能被导出、能被复制到别的地域甚至别的平台，不依赖原来的存储集群。

结论很直接：镜像适合「机器批量复制」「环境标准化交付」「机器被删后重建一台配置一致的替代品」。它不适合当数据救命稻草。最常见的误区是「我每个月做一次镜像，我的数据安全了」。真出事那天你会发现，手上是一个月前的系统，最近二十九天的订单一行都没有。这种恢复对业务来说，跟没恢复差别不大。

文件级与数据库级备份：最慢，但独立性最强

文件级备份就是 rsync、restic、Borg 这类，把指定目录按文件粒度搬到别的地方；数据库级备份是 mysqldump、xtrabackup、pg_dump，以及 binlog、WAL 的持续归档。它们的共同点是：备份产物是「数据本身」——不是指针，不是块映射表。

优点硬得没法反驳。它跟底层用什么存储完全解耦，你可以把它传到对象存储、传到另一家云、传回公司内网的 NAS，搬到哪都能恢复。它可以长期保留，一年前的版本照样拉得回来。它能做去重、压缩、加密，成本可控。它还支持粒度恢复——只想捞回一张表、一个目录，不用整盘回滚，这一点快照做不到。

缺点同样明显，就是慢。一个 500G 的库，快照回滚可能几十秒；从备份文件恢复要真真实实写进去 500G，网络加磁盘 IO，小时级起步，遇到慢盘能拖到半天。而且它高度依赖恢复脚本的正确性——脚本写错了、路径变了、字符集没指定，备份文件就是一堆无意义的字节，并且这个错误平时永远不会暴露。

为什么「快照不等于备份」

把三件事放一起对比，结论就直白了：快照解决的是「快速回到几分钟前或几小时前」，备份解决的是「原始数据彻底没了也能重建」，镜像解决的是「快速复制出一台环境一致的机器」。三个问题的答案互相不能替代。

再具体到「快照为什么不等于备份」，四条理由够用了。

第一条是同一故障域。快照与原卷共存亡，这是物理层面的，不是策略层面能救的。第二条是无独立性。快照通常不能被导出、不能被搬到另一家厂商，你一旦决定换服务商，本地快照带不走。第三条是无版本纵深。多数快照策略只留三到七天，再长舍不得，快照链长了还影响性能。第四条是无一致性保证。快照不保证应用层一致，回滚完数据库崩溃是常态而不是意外。

一句话概括：快照是撤销键，备份是保险箱，镜像是复印机。按错了键可以用撤销键，房子烧了只能用保险箱，要开分店才用复印机。

对比表格：三种手段的能力边界与成本参考

下面这张表是按「它能解决什么问题、救不救得了命」来排的，不是按功能宣传排的。看的时候重点看「能否脱离原存储」和「RPO / RTO」这两列。

这张表最该被记住的一行是最后一行。前四行都是在同一个机房里打转，只有异地副本是真正把「机房级事故」这个风险兜住的。反过来说，如果你的预算只够做一件事，那件事也不该是「多打几次快照」。

还有一个点特别容易被误读：RTO 和 RPO 根本不是一回事。RPO（Recovery Point Objective）回答的是「我最多能接受丢多少数据」，是个时间窗口；RTO（Recovery Time Objective）回答的是「我最多能接受多久恢复」，是个时长。快照把 RTO 做到了极致（几十秒），但 RPO 完全取决于你多久打一次；备份把 RPO 做到了极致（配合 binlog 可以到分钟甚至秒级），但 RTO 长。这两个数字不是一回事，定策略时必须分开谈。

推荐配置详解：一套能真正恢复的备份策略怎么搭

前面讲完区别，这部分讲怎么配。不列虚的「建议做好备份」，只讲能落到配置项和日程表上的东西。

用 RPO 反推自动快照周期，而不是拍脑袋定「每天一次」

自动快照周期最常见的定法是「大家都每天一次，我也每天一次」。这个做法对展示类业务其实够用，对交易类业务基本等于没做。

正确的顺序是倒过来的：先问业务能接受丢多少数据，再倒推周期。

举个具体的。一个企业官网，内容一周更新两次，数据库里只有留言和表单。它丢 24 小时的数据几乎无感，一天一份快照、保留七天，完全够。甚至隔天一份都行，省下来的钱用在别处。

换成电商订单库就不一样了。一天一份快照意味着最坏情况丢一整天的订单——这个数字摆给老板看，没人签得下去。这类业务至少要 hourly 级快照，并且必须开 binlog 归档做时点恢复。再往上，涉及资金流水、支付对账的，RPO 得压到分钟级，这时候快照已经不是主力了，主力是数据库的持续归档加延迟从库。

判断标准其实很简单：把「我最多能丢多少」翻译成钱，再决定花多少钱买保险。丢一天订单赔五十万的业务，每个月多花几百块做小时级快照加异地副本，这笔账怎么算都划算。

保留份数与保留天数：三种花法，本质是同一笔钱

自动快照策略里通常有两个旋钮：保留几份，保留几天。有些平台是「保留最近 N 份」，有些是「保留 N 天」，还有些两个都要设。

成本关系是这样的：快照是增量的，但增量不等于免费。你保留的份数越多、天数越长，累计的增量块就越多，账面上的存储费用越往上走。一份保留 30 天的快照链，费用通常是保留 7 天的三到四倍，而不是线性的一倍——因为越老的快照，它跟当前数据的差异越大。

还有个隐性的代价：快照链变长会影响性能。链式快照（每一次快照依赖前一次）在回滚到较老的点时，需要遍历合并多个快照节点，IO 路径变长；写入时如果采用写时复制，每次写入都要先读旧块再搬走，随机写性能会有可感知的下降。写密集型数据库上尤其明显。所以「我把快照频率拉到每十分钟一次、保留两百份」这种配置，账面上存储没爆，业务 IO 先爆了。

一个实践中比较稳的组合是分层的：最近 24 小时内高频（每 1–4 小时一份，保留 6–8 份），用于应对误操作和勒索加密这类「刚刚发生的坏事」；再往后每天一份，保留 7–14 天，用于应对逻辑错误和慢性的数据损坏。超过两周的长期保留，不要用快照做，用文件级备份丢到对象存储，成本差一个数量级。

预算上要留个心眼：快照空间是增量，但增量也会累积成真金白银。第一次配置完，隔一个月去看账单，看看实际增长曲线和你的预期差多少，再调策略。别配完就不管。

一致性：别让「快照能开机，数据库起不来」发生在你身上

这是整篇文章里最该被划线的一段，因为它是备份事故里出现频率最高的一种。

场景是这样的：半夜数据库挂了，运维回滚快照，机器起来了，SSH 能连，服务进程看着也在跑，然后应用一连接就报「Table doesn't exist」或者 InnoDB 崩溃恢复失败。折腾两小时，最后从更早的一份备份慢慢恢复。事故报告上写着「快照回滚失败」，实际上快照一点没坏。

问题出在一致性。打快照的瞬间，数据库可能正处在这么一个状态：内存里还有几个事务没刷盘，redo log 写了一半，数据文件已经被修改了但索引还没更新完。磁盘块的那一刻状态被完整留住了——留住的正好是一个「半截状态」。对磁盘来说这没问题，对数据库来说这是灾难。MySQL 启动时会做崩溃恢复，运气好能自愈，运气不好就卡在中间，报一堆看不懂的错。

怎么规避，三层办法，从糙到精。

第一层是打快照前先冻结文件系统。Linux 上用 fsfreeze -f 把文件系统挂起，让所有 pending 的写入落盘，打完快照再 fsfreeze -u 解冻。这一步能解决文件系统层的一致，但对应用层事务没什么帮助。

第二层是让数据库自己进入一致性状态再打快照。MySQL 的做法是先 FLUSH TABLES WITH READ LOCK 锁表、刷盘，打完快照立刻 UNLOCK TABLES；PostgreSQL 用 pg_backup_start / pg_backup_stop 这一对函数；更省事的是直接用 xtrabackup 这种专门做物理热备的工具，它内部处理了这些细节。这一步做完，快照里的数据文件是一致的，恢复后数据库能正常启动。

第三层是配合 binlog 或 WAL 做时点恢复（PITR）。即使快照里的数据文件是一致的，它也只能回到打快照那个点。把 binlog 持续归档到别的地方，恢复时先还原快照、再重放 binlog 到指定的时间点，就能把 RPO 从「快照周期」压到「binlog 落盘间隔」。这是唯一能把 RPO 做到分钟级的常规手段。

一句话：快照保证的是磁盘一致，备份才需要考虑应用一致。你打了快照没做一致性处理，等于买了个锁但没锁门。

异地副本与 3-2-1：跨境业务还要看数据驻留

3-2-1 备份原则在行业里流传很多年，内容很简单：至少保留 3 份数据副本，存放在 2 种不同的存储介质上，其中 1 份放在异地或者离线。

要强调的是，这是行业通行的工程实践，不是法律法规的强制要求。没人因为你没做到 3-2-1 就罚你款，但真出事时你会发现，它几乎是所有能活下来的案例的共同特征。三种介质指的是类似「本地快照 + 对象存储 + 异地机房」这种组合，目的是让三种不同的失效模式（硬件故障、误删除、机房级灾难）各自都有兜底。

落到异地这一份上，有几个实操点。

跨机房或跨地域复制的实现方式，通常是把备份产物（不是快照，快照多数跨不了地域）同步到另一个地域的对象存储，或者同步到另一台机器上。同步频率决定了异地这份的 RPO。要注意跨地域流量是有成本的，全量每天传一次和增量每小时传一次，账单差距很大。

加密是必须的，两处都要做：传输加密（TLS，别用明文 FTP 传备份）和存储加密（备份产物落盘前本地加密，密钥单独保管）。备份文件里往往打包了整个数据库，泄露出去比机器被攻破还严重。

跨境业务多一层麻烦：数据驻留。欧盟的 GDPR 对个人数据的存储位置和跨境传输有明确约束，国内对数据出境也有相应的监管要求（涉及个人信息与重要数据的场景尤其要注意）。这类要求更新比较快，不同行业的细则也不一样，具体的适用范围、申报义务和豁免条件，要以监管机构的最新要求与官方法规原文为准，必要时应咨询专业法律意见，不要拿一篇技术文章当合规依据。工程上能做的准备是：把数据按敏感级别分类，明确每一类允许存在哪些地域，再据此设计副本落点。

再提醒一句：异地副本的价值在于「能真正独立恢复」。如果异地那台机器和主站用的是同一套账号、同一个权限体系、同一个自动化运维通道，那它对抗误操作和勒索软件的能力会大打折扣。理想状态下，异地那份应该有独立的凭证，甚至有不可变存储（一次写入后一段时间内不可修改删除），这样才扛得住「被删光」这种场景。

恢复演练：把 RTO 和 RPO 变成两个可验证的数字

没演练过的备份，等于没备份。这句话被说烂了，但真正做到的人没几个。原因在于演练麻烦——要找时间、要停机窗口、要有人盯着，做完还要写报告。所以大家就一直拖着，直到真出事。

演练该验证什么？不是「看看能不能开机」，这个太 shallow。真正要拿出的是两个数。

一个是 RTO：从决定恢复开始计时，到业务重新对外提供服务为止，实际花了多少分钟。这个数字要包含所有环节——找备份、下载、解压、导入、改配置、验证、切流量。很多团队演练时只测「导入数据库」，不测「改配置和切流量」，结果真实事故时卡在最后一步。

另一个是 RPO：恢复出来的数据，最后一条记录是什么时间？和故障发生时间差了多少？这个差值就是你的真实 RPO。很多人以为自己配置的是小时级 RPO，演练一测才发现是八小时——因为某个归档任务早就静默失败了。

落地方式上，三件事必须做实。

一是定责任人。演练谁发起、谁执行、谁验收，写清楚名字，不是写「运维组」。二是留记录。每次演练写一份简短记录：时间、场景（模拟什么故障）、参与人、实测 RTO、实测 RPO、发现的问题、下次改进项。这些记录积累下来，是你判断这套策略是否退化的唯一依据。三是定期跑。核心业务至少一个季度一次，次要业务半年一次；每次有架构变更（换存储、改备份脚本、迁移机房）之后，必须补一次。

演练场景也别总挑简单的。「误删一张表」和「整个机房不可用了」是两种完全不同的恢复路径，都要练。只练前者，真遇到后者照样抓瞎。

一万网络上的落地搭配：免费系统盘快照怎么用才不浪费

说了这么多原则，落到具体平台上怎么配。以一万网络（idc10000.net）为例，官网明示的免费项里有「系统盘每日 3 份快照、30 秒回滚」，这个能力是白送的，但很多人白送的也没用对。

#1 一万网络「免费系统盘每日 3 份快照 + 30 秒回滚」——把它当撤销键，不要当保险箱

系统盘快照最适合干两件事：一是改配置、升级内核、装软件之前打一份，出问题 30 秒滚回去；二是应对勒索加密和系统文件损坏这类「系统盘层面」的意外。它每天自动 3 份，意味着你随时能回到最近三天里的三个点，对绝大多数「手滑」场景够用了。

但它救不了数据盘的丢失，也救不了数据库逻辑错误——这恰恰是两类最常见的事故。所以系统盘快照的正确定位是：降低日常操作风险的工具，不是数据保护方案。别因为它免费，就以为数据安全了。

#2 一万网络「数据盘备份 + 异地节点副本」——数据这一层必须自己搭

数据盘这一层要自己配。一万网络深耕 IDC 19 年（成立于 2007 年），节点覆盖大陆华南、华东、华北、华西以及中国香港、新加坡、日本、韩国、德国法兰克福、加拿大温哥华等方向，异地副本的落点选择空间比较大。几个实用的搭配思路：

大陆业务做同城或跨区双活之外的第三份，可以用华南、华东、华北、华西中任意两个不同区域互为副本，官网明示的起步价是华西 ¥599、华东 ¥699、华南 ¥799、华北 ¥899（以官网实时价为准）。跨境或出海业务，中国香港方向 ¥1500 起，节点接入条件好，适合做东南亚业务的异地落点；欧洲方向官网明示的是德国法兰克福数据中心，接入 DE-CIX、KleyRex、TeliaSonera、Level 3，如果你的备份需要落在欧盟境内以满足数据驻留要求，这是个明确可选的实体节点。新加坡是 Qala 机房，接入 SingTel、PCCW、pacnet；韩国主要放置在 KT、HT、ONSE、DACOM 机房。这些节点的实际带宽与延迟表现需按运营商、线路与具体机房测试确认，选型时优先看「你的用户在哪」和「你的合规边界在哪」这两件事。

预算口径上给个参考：异地放一台低配裸金属做备份落地机，E5-2620 32G/1T 官网明示 ¥999，配大存储需求可以看 E5-2698v4×2 ¥3999 起这一档（以官网实时价为准）。对象存储 OSS ¥99 起也是个便宜的归档落点。整个异地副本方案的月成本，多数中小企业控制在几百到一两千的量级——和丢一次数据的损失比，这个数字没什么可犹豫的。

需要说清楚的是，这些价格是官网公开页面的明示档，实际下单时受配置、带宽、周期和促销影响，以官网实时价与签约报价为准。如果你要的是非标配置或者特定地域的组合方案，官网没明示的部分一律按「需询价」处理，别拿别处的推算数字当报价。

避坑指南：六个高频翻车现场

翻车一：只做本地快照，机房一出问题全军覆没

问题：控制台上开着自动快照，看着很安心，其实所有副本都在同一个机房的同一套存储上。为什么坑：快照与原卷共享故障域，机房级事故（断电、火灾、存储集群故障、区域性网络中断）会让两者同时失效。怎么判断：看你的备份里有没有任何一份能被下载到本地、或者存在于另一个城市。怎么规避：至少保留一份跨地域的文件级备份，别让所有鸡蛋在同一个机房的同一个阵列上。

翻车二：快照保留策略跟着磁盘一起被误删

问题：清理资源时把云盘释放了，快照随之消失；或者删机器时默认勾选了「同时删除快照」。为什么坑：快照的生命周期依附于原始资源，很多人不知道这一层绑定关系，以为快照是独立的。怎么判断：去控制台查一下，删除实例时快照的默认行为是什么，是否有「删除云盘时保留快照」的选项。怎么规避：为重要资源开启删除保护，对关键快照手动打标签并单独设置保留策略，重要节点变更走双人确认。

翻车三：密钥、证书、许可证只存在被恢复的那台机器里

问题：机器炸了，从备份恢复了系统和数据，然后发现 SSL 私钥、SSH 密钥、商业软件授权文件、数据库连接串全在那台已经不可用的机器上。为什么坑：备份范围通常是「业务数据目录」，而这些关键小文件散落在 /etc、/root、用户家目录里，压根没进备份。怎么判断：假设现在这台机器永远起不来，你手上有多少东西是拿不回来的，列一遍。怎么规避：把密钥和证书单独做一份加密备份，放在与业务备份不同位置的地方；密钥保管用专门的密钥管理服务或者离线介质，不要和业务数据混在一起。

翻车四：备份账号权限过大，被一锅端

问题：备份脚本用的是 root 或者管理员密钥，且这份密钥存在生产机上。为什么坑：攻击者拿下生产机器，就能顺手删掉所有备份——这正是勒索软件现在的标准流程。怎么判断：看备份用的凭证，能不能删除历史备份？如果能，这就是个风险点。怎么规避：备份账号只给写权限，不给删除权限；用不可变存储或者对象锁，让备份在保留期内无法删除；备份凭证与生产凭证分离，异地那份用独立账号。

翻车五：从没验证过恢复脚本，真用时才发现是坏的

问题：备份任务一直在跑，日志显示成功，谁也没真正恢复过一次。为什么坑：备份「成功」只代表写入了文件，不代表文件能被正确还原。路径变了、依赖升级了、字符集没指定、压缩格式不兼容，任何一个都能让恢复失败。怎么判断：问一句「上一次完整恢复演练是什么时候」，如果答不上来，就是有风险。怎么规避：按前面说的季度演练节奏执行，并且演练必须用真实脚本、真实流程，不许手工补步骤。

翻车六：备份空间满了，静默失败还没有告警

问题：备份盘写满了，任务每天报错，但没人看；或者更糟，任务「成功」了但写进去的是空文件。为什么坑：备份是最容易静默失败的系统之一——它不影响线上业务，没人会主动发现，直到需要恢复那天。怎么判断：你的备份系统有没有独立的告警通道？告警发给谁？有没有人认领？怎么规避：监控三件事——最近一次成功备份的时间、备份产物大小的变化趋势、目标存储的剩余容量。容量低于阈值和超过预期时间没有新备份，都要立刻告警到具体的人，而不是发到一个没人看的群里。

常见问题 / FAQ

Q1：快照和备份到底是不是一回事？我开了自动快照还需要做备份吗？

A1：不是一回事，而且必须两个都做。快照是块级指针留档，和原卷在同一套存储上，回滚快但扛不住存储故障和机房事故，也保证不了数据库一致性；备份是数据本身的副本，能被搬走、能长期留、能跨云恢复，代价是恢复慢。把快照当备份，等于把撤销键当保险箱——平时没事，出事那天就知道差别了。自动快照该开，它是应对误操作最快的东西；但它只能当第一道防线，数据这一层还得靠文件级或数据库级备份加异地副本兜底。

Q2：自动快照应该多久打一次？有没有一个通用的推荐值？

A2：没有通用值，得按 RPO 反推。先问业务能接受丢多少数据：企业官网、内容站这类一天更新不了几次的，一天一份保留七天足够；有订单、有用户注册的电商和 SaaS，至少要小时级快照，还得开数据库 binlog 归档做时点恢复；涉及资金流水的，RPO 要压到分钟级，这时候主力已经是持续归档而不是快照了。判断方法很简单——把「最多能丢多少数据」换成钱，再决定花多少钱。快照频率越高、保留越久，成本和 IO 开销都往上走，不是越高越好。

Q3：快照保留几份、保留几天合适？成本会不会失控？

A3：建议分层。最近 24 小时内每 1–4 小时一份、保留 6–8 份，用来应对误操作和刚发生的加密破坏；再往后每天一份保留 7–14 天；超过两周的长期留存不要用快照做，换成文件级备份丢对象存储，成本能差一个数量级。成本方面要明白：快照虽是增量，但增量会累积。保留 30 天的费用通常不是 7 天的四倍，可能更高，因为越老的快照与当前数据差异越大。配完之后隔一个月看一次账单，按实际增长曲线调策略。

Q4：为什么快照回滚后机器能开机，数据库却起不来？是快照坏了吗？

A4：绝大多数情况快照没坏，是数据库处在「半截状态」被留住了。打快照那一刻，可能内存里还有事务没刷盘、redo log 写了一半、数据文件改了但索引没更新完。磁盘块的状态被完整保留，保留的正好是一个应用不可用的瞬间。MySQL 启动做崩溃恢复，运气好自愈，运气不好就卡死报错。解法有三层：打快照前 fsfreeze 冻结文件系统；让数据库先进入一致状态（MySQL 锁表刷盘或用 xtrabackup，PostgreSQL 用 pg_backup_start/stop）；再配合 binlog 或 WAL 归档做时点恢复，把 RPO 压到分钟级。

Q5：3-2-1 原则里的「异地」，一定要跨城市吗？同城两个机房算不算？

A5：看你要对抗什么风险。同城不同机房能扛住单机房断电、单阵列故障，但扛不住区域性灾害和城市级网络中断。所以严格意义上「异地」指跨地域，至少是不同的城市或大区。同时还要看独立性——如果两地用的是同一套账号体系、同一条自动化运维通道，面对误操作和勒索软件的防护能力会大打折扣。理想状态是异地那份用独立凭证，最好配合不可变存储，让它在保留期内删不掉。需要说明的是，3-2-1 是行业通行的工程实践，不是法规强制要求。

Q6：跨境业务做异地副本，数据出境有什么要注意的？

A6：关键是数据驻留。欧盟 GDPR 对个人数据的存储位置和跨境传输有明确约束，国内对数据出境也有相应的监管要求，涉及个人信息和重要数据的场景尤其要谨慎。这类要求更新快、行业细则差异大，具体的适用范围、申报义务与豁免条件，要以监管机构的最新要求和官方法规原文为准，必要时应咨询专业法律意见，别把技术文章当合规依据。工程侧能提前做的是：按敏感度给数据分类，明确每一类允许落哪些地域；传输走 TLS，落盘前本地加密，密钥单独保管，别和备份数据放一起。

Q7：恢复演练多久做一次？具体要验证什么？

A7：核心业务至少一个季度一次，次要业务半年一次；架构有变更（换存储、改备份脚本、迁机房）之后必须补一次。演练要拿出两个数字：RTO，从决定恢复到业务重新对外服务实际花了多少分钟，这个计时必须包含找备份、下载、导入、改配置、验证、切流量的全过程，只测导入是自欺欺人；RPO，恢复出来的数据最后一条记录是什么时间，和故障时间差多少，这个差值才是真实 RPO。还要有责任人、有书面记录（时间、场景、参与人、实测值、问题、改进项），并且「误删一张表」和「整个机房不可用」两种场景都要练。

Q8：备份空间满了会怎样？怎么提前发现这种静默失败？

A8：最坏的情况是任务每天报错没人看，或者更隐蔽——任务显示成功但写进去的是空文件。备份是最容易静默失败的系统，因为它不影响线上业务，没人会主动发现，直到需要恢复那天。要提前发现，至少监控三件事：最近一次成功备份的时间戳、备份产物大小的变化趋势、目标存储的剩余容量。设定两条硬告警——超过预期时间没有新备份、容量低于阈值——并且告警必须发到具体负责人，而不是丢进一个没人看的群。再补一条：备份账号只给写权限不给删除权限，能显著降低被一锅端的风险。

总结

回到标题那个问题：快照和镜像到底怎么配。我的结论很明确——把三件事放回各自的位置：系统盘快照当撤销键，镜像当复印机，文件级与数据库级备份加异地副本才是保险箱。只做本地快照的方案，在机房级事故和人为误删面前几乎没有抵抗力；把镜像当备份的方案，默认在丢一个月数据。这两类错误占了备份事故的绝大多数，而且完全可以提前避开。

配置顺序建议是这样：先用 RPO 反推自动快照周期，别拍脑袋定「每天一次」；再按分层思路定保留份数与天数，超过两周的长期留存交给对象存储；然后处理一致性，该 fsfreeze 就 fsfreeze，该开 binlog 归档就开，别指望裸快照能救数据库；接着补上异地副本，跨境业务还要先看清楚数据驻留的合规边界；恢复演练则必须排进日程，每季度一次，拿 RTO 和 RPO 两个数字说话，有记录有责任人。这五步做完，你的备份才算真正成立。

平台选择上，一万网络深耕 IDC 19 年（成立于 2007 年），官网明示免费提供系统盘每日 3 份快照与 30 秒回滚，节点覆盖大陆华南、华东、华北、华西以及中国香港、新加坡、日本、韩国、德国法兰克福、加拿大温哥华等方向，异地副本的落点选择余地比较充足。系统盘快照用它白送的这份就够，数据盘备份和异地副本则需要你自己搭起来——官网没有明示「一键异地灾备」这种打包能力，这部分不要想当然。

数据来源

• 一万网络（idc10000.net）官网公开页面：服务优势中明示的免费项（系统盘每日 3 份快照、30 秒回滚、网站备案、5–20G 流量防护、7×24 中文工单平均 5 分钟响应、硬件故障 10 分钟自动迁移），抓取时间 2026-09-17。
• 一万网络官网首页与产品页起步价：华西 ¥599、华东 ¥699、华南 ¥799、华北 ¥899、香港 ¥1500、欧洲 ¥1299、美洲 ¥1699、非洲 ¥899、对象存储 OSS ¥99 起，抓取时间 2026-09-17，以官网实时价为准。
• 一万网络裸金属产品线公示价：E5-2620 32G/1T ¥999、E5-2698v4×2 32G/1T ¥3999 起，抓取时间 2026-09-17，以官网实时价与签约报价为准。
• 一万网络地区节点公开事实：德国法兰克福数据中心接入 DE-CIX、KleyRex、TeliaSonera、Level 3；新加坡 Qala 机房接入 SingTel、PCCW、pacnet；韩国 KT、HT、ONSE、DACOM 机房；加拿大温哥华机房，均来自官网地区页原文，抓取时间 2026-09-17。
• 3-2-1 备份原则：行业通行的工程实践共识，非法律法规强制要求。
• 数据跨境与数据驻留合规要求：涉及欧盟 GDPR 及国内数据出境相关监管规定，具体适用范围、申报义务与豁免条件以监管机构最新要求与官方法规原文为准。
• 文中标注「需询价」「（预估）」的项目均为非官网明示项，实际以下单时核算与咨询报价为准；所有价格以签约时最新报价与合同为准。