我见过太多人栽在数据迁移上。去年有个做电商的朋友，趁着双十一前换服务器，结果迁移当天数据库锁死，订单页面直接白屏，客服电话被打爆，花了三天才把数据捞回来，大促的流量全便宜了竞对。还有个做设计的姑娘更惨，移动硬盘突然不识别，几年作品全没了，哭都来不及。数据这东西，平时感觉不到重量，一旦没了，才知道什么叫天塌下来。
迁移和备份，听起来像IT部门的事，但真到了关键时候，老板找的是你，客户骂的是你，数据丢了没人替你背锅。所以别指望“到时候再说”，得把这事儿当成喝水吃饭一样的基本功。今天这篇，不跟你扯那些玄乎的云原生、容灾架构，就讲人话，教你怎么在迁移和备份的时候，让业务像没断过气一样继续跑。
先说迁移。很多人一上来就想着“全量复制”，把老服务器上的东西一股脑拷到新机器上。听起来省事，但业务系统最怕的就是“复制完就切”。你复制的时候，新数据还在不断进来，等你拷完了，老库里又多了几千条订单，一切换，这些新数据就丢了。所以迁移的铁律是：先做全量同步，再做增量同步，选个业务低峰期，把增量也补完，再瞬间切换。这个过程叫“追平”，追不平就切，等于自己给自己埋雷。
还有个细节，很多人忽略：迁移前必须做“演练”。不是说你敲几个命令跑通了就叫演练，而是要把整个流程走一遍，包括回滚方案。你想想，万一切到新环境后，发现某个接口调不通，或者权限配错了，你能不能一分钟之内切回老系统？这个回滚路径，必须在迁移前就测试好。我见过最离谱的情况，是有人迁移前没测回滚，结果新环境有问题想退回，发现老环境的备份已经被覆盖了，直接陷入绝境。所以记住：没有回滚预案的迁移，都是耍流氓。
再聊备份。很多人觉得，备份不就是定时把数据库导出一下嘛。错了，备份的核心不是“存”，而是“能恢复”。你想想，你存了一百份备份，真出事的时候，发现最近的一份是三天前的，或者恢复的时候报错说文件损坏，那跟没备份有啥区别？真正靠谱的备份，得满足三个条件：一是频率够高，关键业务至少每天一次，甚至实时备份；二是存储要隔离，不能跟生产环境放在同一台机器上，不然机器烧了，备份也跟着没了；三是一定要定期演练恢复，每个月找一天，把备份拿出来，恢复到一台测试机器上，看看能不能正常跑起来。
我有个客户，公司做SaaS的，数据量不大但特别关键。他们之前一直用自建的脚本备份，觉得挺稳妥。结果有一次机房断电，硬盘坏了，他们从备份恢复，发现那个备份文件因为脚本有个bug，只写了一半，根本打不开。后来他们换成了云上的托管备份服务，还设置了跨地域复制，再也没出过这种幺蛾子。所以说，别迷信自己写的脚本，专业的工具和方案，该花钱就花钱，这钱比出事的赔偿便宜多了。
说到业务不停，这里有个关键技巧叫“灰度切换”。别指望一次性把全量流量切到新环境，那太冒险了。你可以先切一小部分用户过来，比如百分之五，让他们的请求走新系统，观察个半小时，看看日志有没有报错，监控有没有异常。没问题，再逐步放大比例，百分之二十、百分之五十、百分之百。这个过程虽然慢，但稳。一旦发现问题，可以立刻把切过来的流量再导回去，用户几乎无感知。这个策略，尤其适合Web服务、API接口这种可以动态路由的场景。
还有个容易踩的坑，是数据库的“双写”。有些系统需要在新旧环境同时运行一段时间，这时候就得考虑数据双写。但双写有个大坑：两边同时写，万一一边成功一边失败，数据就分叉了。所以双写一定要有校验机制，比如写完后对比两边的主键和版本号，不一致就告警。更稳妥的做法是，用消息队列做异步双写，先写主库，然后通过消息同步到备库，这样能减少强一致性的压力。但不管怎样，双写方案一定要有专人盯着，不能设完就撒手不管。
无论迁移还是备份，都离不开一件事：文档。你要把每一步操作、每一个命令、每一个配置文件都记录下来，包括当时为什么这么做，遇到什么问题怎么解决的。这不是为了应付检查，而是为了下次再遇到类似情况，你或者你的同事能照着文档快速操作，不用重新踩一遍坑。我见过太多团队，靠着一两个“核心骨干”的记忆撑着，人一走，系统就成黑盒了。文档化，是让业务持续跑下去的保障。
说到底，数据不丢，业务不停，靠的不是运气，是流程和习惯。迁移前做演练，备份后做恢复测试，切换时用灰度，操作时留文档。把这些动作变成肌肉记忆，你就再也不用半夜爬起来处理数据事故了。记住，每一次数据丢失，都不是“意外”，而是之前某个环节的偷懒。别等到丢了才后悔，现在就开始，给数据上一份保险。
