干这行十几年，最怕听到的一句话就是“数据库挂了”。不管是凌晨两点的电话，还是领导站在身后的那句“数据能找回来吗”，那一刻的心跳加速，比跑完五公里还剧烈。sqlserver作为企业级数据库的老大哥，平时稳如老狗，可一旦出幺蛾子，恢复手段就是你的救命稻草。今天不聊玄乎的理论，直接说人话，把那些真正管用的恢复路径掰开揉碎讲清楚。
第一件事，先分清“软故障”和“硬故障”。软故障好说，比如误删了表、更新语句忘加where条件、或者事务日志爆满导致数据库进入恢复挂起状态。这类问题，大多数时候靠备份就能解决。但前提是你得有备份，而且备份策略得靠谱。别笑，我见过太多公司，备份文件是有了，结果恢复的时候发现备份是坏的，或者日志链断了，那才叫欲哭无泪。所以，恢复的第一步永远不是技术，而是检查你的备份文件是否完整、是否可读。这个习惯，比任何高级技巧都值钱。
如果是误操作导致的数据丢失，而且时间窗口比较短，那最直接的办法就是利用事务日志做时间点恢复。sqlserver的日志文件记录了每一个事务的细节，只要你的数据库处于完整恢复模式，并且日志链没有断裂，理论上可以恢复到任意一个时间点。具体操作不复杂：先备份当前日志尾部，然后还原一次完整备份，接着还原差异备份，用STOPAT参数指定到误操作发生前的那一秒。关键在于，你得清楚自己大概是什么时候犯的错，时间点越精确，恢复的损失越小。这里有个坑，很多新手把STOPAT写成分秒不差，结果因为几毫秒的偏差，数据还是不对。建议留出30秒到1分钟的余量，多试几次。
但现实往往更残酷，很多公司压根没开完整恢复模式，或者备份策略混乱不堪。这时候遇到硬故障，比如磁盘阵列损坏、服务器突然断电导致物理文件损坏，那就得走另一条路了。sqlserver自带了一个工具叫DBCC CHECKDB，它可以检查数据库的物理和逻辑完整性。如果只是轻微的页损坏，用REPAIRALLOWDATALOSS选项尝试修复，但记住，这个操作有风险，它会删除损坏的数据页，所以能先备份就先备份，哪怕备份的是损坏的文件，也比没有强。修复完之后，立刻把数据导出到新库，别在原库上继续跑，那等于埋雷。
还有一种情况，整个mdf主数据文件损坏，连附加都附加不上。这时候别慌，先看看有没有ndf辅数据文件和ldf日志文件。如果日志文件还在，可以尝试创建同名同路径的新数据库，然后用替换文件的方式强行附加。具体做法是：新建一个同名数据库，停止服务，把损坏的mdf文件覆盖过去，再启动服务。sqlserver会尝试用日志文件重放事务，运气好的话能救回来一部分数据。这个方法不保证100%成功，但死马当活马医，总比直接放弃强。我实操过几次，成功率大概在三成左右，但救回来的数据，哪怕是部分表，也比重新录入强一百倍。
如果连文件都找不到了，那就得祭出终极武器——第三方恢复工具。市面上像Stellar Repair for MS SQL、ApexSQL Recover这类工具，专治各种疑难杂症。它们能直接扫描损坏的mdf文件，尝试提取表结构和数据。但这里要泼盆冷水，这类工具价格不菲，而且恢复出来的数据可能不完整，特别是遇到大字段、压缩字段或者索引失效的情况，效果会打折扣。所以，工具只能作为的手段，不能当常规武器用。而且用之前，一定把原文件做镜像备份，免得越修越烂。
说一千道一万，恢复的最高境界是根本不需要恢复。日常运维里，把备份策略做好，比什么都强。完整备份每天一次，差异备份每四小时一次，日志备份每十五分钟一次，这是最基本的黄金组合。还有，定期做恢复演练，别等到真出事了才第一次尝试还原。我见过太多公司，备份脚本写了三年，但从没跑过一次恢复测试，结果真到用时，不是权限不对，就是路径变了，还原失败。那种绝望，比数据库本身损坏更让人崩溃。
另外，千万别忘了检查msdb数据库里的备份历史记录。有时候你忘了备份文件放在哪，或者文件名太乱，但msdb里都记着。用RESTORE HEADERONLY FROM DISK = '路径'命令，能快速查看备份文件的元数据，包括备份时间、数据库名称、是否包含日志等信息。这招在排查“备份文件到底是不是我要的那个”时特别管用。还有个小技巧，把备份文件命名规则改成“数据库名备份类型日期时间.bak”，别用默认的纯数字，不然三个月后你自己都认不出来。
说句掏心窝子的话，数据库恢复这件事，七分靠预防，三分靠技术。你永远不知道下一次故障什么时候来，所以每一次操作前，先想清楚后果。更新数据前先备份，删除数据前先确认，修改表结构前先在测试库演练。这些习惯，比任何恢复技巧都重要。当然，如果你已经把前面的方法都看进去了，并且能熟练操作，那至少在面对故障时，心里有底，手上有招。sqlserver数据库恢复方法，说到底就是一套组合拳，备份、日志、工具、演练，缺一不可。
