服务器做快照怎么做：存本地还是云盘

快照存本地还是云盘，我一般先看这台机器丢了数据以后多久能重建。服务器做快照怎么做，得分两层看，一层是快照怎么拍，一层是拍完的东西放哪儿。混在一起想，人就容易绕进去。多数人纠结的压根不是技术，是那份保险买多贵。

服务器做快照怎么做的两种存法

本地的玩法，绕不开卷管理那套。LVM 上一条 lvcreate -s 就能切出快照卷，底层是写时复制：改过的块才搬走，没动的块还指回原来那块盘。云盘就简单粗暴些。控制台点一下，快照落到后端一套独立存储里，跟这台云主机已经解绑。机器删了，快照还在呢。名字一样，性子完全不同。

先说不绑机器这件事。

本地快照的命和母盘绑在一起。母盘所在的物理盘出坏道、阵列掉一块盘，快照跟着一起完蛋。机房我见过硬盘灯常红还硬扛着的，最后快照卷和源卷一起打不开，谁都救不回来。省下的那点钱，全赔进去了。

本地盘那点速度，最容易骗人

本地快照回滚是真的快。

回滚一个几十 G 的卷，本地可能几分钟就完事。云盘那边呢，得先下载、校验，再写回，慢一截是常态。具体差多少，跟带宽和快照体积都有关系，我真没法给准数。你拿自己的机器跑一遍，比看我写十遍都强吧。慢不是问题，慢能等；怕就怕回滚到一半，发现快照本身是坏的，那就没得等了。

同一块盘上别堆快照。

写时复制不等于不占空间。你在源卷上使劲写，快照卷跟着涨，涨到把存储池撑满，母卷直接变只读，这坑在测试环境里我干过不止一次，全是图省事没配监控。df 和 lvs 隔三差五看一眼就好，比事后拍大腿强。

别把快照当成备份用

快照和备份经常被混着叫。快照是那个时间点的一张照片，让你能回去；备份是另一份独立的复制，原件没了还能拿出来用啊。放在同一套存储上的快照，本质还是同一份数据的另一个视角，母盘一坏一起没。云盘快照虽然是存在别处，可同一家云同一个区域出了问题，风险还是共担的嘛。真要紧的业务，我一般会再往异地或者对象存储丢一份导出的备份文件，慢是慢点，踏实呗。

云盘快照贵在哪，值不值

云盘快照一般按增量存，第一份是全量，后面只记改动过的块，删掉中间某一份也能重新算出完整镜像，所以保留十几份并不一定是十几倍的钱。怎么计费、免费额度多少、保留多久，各家差别不小，以服务商控制台或官方文档写明的口径为准，别听人转述。

买的是那份解绑。

机器被误删、账号被人登进去清了一遍、整台宿主机出事，这些场景下本地快照一点用没有，只有躺在别处的快照能救命。所以我的做法很土：本地留一两天高频快照应付手滑，云盘那边拉长到周级别，两边都留，谁也不指望谁。钱花在这儿不算浪费，比事后到处问数据恢复的报价便宜得多，那报价我听过一次，没敢细问。

数据库机器不能只靠块级快照

跑 MySQL 的机器，块级快照拍下来不一定能直接起。InnoDB 的脏页还在内存里没落盘，你咔嚓一下拍完，恢复出来的库可能得做崩溃恢复，运气不好直接报错。我一般这么干：先 fsfreeze -f /data 把文件系统冻住，拍完再 fsfreeze -u /data 解冻，冻的窗口越短越好；或者干脆 mysqldump –single-transaction 导一份逻辑备份，跟快照摆在一起。

两条腿走路。

逻辑备份能挑单表恢复，快照能整机回滚，用途不一样。有人只留快照，等到要捞一张表的时候才发现没处下手，只能把整台机器回滚到某个时间点，别的业务跟着一起倒退，这账算下来比多存一份 dump 贵多了。

回滚这件事，得提前演练

快照最容易出岔子的地方不在拍，在恢复。我给自己定的规矩是：新机器上第一次配快照策略，先恢复到一台临时实例，把服务起起来，挨个接口点一遍，再删掉。没演练过的快照，我按没有算。

先测，再信。

演练得看几处：文件系统 fsck 有没有报错、数据库能不能正常启动、应用的连接串指向哪儿、证书和密钥文件在不在。恢复出来的机器 IP 变了，有些程序写死了地址就起不来，这些坑要在演练里露出来，别等真出事才骂人。

我自己的保留节奏

策略这东西没有标准答案，我给个我常用的骨架：每天凌晨拍一份保留七份，每周再拍一份保留四份；每次发版、升级内核、动数据库结构之前手动拍一份，标注清楚改了什么，事后确认没问题再删。定时任务走云控制台的策略比 crontab 稳，crontab 会随着机器重装一起消失，人容易忘。

手动那份的命名别偷懒，「before-upgrade-2026xxxx」这种带上动作的最有用，三个月后你自己都记不住当时在干什么，一看名字就明白。监控上给存储用量留个告警阈值，快照把池子撑满这种事，报警比人靠谱。

回到最开始那个问题：本地还是云盘。我的答案是本地留短、云盘留长，数据库再补一份逻辑导出，然后一定要演练一次恢复。服务器做快照怎么做，技术上就那么几步，真正拉开差距的是你有没有想过「这玩意儿恢复出来到底能不能用」。拍的时候顺手，回滚的时候才知道疼。