服务器三种备份方式到底怎么选？快照、镜像、文件级备份一次讲清

一台跑了三年的服务器某天早上业务全量 500登上去一看数据库主表空了。运维第一反应是去控制台找快照然后发现最近一次成功的快照是 11 天前——自动快照策略两个月前就因为地域配额满了开始失败而失败这件事没有任何告警。这个场景里最讽刺的地方在于他确实做了备份。问题出在他把三种不同的东西当成了一种。快照、镜像、文件级备份解决的其实是三个不同的问题快照解决我刚才改错了想退回十分钟前镜像解决我要再开一台一模一样的机器文件级备份解决这台机器整个没了在服务器三种备份方式里只配第一种是最常见的做法也是最容易在真正出事那天被一次性击穿的做法。下面按这个顺序讲先分清三者差别再逐个说清楚每种方式的能力边界和坑最后给一份能照着配的组合。一、先分清快照、镜像、备份不是一回事很多人以为这三者只是备份的三种粒度其实不是——它们的数据存放在哪、生命周期跟谁绑定都不一样这决定了它们能防什么、防不了什么。快照镜像备份管的是什么某块云盘在某一时刻的数据块整台机器的系统环境操作系统 已装软件 配置独立于源盘的一份数据副本能不能直接开新机器不能能通常不能要先恢复成盘存在哪里一般与源盘同一套存储镜像服务一般存在对象存储等独立存储源盘删了它还活着吗一般跟着没在在典型场景变更前打个回滚点批量部署、跨地域还原防删库、防勒索、防地域故障一个很实用的判断口诀关心机器能不能起得来 → 用镜像关心数据能不能找回来 → 用备份关心刚才那一步能不能反悔 → 用快照至于服务器备份方法该怎么定本质上就是先回答我最怕的是哪种事故再往上配。二、方式一快照——最便宜的回滚点也最容易用错快照是三个里面成本最低、速度最快的也是被误解最深的。它的工作原理各家实现基本一致为云盘创建的第一份快照是全量快照备份当时盘上的所有数据块之后创建的都是增量快照只备份自上一份快照以来发生变化的数据块。增量快照虽然不存全量数据但会引用前面快照中未变化的数据块——所以拿任意一份快照回滚都能恢复出那个时间点的完整数据。这个引用关系很关键它带来两个反直觉的结果删掉中间某一份快照通常不会破坏其他快照的可用性具体合并行为各家不同见第六节。快照链的容量不等于各份快照大小之和也不等于盘的大小。坑一快照只保存已经落到盘上的数据。还在内存缓冲区里、没刷到磁盘的数据不会进快照Linux 下/run这类内存文件系统里的东西也不会。如果打了快照就以为万事大吉重启后才发现少了点什么多半是这个原因。稳妥做法是打快照前先执行sync把缓冲区刷下去数据库场景则要先把表锁成只读再打快照FLUSHTABLESWITHREADLOCK;-- 此时创建快照UNLOCKTABLES;坑二回滚是要停机的。至少在主流云平台上云盘回滚要求实例处于已停止状态。也就是说回滚这个动作本身意味着一次业务中断不是随手就能点的按钮。坑三换过系统盘老的系统盘快照就废了。更换操作系统后系统盘 ID 会变原有的系统盘快照无法再用于回滚。有些平台更直接——重装或切换操作系统后系统盘的快照会被自动删除数据盘快照不受影响。坑四删除云盘会带走它的快照。这点各家口径一致或相近。快照的生命周期是绑在源盘上的盘没了快照跟着没。坑五也是最致命的自动快照策略失败是静默的。开头那个故事就是这个坑。配额满、权限变更、地域限制都可能让定时任务连着失败几十天而没有一个人知道。给快照任务配一条失败告警比多保留 30 天快照有用得多。三、方式二镜像——拿来开新机器不是拿来回滚数据镜像常被当成更完整的快照这是个误会。它的定位是模板不是时间点。以 ECS 为例官方对两者区别的描述很清楚镜像可以直接用来创建实例快照不行快照只能用于当前实例云盘的数据恢复。而当你用实例创建自定义镜像时系统会为源实例的每块云盘系统盘和数据盘各一份创建快照这些快照的集合构成一份自定义镜像。这条机制解释了几条实操规则只有系统盘快照能创建自定义镜像数据盘快照不行共享快照也不行。想要镜像里带数据盘内容得在创建过程中手动勾选对应的数据盘快照。删快照时如果它关联着镜像得先删镜像。反过来删除自定义镜像时可以选择保留或删除对应的快照。原实例到期释放后由它的快照创建的自定义镜像不受影响。这条很实用——机器可以放掉镜像留着当存档。阿里云文档里明确提醒制作镜像前要清理敏感数据包括个人文件、密码、密钥、配置文件里的访问凭证。因为镜像是把当前机器整个打包.bash_history里那条带着 token 的 curl 命令也会一起进去之后每台用这个镜像开出来的机器都带着它。所以这套系统级的备份方式适合的是批量部署相同环境、跨可用区或跨地域还原系统、系统迁移。不适合当日常数据备份——每次都整盘打包频率上不去成本也不划算。四、方式三文件级备份——服务器备份到本地或另一台服务器这一层是唯一能在整台机器没了时还活得下来的那一层也是本地留存和跨机同步的主战场。最常用的是 rsync。一个基础的推送rsync-aAXv/data/ backup10.0.0.2:/backup/data/-a是归档模式保留权限、时间戳、软链接等-A保留 ACL-X保留扩展属性。这里有个能毁掉备份的参数--delete。它会让目标端跟源端保持严格一致源端误删的文件同步之后目标端也没了——这就是备份跟着一起被误删的经典路径。要用可以但请务必先跑一遍演练看清楚它会删什么rsync-aAXv--delete--dry-run /data/ backup10.0.0.2:/backup/data/确认输出里没有意外再去掉--dry-run真正执行。更稳的做法是不让新备份覆盖旧备份按日期分目录未变化的文件用硬链接复用rsync-aAX--link-dest/backup/data/$(date-dyesterday %F)\/data/ /backup/data/$(date%F)/这样每个日期目录看起来都是一份全量快照实际只多占变化部分的存储空间rm掉任意一天也不会影响其他天。这条正好对应服务器自动备份到另一台服务器的需求——目标机上留的是一串可回溯的历史版本而不是一份被反复覆盖的最新副本。数据库要单独处理靠文件拷贝是不行的拷出来的 InnoDB 文件大概率不一致mysqldump-uroot-p--single-transaction--routines--triggers\mydb/backup/mydb_$(date%F).sql几个参数不能省--single-transaction对 InnoDB 开一致性读事务导出期间不锁表业务照常写入。--routines --triggers这两个必须显式写否则存储过程和触发器不会进备份文件恢复时才会发现少了东西。备份期间不要跑 DDL。ALTER TABLE这类操作可能让 dump 直接报错中断。注意--single-transaction只对 InnoDB 有效如果库里还有 MyISAM 表那部分仍会被锁。想做时间点恢复再加--master-data2把 binlog 位点写进文件头部。最后说保留策略。只留最近 7 天是不够的——勒索软件和误操作往往不是当天发现的。业界通行的3-2-1 原则是至少3 份副本1 份生产 2 份备份、存放在2 种不同介质上、其中至少1 份在异地。顺带回答一个高频问题服务器备份软件哪个好用这个问题本身就问偏了。先确定你要防的是误删、是硬件故障、还是整地域故障场景清楚了该用 rsync、该用数据库导出、该上带版本管理的备份工具选择会自己浮出来。五、物理服务器备份Windows Server 服务器备份怎么做物理机没有虚拟化层帮忙拿不到云盘那种块级快照能用的手段要换个思路。Windows Server 自带 Windows Server Backup命令行是wbadminwbadmin start backup -backupTarget:E: -include:C:,D: -allCritical -systemState -quiet几条必须知道的规则-allCritical会把所有关键卷包含操作系统状态的那些卷打进备份只有加了它才能做裸机恢复。而且它必须和-backupTarget一起用单独用会直接失败。备份目标卷不能是被备份的卷之一。把 C: 备份到 C: 是不行的得挂一块独立的盘或指向远程共享。存到远程共享文件夹时同一台机器再备份一次会覆盖上一份。微软文档对此有明确警告如果备份中途失败你可能落得旧的被覆盖、新的又不可用的两头空局面。规避办法是在共享目录下按日期建子目录。默认是-vssCopy不更新文件历史记录不会打乱其他备份软件的增量链。别随手加-vssFull那会更新历史并可能截断日志。Linux 侧的物理机和云服务器内思路一致文件级同步 数据库导出 定时任务且异地必须有一份。定时任务建议用 systemd timer 而不是 crontab——前者可以声明对数据库服务的依赖重启后不会在数据库还没起来时就开始 dump。六、各家云平台快照和备份到底差在哪同样是叫快照各家实现细节差得挺远尤其是存哪儿和删盘之后还在不在这两件事。选平台或者做跨平台方案时这张表值得对着看。阿里云 ECS腾讯云 CBS华为云增量机制首份全量后续增量增量块引用前序快照的未变化块任一快照都能回滚出完整数据增量回滚时合并整条快照链相同位置的数据块取最新增量快照链容量按数据块的继承关系计算快照存哪创建后默认存入对象存储 OSS该 Bucket 用户不可见以冗余方式分布式存储在 COS存放在云硬盘所在的物理存储磁盘上不占用云硬盘空间独立备份服务云备份、归档快照快照跨地域复制云备份 CBR备份数据存 OBS与云硬盘分开存放删掉云盘后快照随云盘释放快照随云盘释放备份不会被删快照会被同时删除重装/切换操作系统更换系统盘后历史系统盘快照无法回滚新的系统盘—系统盘快照自动删除数据盘快照不受影响速度差异——创建和回滚快照比备份快备份因数据搬迁耗时更久有三条结论是可以直接用的快照和备份不是一回事别互相替代。备份数据与源盘分开存储源盘损坏甚至被删除后仍能恢复快照快、便宜、适合回滚但它跟源盘绑得更紧。只要防删盘/防地域故障是需求就得上独立备份服务光靠快照策略覆盖不了这个场景。跨地域复制是灾难恢复的分水岭。快照解决误操作跨地域副本解决站点级故障两者不能省掉一个。相关官方文档阿里云镜像概述含镜像与快照的完整区别表、腾讯云快照原理、华为云备份、快照、镜像有什么区别。七、一份能照着配的备份组合前面把三种方式拆开讲这一节把它们拼回去。服务器三种备份方式不是三选一而是按频率和责任分层各管各的。先明确两个指标不谈这两个数字谈备份都是空的RPO恢复点目标能容忍丢多久的数据。每天一次全量RPO 就是 24 小时。RTO恢复时间目标能容忍多久恢复服务。有了这两个数配置就定了。一份中小规模业务的常见组合要保护的对象手段频率保留系统盘环境自定义镜像每次重大变更后手工做一次最近 2-3 个版本数据盘自动快照策略每天 1 次低峰期7 天数据库mysqldump 异地 rsync每天全量binlog 留着做 PITR30 天配置与代码git 仓库 异地同步每次变更全历史整体快照任务失败告警实时—最后一条最容易被跳过但它决定前面四条的生死恢复演练。没验证过能恢复的备份等于没有备份。至少每季度做一次完整的恢复测试——用快照创建一块新盘挂到测试机上看看数据对不对把 dump 出来的 SQL 真的导进一个空库跑一遍。这步做了前面所有配置才算数。回到开头那台服务器。他缺的不是备份工具是分类把改错了能反悔和机器没了能重建当成了一件事于是只配了自动快照。服务器三种备份方式里快照是回滚点镜像是模板文件级备份是最后一道防线——分清楚各自防什么比把任何一种做到极致都重要。各平台的机制、配额与计费会随时间调整具体以各家官网当期公示的文档为准。