上周五下午，公司突然断电，核心交换机重启后部分 VLAN 无法通信。问题出在配置丢失——虽然平时有定期备份，但没人真正验证过能不能用。这次事故让我意识到，备份不是终点，能恢复才是关键。
为什么要做恢复演练？
很多单位的“备份”只是把配置文件存进共享盘，连后缀名都懒得改。可真出事时才发现，备份的是半年前的老版本，或者根本没保存密码加密的部分。更离谱的是，有人拿华为设备的配置去还原到思科盒子上，当然跑不起来。
我见过最惊险的一次，是某医院做完升级回滚，发现备份里漏了防火墙策略，结果挂号系统对外暴露在公网整整两小时。
实战：模拟路由器配置丢失后的恢复
我们用一台旧版华三 MSR36-20 做测试。先手动修改 IP 地址让它脱离管理网段，模拟“失联”状态：
<H3C> system-view
<H3C> interface GigabitEthernet 0/0
<H3C-GigabitEthernet0/0> ip address 192.168.99.1 255.255.255.0
<H3C-GigabitEthernet0/0> quit此时从网管平台已经 ping 不通设备。接下来通过 Console 口接入，加载之前存好的配置文件：
<H3C> tftp get 192.168.1.100\config_bak.cfg startup-config
<H3C> reboot重启后接口恢复原 IP，业务也跟着回来了。整个过程不到八分钟，比重新配置快了一倍还多。
几个容易踩的坑
有一次我在虚拟化平台做演练，TFTP 服务器开了 Windows 防火墙，传输到一半中断，结果设备启动找不到配置文件直接进了初始化向导。后来才明白，自动化脚本得加上重试机制和校验步骤。
还有就是时间同步问题。某次恢复完发现日志时间错乱，排查半天才知道 NTP 配置被遗漏了，导致后续审计对不上。
建议每月搞一次“小灾难”
现在我们组固定每月第二个周三晚做一次演练。方式很简单：随机挑一台非核心设备，清空配置，然后用备份恢复。谁负责的设备谁来修，超时半小时算失败。
别觉得麻烦，等哪天光纤被挖断、机房进水的时候，你会感谢那个坚持做演练的自己。