Azure 稳定实名号 Azure数据备份还原测试

各位正在给Azure环境做备份方案的同仁，先别急着点保存按钮——我上周刚把一台生产SQL Server VM的备份策略配得花团锦簇，结果真出事时，发现恢复脚本里藏着个Get-AzRecoveryServicesBackupItem参数写反了，愣是多花了三小时重跑。今天这篇，不讲PPT里的‘高可用’‘RPO/RTO’大词，就聊人话：怎么让Azure备份不变成你凌晨三点的噩梦。

Azure 稳定实名号 一、别信‘默认开启’这四个字

Azure控制台里那个‘启用备份’按钮，长得像巧克力糖纸一样诱人。但请记住：它只负责在VM上装代理，不自动选数据库、不自动设保留策略、更不帮你检查磁盘是否挂载成功。我们曾有台VM，系统盘备份正常，但D盘（存着SQL数据文件）压根没被识别——因为当初建盘时用了diskpart手工初始化，没打NTFS标签，Azure Backup Agent直接当‘哑盘’跳过了。解决方案？登录VM，执行：Get-PSDrive | Where-Object {$_.DisplayRoot -like "D:\*"} | ForEach-Object {chkdsk $_.Root /f}，再重启Agent服务。别笑，这事真发生过。

二、Vault不是保险柜，是调度中心

很多人建完Recovery Services Vault就以为万事大吉。错。Vault本质是个‘指挥所’，真正干活的是背后叫‘Backup Policy’的三个组件：备份频率（每4小时？每天？）、保留期（7天？90天？）、快照类型（应用一致性？崩溃一致性？）。重点来了：SQL Server必须选‘应用一致性快照’，否则还原后数据库大概率报0x80070005权限错误。为什么？因为崩溃快照只冻住磁盘I/O，SQL事务日志还在狂写。我们试过一次，还原后DB状态是‘RECOVERY_PENDING’，查日志发现LDF文件末尾缺了最后12KB提交记录——够喝一壶咖啡的时间来排查。

三、还原测试，不是点‘恢复’就完事

上周五下午，运维小张按流程做了次还原演练：选中昨天的备份点→点击‘恢复VM’→填新VM名→确认。两小时后，新VM起来，但他发现SSMS连不上SQL实例。抓包一看，端口1433根本没监听。原因？Azure还原VM时默认关掉所有自启动服务，包括SQL Server服务。解决方法：在还原前，进原VM运行Set-Service -Name "MSSQLSERVER" -StartupType Automatic；还原后，用Run Command远程执行Start-Service MSSQLSERVER。顺带说，别忘了检查防火墙规则——新VM的NSG默认拒绝所有入站，你得手动开1433端口。

四、文件级还原：比找初恋照片还费劲

客户发来需求：‘只要C:\inetpub\wwwroot\config.xml这个文件，不要整个VM’。听起来很合理对吧？Azure确实支持文件级还原，但操作链路堪比解密摩斯电码：
① 进Vault → ‘备份项’ → 找到对应VM → 点‘文件还原’；
② 下载那个6MB的‘恢复脚本.ps1’；
③ 用管理员权限打开PowerShell，执行脚本（注意：必须用生成脚本时的同一订阅ID，换账号会403）；
④ 脚本会拉起临时SMB共享，路径形如\\192.168.100.10\AzureBackupShare\...\config.xml；
⑤ 你得自己复制粘贴，且共享只存活12小时。
我们第一次做时，脚本里有个硬编码IP，而客户VNet用的是10.0.0.0/8网段，冲突了——临时改脚本里IP，加了行$ip = Get-NetIPAddress -AddressFamily IPv4 | Where-Object {$_.IPAddress -like "10.*"} | Select-Object -First 1 -ExpandProperty IPAddress才搞定。

五、跨区域还原：别让‘异地’变成‘异步地狱’

合规要求必须跨区域备份？恭喜你解锁地狱模式。Azure Site Recovery和Backup服务是两套体系，Backup的跨区还原需满足三个条件：源Vault所在区域必须支持‘备份存储冗余’（目前仅22个Region），目标区域要有同名Resource Group，且目标VM必须提前创建好相同大小的OS磁盘。最坑的是时间差：从东京备份，还原到法兰克福，光下载快照就得47分钟（实测），期间任何中断都会失败，且无法断点续传。我们的解法是：用AzCopy预热目标区域的Blob Storage，把备份文件分块同步过去，再用本地脚本调用Restore-AzRecoveryServicesBackupItem指定本地URI——省了28分钟。

六、5个血泪教训，写在你删掉测试资源之前

1. 别用‘标准存储’存备份：IO延迟高，快照合并时可能卡死，某次导致备份窗口超时，连续三天告警邮件轰炸；
2. SQL Server AlwaysOn集群要单独备份每个节点：主节点备份≠备节点可恢复，我们曾因漏备备节点，故障切换后发现日志链断了；
3. 每月1号记得检查Retention Policy：Azure不会提醒你‘已超期’，只会静默删除旧快照，有次审计发现最近3个月备份全没了；
4. VM关机状态下不能触发应用一致性快照：哪怕策略设了每小时一次，关机状态只会生成崩溃快照，这点文档藏得很深；
5. 还原后务必验证数据一致性：用DBCC CHECKDB WITH PHYSICAL_ONLY跑一遍，我们发现某次还原后索引页CRC校验失败，是快照传输时网络抖动导致的位翻转。

七、3条偷懒小技巧（老板不知道）

• 用Tag自动化绑定备份策略：给VM打tag BackupPolicy=SQL-Prod，然后写Automation Account Runbook，每天扫描tag匹配的VM并自动关联对应策略——再也不用手动点50台机器；
• 备份日志自动归档到Log Analytics：在Vault的‘诊断设置’里勾选‘AzureBackupReport’，用KQL查AzureDiagnostics | where Category == "AzureBackupReport" | summarize count() by OperationName, Status, Resource，能秒定位失败根源；
• 用ARM模板固化恢复流程：把restore.json模板里VM名称、VNet、NSG全参数化，CI/CD流水线里传参即可一键拉起测试环境，比手动点快5倍。

最后说句实在的：Azure备份不是魔法，是精密仪器。它不会替你思考业务逻辑，也不会原谅你漏掉的一个分号。上周我们还原成功后，团队聚餐点了顿火锅，我涮毛肚时突然想起——原来所谓‘容灾能力’，不过是把所有假设都推演成脚本，再把脚本跑成肌肉记忆。下次你点下‘恢复’按钮前，不妨默念三遍：快照时间戳对吗？应用服务启了吗？防火墙放行了吗？

毕竟，在云上，最贵的不是资源，是你重装系统时，客户发来的那句‘你们的数据，是不是丢了？’