服务器备份到底该怎么做？从"备了"到"能恢复"差多远

服务器出事，最让人崩溃的从来不是"没有备份"，是"明明备了，恢复的时候才发现不管用"。

盘坏了，翻出备份一看，和坏盘在同一个机柜的同一台机器上，一起走的；中了勒索，备份目录因为和线上保持同步，被一起加密了；数据库坏了，dump 文件拉出来是半年前的——备份任务早就静默失败了几个月，没人知道；最冤的一种：备份好好的，恢复步骤没人说得清，试着恢复了四个小时还没起来，业务干等着。

备份这件事，90% 的功夫花在"备"上，可它的价值 100% 体现在"恢复"上。这篇文章就把灾备这件事按实战的顺序讲清楚：备什么、怎么备、放哪里、怎么验证——每一步都是能落地检查的。

一、先想清楚两个数：能丢多少，能停多久

动手之前先回答两个问题，答案决定了备份方案怎么做：

第一个：能接受丢多少数据？是丢一天可以接受，还是最多丢一小时？数据库里挂着客户订单和生产记录，多数厂子的答案是"最多丢十几分钟到一小时"。这个答案直接决定备份频率——天天备一次的方案，最坏情况要丢一整天的数据，和"最多丢一小时"的要求对不上。

第二个：能接受停多久？业务系统瘫了，半天内恢复可以吗？还是要分钟级拉起？答案决定方案里要不要留"最后一道底牌"（比如整盘镜像、随时可切换的备用机）。

把这两个数写在纸上，备份方案就不容易跑偏。所有后面讲的方法，都是围绕"丢得起多少、停得起多久"这两个约束来配的——脱离这两个数谈备份，容易变成"天天全量拷一遍"的自我安慰。

举个常见的取法，对上了就对号入座：一家二三十人的机加工厂，业务系统是订单、工单和生产记录，老板的底线是"丢一上午的数据没法向客户交代，停一天生意没法做"。倒推出来就是：数据库至少每小时留一个恢复点（上日志归档），文件数据每天同步一次，整机故障时四小时内恢复（所以要有另一台能顶上的机器和一份够新的备份）。这两个数定了，后面每一层方案都是在兑现它们——备份频率、保留策略、演练周期，全部跟着这两个数走。反过来，如果一家厂的答案是"这批数据丢了可以重新录，停三天也无所谓"，那方案可以简单到每周一份全量加一份异地，没必要上重装备。方案没有标准答案，只有和业务对不对得上。

二、备份什么：数据、配置，还有那些容易漏的

很多厂的备份只做了一件事：把数据库导一份。等真要恢复的时候，才发现缺的东西一箩筐。一份完整的清单要分三类：

第一类：业务数据——最核心，但备法有讲究。

数据库必须用官方导出工具做逻辑备份（PostgreSQL 用 pg_dump，MySQL 用 mysqldump），不要直接拷贝数据目录。数据库在运行时数据文件处于不断变化的状态，直接拷下来的是一份"前后不一致"的文件，恢复时轻则报错重则起不来。要物理级备份，也得先做快照冻结再拷（后面讲）。

除了数据库，还有文件类数据：上传的图纸、附件、图片。这些通常散在某个目录下，逐个确认、列进清单。

第二类：配置——丢了最耗时的一类。

系统装回来只要一小时，但配置调回来可能要三天。要备份的有：/etc 下改过的配置（nginx、防火墙规则）、crontab 定时任务、systemd 自定义服务单元、SSL 证书和私钥、SSH 的 authorized_keys、应用的配置文件和环境变量（注意：含密码的文件要加密存放）。

第三类：运行环境——恢复提速的关键。

代码的版本、运行时版本、依赖清单、容器编排文件。恢复的时候最怕"装了个新版本，跑不起来"，把版本信息记下来（或用容器固化），恢复时间能省一大半。

反过来说，也有些东西不用备：日志（留够时长即可）、缓存、临时文件。清单分清轻重，备份的体积和耗时才控得住——这也是很多厂的备份任务最后因为磁盘撑爆而悄悄失败的原因。

三、怎么备：方法选对，别拿一把锤子拧所有螺丝

1. 全量和增量的搭配。

全量备份恢复最简单（一份文件搞定），但体积大、耗时长；增量只备份变化，省空间，但恢复时要按顺序叠加。实战里的常见搭配是：每周一次全量 + 每天增量，保留策略用阶梯——最近 7 天都有、最近 4 周每周留一份、最近 12 个月每月留一份。保留多份的意义不止是防丢，更是防"坏版本覆盖好版本"：数据某天被误删了，第二天备份把"删完的状态"覆盖上去，如果只有一份备份，错误就成了永久。

2. 文件级同步：rsync。

目录类数据（附件、配置、代码）的主力工具。增量传输、可排除指定目录，配合 --link-dest 参数还能做出"每天一份快照、但重复文件不占空间"的效果。注意一条：rsync 的 --delete 参数慎用——线上误删了文件，带 --delete 的同步会把备份里的也删掉，这就是"同步盘不是备份"的典型翻车点。

3. 数据库的一致性：先快照再拷。

既要物理级速度、又要一致性，用 LVM 快照（或云盘快照）：先给卷打快照，把数据库"冻"在一个一致的时间点，再从快照里拷。数据库另有细法：开启 binlog/WAL 归档后，定时 dump 加上日志回放，可以恢复到一天的任意时刻——这对"误删了一张表想找回"的场景是救命的。

4. 整盘镜像：最后的底牌。

dd 整盘镜像能在新硬盘上原样复原整个系统，适合作为低频的兜底（比如每季度一次），不适合天天做——慢、占空间，而且系统在运行时镜像同样有一致性问题，要在维护窗口或配合快照做。

5. 云服务器的快照：方便，但别只靠它。

云平台快照一键开启，确实省事。但要看清它的边界：快照通常和主机在同一个云账户、同一个地域里——账户被盗、地域级故障、快照策略被误关，快照就一起没了。云快照可以作为方案的一层，不能是全部。

6. 自动化与告警：静默失败最危险。

所有备份任务交给 crontab 或 systemd timer 定时跑，但必须配告警：任务失败、输出文件比预期小很多、连续几天没有新文件，都要能主动通知到人。一个没人盯的备份任务，失败三个月是常态——开头说的"dump 是半年前的"就是这么来的。

把这些拼起来，一套典型的小厂方案大概长这样：

凌晨一点，数据库定时导出（全量 dump），导完检查文件大小是否符合预期，异常就发通知；凌晨两点，文件目录增量同步到备份机，只增不删；凌晨三点，把当夜的 dump 和变动文件推到异地对象存储，开版本控制；每周五，拷一份当周全量到离线硬盘，拔下锁柜；每月第一个周六，轻量演练：把最近的 dump 在测试环境导一遍，看数据对不对；每季度，完整演练：另起一台机器，从备份把整套系统恢复起来，记录耗时。

一行任务清单贴在服务器边上，每一步谁负责、失败了找谁，写得清清楚楚——灾备这件事的全部难度，其实不在技术，在于有人对它负责、有人定期看它一眼。

四、存哪里：3-2-1 原则和防勒索

3-2-1 一句话讲完：重要数据留 3 份副本，放在 2 种不同介质上，其中 1 份在异地。

落到小厂的实况，大概是这样：

第 1 份：本机另一块盘/另一目录——防手滑误删，防不了整机故障；第 2 份：另一台机器（同机房的备用机或 NAS）——防单机故障；第 3 份：异地——同步到另一台异地服务器，或推到对象存储（rclone 一条命令的事，成本一个月几块钱）。

防勒索是 3-2-1 的灵魂，两条硬规矩：

其一，备份账号的权限要单向。线上机器往备份端写数据可以，反过来备份端对线上"只增不删"——勒索软件拿到线上机器的权限后，第一件事就是顺着连接把备份一起加密或清掉。对象存储开版本控制、备份目录权限收紧、备份账号不给删除权，都是这个思路。

其二，留一份够不着的。定期（比如每周）把关键数据拷到一块离线硬盘上，拷完拔下来锁柜子里。离线介质是勒索软件和误删都够不到的终点——它不联网、不挂载，谁也加密不了它。

五、没验证过恢复的备份，等于没有备份

这是整篇文章最重要的一节。

备份文件躺在那里，不代表能恢复。文件损坏、密码失传、版本对不上、缺了证书、恢复步骤没人会——每一种都得在真出事前发现。所以要定期做恢复演练，做法不复杂：

第一步，选个低峰期，找另一台机器（哪怕是台旧电脑或临时开的云主机），把最近一份备份完整恢复一遍。

第二步，恢复完真把系统拉起来：服务能启动、页面能打开、登录进得去。

第三步，抽查数据：看最新的记录在不在、对不对——恢复到三天前的数据是"技术上成功、业务上失败"。

第四步，记录耗时：从开始恢复到业务可用花了多久，这就是你真实的"停机时长"。平时演练要两小时，出事时只多不少——心里有这个数，才知道该把演练周期缩短还是方案加码。

演练十有八九会暴露问题，常见的有：dump 文件其实早已损坏、数据库密码只有离职员工知道、新版本依赖和老备份对不上、证书私钥没备份过。每一个问题在演练里发现，成本是一下午；在事故里发现，代价是业务停几天。

最后，把恢复步骤写成一张纸：按什么顺序起哪些服务、密码和密钥放在哪、找谁确认。半夜出事的时候，没人有空翻五十页文档。

给没做过演练的厂一个预期：第一次演练几乎必然卡壳，而且卡的往往不是备份文件本身。常见的是这一串——拿到备份文件后发现解压密码只有离职网管知道；数据库导进去了，应用连不上，因为配置文件里写的还是老机器的地址；服务起来了，页面打不开，证书私钥没备过；终于都通了，一查数据，恢复到的是五天前的备份，中间四天的备份任务早失败了。一整串问题暴露下来，一下午就过去了——但这恰恰是演练的价值：这些雷，每一个都可能在真出事的那天把恢复时间从小时级拖成天级。第一次演练过后，把暴露的问题逐条修掉，第二次就会顺很多；到第三次，两小时内从零恢复到业务可用，这套备份才算真正立住了。

六、最常见的几个误区

"备份放在服务器另一块盘上就安全了。"机器被偷、主板烧了、勒索加密整个系统，另一块盘一起没。副本必须在另一台机器上。

"云主机开了快照就不用做备份了。"快照在同账户同地域，账户失守或误操作都可能一起没；而且快照不等于可独立拉起的恢复点。快照是一层，不是方案。

"备份任务还在跑就说明没问题。"任务在跑不等于备份成功——磁盘满了它可能天天失败，导出文件可能只有几百字节。要看结果和告警，不看任务存在。

"把数据目录拷一份就是备了数据库。"运行中的数据库直接拷文件，恢复时大概率起不来。用官方导出工具，或先快照再拷。

"同步盘/网盘就是备份。"同步是镜像：线上误删、被加密，同步端跟着变。同步可以有，但必须另有版本化的、单向的备份。

"保留越多份越好。"没有阶梯策略的无限保留，最后磁盘撑爆、任务失败，反而害了整个备份体系。按 7 天/4 周/12 月的阶梯来。

"等这阵子忙完再弄备份。"备份的价值在出事前就体现——你永远不知道出事是哪天，而数据坏了没有"下一次"。

七、这事可以交给专业的人做

灾备搭建是典型的一次性短期项目：先按业务定"能丢多少、停多久"两个数，再出方案（备什么、怎么备、放哪里、保留策略），然后落地配置、做一轮完整恢复演练，最后交付一页恢复手册——有明确的起点和终点，做完验收。

我们摩杰斯自己的核心业务系统（生产管理软件）十四年来一直跑在 Linux 上，备份和恢复这套东西在几百家制造客户的现场一台台搭过、验过。我们做灾备就按本文的顺序来：先定两个数，再配三层副本，最后用一场真刀真枪的恢复演练收尾——备份靠不靠谱，不看备份了没有，看恢复那天行不行。

想了解为什么生产系统值得建在 Linux 上，可以看《系统为什么从第一天就跑在 Linux 上》；半夜宕机怎么分钟级拉起，可以看《产线系统半夜宕机怎么分钟级拉起》；服务器被黑了先做什么，可以看《Linux 服务器安全加固与入侵应急》——备份是那次处置里"最后一道防线"的展开篇。灾备搭建这类短期项目的服务范围，见Linux 服务器服务介绍。

结语

备份这件事，说穿了就是三句话：

备什么想周全——数据、配置、环境三类列清单，数据库用导出工具不拷目录；放在哪里想清楚——3-2-1 分层，备份端单向可写，留一份离线的；恢复这件事练过——没演练过的备份等于没有备份，演练发现的每个问题都是提前拆掉的雷。

服务器和数据没有"平安无事"的默认值，只有"出事那天你手里有什么"。备份是唯一一件现在做、将来才用得上，而且用得上时一切都来不及补的事——它值得排进这个月的日程，而不是躺在"等有空"里。