服务器数据备份怎么做才安全

硬盘坏掉那天才发现最近一次备份是三个月前的，这种事故在运维群里几乎每个月都能见到一例。很多人以为把文件复制到另一块盘上就叫备份，等到系统盘崩了、库被误删、机房断电之后才知道，那条复制命令从来没成功跑完过。备份要做几份、放在几个地方、多久跑一次、多久演练一次恢复，这篇按能落地的顺序讲一遍，顺带说说入门小机器和大容量机械盘机型在备份里各能干什么。

备份失败通常坏在哪一步

备份最常坏在没人看结果这一环。定时任务跑了半年，管理面板里全是成功，真去翻目录才发现压缩包是 0 字节，原因是脚本把输出写进了同一个文件名，第二次运行时先清空再打包，磁盘一忙就只剩个空壳。这种问题不看内容只看状态是发现不了的，每天抽查一个包能不能解开，比设十条告警都直接。

第二类坏在只备了数据库文件没备程序。库里几十万条订单好好的，网站代码和那几份手改过的配置文件丢了，恢复时照样得从零搭环境。整站备份要包含代码目录、上传目录、数据库导出和 nginx、php 的配置，缺一样都得返工。

第三类坏在备份和业务待在同一台机器同一个目录。误删是最常见的情况，删库的命令一敲，备份文件跟着一起没；勒索软件加密也是从业务盘开始往下扫的。备份落在业务机本地盘上，等于把两个鸡蛋放进同一个篮子。

第四类坏在增量链条断了。第一天做了全量，之后七天都是增量，中间第三天的文件被挤掉，恢复时链条从断点往后全废。所以增量要配定期的新全量，七个增量加一个全量是最常见的节奏，链条越短越好恢复。

第五类坏在时间点选错。凌晨三点跑备份，业务正处在活动流量的低峰尾巴上，磁盘 IO 一压，前台响应肉眼可见地抖。放到凌晨四点或者干脆把数据库和文件分开跑，比硬挤在一个窗口里稳。这几条都不算新鲜，但真出事时挨个对照，能省掉一半的扯皮。

备份要放到别的机器和别的地方去

异地这一层不用想得太复杂。最低要求是备份不要和业务同机房，业务机整机掉了，同机房另一台机器还能救急；高一点的要求是跨城市甚至跨服务商，机房整体断网的场景虽然少见，碰上一次就够受。把冷备放在一台入门小机器上，一个月三百多块，存一个月的增量包绰绰有余，每天跑一次同步也不吃力，冷备这层最怕的是压根没买，图纸想得再细也顶不上一个能连上的地方，这类机器可以看看云途这边的入门档配置。

备份目标机的选法跟业务机不一样。它不需要高主频、不需要大带宽，只需要能装下几个月的增量并且读得动。机械盘的大容量档在这一点上比全固态划算，六 TB 的空间塞三个月的整站包仍有富余，顺序读写拷几百 G 也就是一两个小时的事，这类大容量机型的具体参数在这里能对得上，挑的时候别被高主频迷惑，容量和盘位才是要点，客服问清楚能不能加盘更省事，后面数据涨起来不用再折腾一次。

传输方式也得想清楚。用 rsync 走 ssh 加密通道，断点续传和增量比对都有；打包上传走对象存储也行，但对小团队来说多一套账号和费用要记。带宽小的机器别指望一小时搬完，先算清楚每天新增多少 G、链路能跑多少 M，再决定备份周期，比事后发现搬不完强，链路算术算错一次，代价是多付一个月的时间。

全量和增量怎么排

全量的频率取决于数据体积。整站几十 G 的站点一周一次全量就够，几百 G 的图片站拉到两周一次，把增量压得更频繁。全量和增量的比例得按每天的实际变更量来定。

增量按小时跑最实用。数据库每小时导一次逻辑备份，文件部分按内容比对同步，这样最坏情况丢一小时的数据，业务上基本能接受，再提高频率意义不大，数据变更没那么快。

数据库的备份方式要跟引擎匹配。InnoDB 用逻辑导出会锁表一段时间，量大时改用物理备份加日志归档，恢复到任意时间点都行，二进制日志要一起归档，缺了就只能回到整点。

文件增量别用时间戳硬比。时区、时钟漂移、跨机器同步都会让判断出错，用校验和或者同步工具的算法比对更稳，文件数多的站点尤其明显，误判一次就是一轮全量。

每次跑完写一行状态到独立的日志。成功与否、包多大、耗时多少，出问题先看这行，比翻一堆输出快得多，这行日志顺手接进监控面板，异常值一眼能看出来。

老包的清理要自动化。按保留策略清理，比如留七天的时增量加四周的全量，别靠人记得手动删，策略写进脚本，换人接手也不用问保留几天。

备份窗口和业务高峰错开。促销日、发版日单独排，宁可推迟一次备份，也别在流量最高的时候压磁盘，挪一小时的代价远小于前台抖半小时。

备份文件怎么不被删

备份目录的权限要单独管。跑业务的账号不该有删备份的权限，脚本用独立账号只写不删，清理交给另一条带白名单的任务，权限边界清楚，误操作的空间就小了一半，日记里也查得到是谁动的，责任到人这一步比权限本身更要紧，出了事也查得清边界在谁那儿。

防误删最有效的一招是加一层不可写窗口。文件写完立刻改成只读，七天内不许动，误删命令碰到只读文件会先报错，给人留一次反应的机会，这七天里想清理得先改权限，多一道手续就多一道保险，这条规则最好写进上线检查清单里，改权限这类动作本来就不该随手做，改完要留痕，谁改的、为什么改都记上。

勒索软件盯着的是可写的共享目录。备份机不要挂业务机的共享盘，走加密通道推过去，落地即只读，加密程序扫不到也改不了，即便账号被盗，最近几天的包也拿不走，这一层比任何杀毒软件都管用，备份机不挂共享盘是最低门槛，端口也别对外开放，只留一个源地址能连。

备份包的命名别只用日期。加上站点名、库名、大小和校验值，恢复时一眼能认出该用哪个，也能顺手发现异常小的包，恢复现场最容易拿错文件，规范命名能省十分钟，包里放一份清单文件更省事，解开就知道里面有啥，包大了传输中断也能对上号，恢复前先核对校验值，别拿个半截包去解压。

恢复演练怎么做

没演练过的备份只能算一种可能性。每隔一两个月挑一台闲置机器，按文档从零恢复一次，走完才敢说这套备份能用，演练机器不必和业务机同配置，能跑起来就算通过，演练用的机器提前备好账号和依赖包，免得当场装环境，演练拖成加班多半是因为环境没备好。

演练要计时。从拿到备份包到站点能访问，中间花了多久，这个数字决定了真出事时能不能扛住，超过预期就要么把流程再压短，要么接受更长的公告时间，公告时间这个词得提前跟老板对好，别等出事才吵，说清楚能接受多久，后面每一步都有依据。

演练要覆盖最坏情况。整机重装、数据库回滚到前一天、误删的目录从包里捞出来，这三种场景各练一次就够覆盖八成事故，练的时候按真实流程走，不要图省事跳过步骤，跳过的那一步往往就是出事时卡住的那一步，演练的意义就在这儿。

演练结束把缺的步骤补进文档。总会有一步在文档里没写，比如证书私钥放哪、定时任务表怎么还原、证书到期前怎么续，写清楚一次，后面接手的人少熬一晚，文档放在能被搜到的地方，不要存在个人网盘里，交接时按目录翻一遍就够。

演练时顺便验证备份机的容量和带宽。恢复要读全量再解压，空间不够会在中途停下，白等一场，把备份机剩余空间做成周报，比临时抱佛脚有用，容量到七成就该扩，别等到跑不动才想起来，扩容量比清老包麻烦得多。

便宜档和大容量档在备份里各干什么

三百多块的入门机型适合当异地冷备。它的作用只有一个：把每天的包接住，需要时能把数据拿回来，跑不动业务也无所谓，半夜掉线有人知道就行。

这类机器带宽和流量有限，别指望它同时干别的事。备份任务独占，跑完就闲在那，出故障的概率也低，顺手配一条掉线告警就更稳，掉线两小时没人知道，备份等于没做，告警发到手机上才算闭环。

大容量机械盘机型适合当主备份目标。六 TB 的空间能存好几个站点的多周全量，顺序读写快，容量单价低，选型时盯住容量和盘位，别为用不上的核数多付钱，备份机的处理器常年闲着，省下的预算加到盘位上更值。

它的短板是随机读写。真要在这类机器上跑数据库或者频繁读小文件会很难受，定位成仓库比定位成业务机合适，读写压力大的活儿别往它身上压，它的价值在容量和顺序速度上，拿它跑虚拟机属于用错地方。

两台机器的角色别混。业务机自己存一份快照应急，主备份落大容量机，异地再放一台小的，三层各有各的用，任何一层出问题都能顶上一段时间，不至于当天就抓瞎，三层备份的说法听着老套，真出事时全靠它撑着，分开存放是最便宜的保险。

三个层次的成本加起来往往不到业务机的一半。这笔钱花在能拿回数据的地方，比花在更快的处理器上实在，备份这事省不得，能拿回数据才算真做过备份，演练过一遍才算数。