数据恢复这件事，备份策略没做好再多工具也白搭

硬盘挂掉的那一刻，大多数人第一个反应是找恢复工具。真正的问题在于，数据能不能救回来，往往在故障发生之前就已经决定了。如果一台机器上跑着数据库、又只有单盘、又没做快照，那数据恢复的成功率就基本交给了运气。这篇文章想聊的是：在租服务器、配存储的时候，怎么把「恢复能力」当成一项配置去选，而不是等出事之后再补。

先分清两种故障：逻辑损坏和物理损坏

逻辑损坏指的是文件被误删、分区表被写坏、数据库事务日志损坏，磁盘本身还是好的。这类情况下，数据大概率还在扇区上，只是文件系统不认识它了。处理方式通常是立刻停止对这块盘的写入，把盘挂到另一台机器上做只读镜像，再在镜像上跑恢复。

物理损坏是另一回事。磁头异响、SSD 主控掉盘、RAID 阵列里坏了两块以上，这些情况自己折腾只会让情况更糟。开盘换磁头需要在无尘环境里做，普通机房不具备这个条件，硬试的结果往往是盘片被划伤，原本能救的数据也救不回来了。

我一般会先问一个问题：这块盘上跑的是业务库还是冷数据？业务库要的是尽快切到备用节点恢复服务，冷数据可以慢慢救。这两条路的处理顺序完全不同，混在一起想只会耽误时间。

真正管用的不是恢复工具，是故障前就存在的副本

恢复工具解决的是「已经坏了怎么办」，备份解决的是「坏了也不怕」。后者才是能提前花钱买到的确定性。行业里常说的 3-2-1 原则，落到租服务器的场景里是这样：

• 至少 3 份数据副本，一份在生产机，一份在同机房另一台机器，一份在异地；
• 至少 2 种不同介质或存储形态，比如本地 SSD 加对象存储；
• 至少 1 份放在异地机房，防的是整机房级别的故障。

成本差在哪？同一机房做副本，内网传输基本不花钱，延迟通常在 1ms 以内，快照可以做到每小时一次。异地副本就贵了，跨区域传输要算流量，延迟通常几十毫秒，适合每天或每几小时同步一次。我的取舍是：核心交易库同机房高频快照加异地每日全量，日志类数据只做异地每日增量，能省下不少带宽钱。

快照便宜但有边界，别把它当成备份

快照的好处是快、占空间小、回滚只要几十秒。但它有个致命边界：快照和源数据通常存在同一套存储上。存储本身挂了，快照跟着一起没。所以快照能防误删、防程序写错数据，防不了硬件整体报废。

这就是为什么我会把快照和备份分开配置。快照留着做日常回滚，真正意义上的备份必须落到另一台物理设备上。租一台低配独立服务器专门跑备份节点，比在生产机上堆硬盘更靠谱，因为它和主业务不共享电源、不共享 RAID 控制器。

如果业务本身有合规要求，备份节点的机房位置也要提前想清楚。数据出境涉及合规，备份放哪里不是纯技术问题。

自建备份节点要花多少钱

备份节点对 CPU 要求不高，对磁盘容量和网络带宽要求高。一台 E5-2630L 双路、32G 内存、20M 带宽的机器，月付大致在 139 美元这个量级，跑 rsync 增量同步和定期全量完全够用。放在东京机房的话，到国内沿海的延迟通常在 40~60ms，做每日同步没问题。

如果数据量特别大、又要求备份节点本身有冗余带宽，可以考虑法兰克福那种 10G 口的大带宽机型，E5-2683v4 双路配 128G 内存，月付 2309 美元。这个价位适合已经有明确合规或跨境数据需求的情况，普通业务用不上，硬上就是浪费钱。

需要多节点同步、又在意国内访问速度的，可以看看 日本东京服务器4，E5-2630L*2 配 32G 内存和 20M 带宽，月付 139 美元。对中小团队来说，这个价位的机器专门做备份节点，比在生产机上加硬盘划算，因为故障域是分开的。

最后给个能直接执行的判断：数据丢了不影响收入的，快照够用，不用额外花钱；数据丢了当天就损失订单的，必须配异地副本，预算按生产机成本的 20%~30% 留；数据涉及合规留存的，备份机房位置要单独评估，别默认跟生产机放一起。备份这件事，花的是小钱，省下的是整台机器都换不回来的东西。