说到恢复SQL数据库这事儿，我这两天正好帮朋友处理了一个类似的烂摊子。他公司有个老员工离职前，手一抖把订单表里的数据清了一半，备份文件倒是留了，但恢复的时候死活报错。我坐他旁边看了一个多小时，发现是他把完整备份和差异备份的顺序搞反了。这事儿让我想起来，很多人在恢复数据库时翻车，往往不是技术多深奥，而是基础操作没理清楚。SQL数据库恢复听着吓人，其实就像拆快递——你要是不知道哪个箱子先开，后面全得乱套。
先说说最常见的完整备份恢复。完整备份就像你给数据库拍了一张全身照，它记录了某个时间点的所有数据。恢复时，你只要把这张“照片”覆盖回去就行。但这里有个关键点——很多人以为备份文件拷进去就能用，结果发现数据库状态是“正在恢复”或“只读”。这其实是因为SQL Server默认会保持事务日志的连续性，你恢复完整备份后，后续还要加上差异备份和日志备份才能让数据库回到正常读写状态。我见过最离谱的案例是有人把完整备份恢复后，直接重启服务器，结果数据全丢了，因为事务日志没来得及应用。正确做法是先用RESTORE DATABASE命令加上NORECOVERY参数，这样数据库会停在“恢复待定”状态，等你后续操作。
接着聊差异备份。这个玩意儿很多人搞混，以为它和完整备份是并列关系。实际上，差异备份是完整备份的“补丁”——它只记录自上次完整备份以来所有变化的数据。恢复时，你必须先恢复完整备份，再按顺序恢复差异备份。比如你周一做了完整备份，周二周三各做了差异备份，那恢复时就得先恢复周一的完整备份，然后恢复周三的差异备份（而不是周二的）。因为差异备份是累积的，周三的备份已经包含了周二的所有变化。我有次帮一个电商客户恢复数据，他们误以为差异备份是独立的，结果恢复后订单状态全乱套，只能回滚到三天前的完整备份，损失了二十多万的交易记录。
事务日志备份是恢复的一块拼图。它记录的是两次备份之间所有的事务操作，比如插入、更新、删除。恢复时，你可以把数据库恢复到某个精确的时间点，比如“今天下午3点15分23秒”。这对误操作特别有用——假设有人下午4点删了一张表，你只要在恢复完整备份和差异备份后，应用4点之前的所有日志备份，再指定STOPAT参数到3点59分59秒，就能把数据救回来。但这里有个坑：日志备份必须连续。你如果周四早上删了日志备份文件，那周四下午的数据就永远找不回来了。我有个做金融的朋友就吃过这个亏，他们审计要求保留180天的日志，但运维图省事只留了30天，结果被监管罚了五十万。
说到恢复模式，很多人栽在简单恢复模式上。这个模式下，SQL Server会自动截断事务日志，意味着你只能恢复到最近一次完整备份或差异备份的时间点，无法恢复到任意时刻。很多小公司图省事用简单模式，结果数据丢了连后悔药都没得吃。我建议生产环境至少用完整恢复模式，虽然日志会膨胀得厉害，但关键时刻能救命。有个做SaaS的客户，他们数据库每天增长20GB日志，嫌占空间就改成简单模式，结果某天凌晨硬盘坏了，只能恢复到前一天备份，丢了8小时数据，用户投诉电话打爆了客服部。
实操中还有个常见问题：恢复时路径和文件名不对。SQL Server的数据库文件默认放在C盘Program Files下，但很多人备份文件放在D盘，恢复时忘了指定MOVE选项，结果报错“文件已存在”或“路径无效”。正确做法是在RESTORE命令里用WITH MOVE参数，把数据文件和日志文件重新定位到新路径。我处理过一个案例，客户把数据库从开发服务器迁移到生产服务器，两个服务器的盘符不一样，开发是E盘，生产是F盘。他直接用恢复命令没改路径，结果SQL Server一直找不到文件，折腾了两天才发现是路径问题。
提醒一句：恢复前一定要先检查备份文件的完整性。很多人拿到备份文件就恢复，结果恢复一半报错“备份集损坏”，那真是欲哭无泪。用RESTORE VERIFYONLY命令可以检查备份文件是否可读。我习惯在备份完成后，立马跑一遍这个命令，确认文件没问题再归档。另外，恢复时最好先在一台测试服务器上演练，确认步骤和数据正确后，再对生产库操作。我见过最惨的案例是有人直接在正式库上恢复，结果把新数据覆盖了，老数据也没救回来，只能从磁带备份重新折腾了三天三夜。
说到底，SQL数据库恢复不是玄学，是门手艺活。你只要把完整备份、差异备份、日志备份这三者的关系和顺序理清楚，再记住几个关键参数，基本就能应付90%的场景。但最核心的其实是备份策略本身——恢复做得再好，也不如备份做得扎实。我建议每个DBA都写个恢复手册，把步骤、参数、注意事项全列出来，遇到紧急情况照着手册操作，能少踩很多坑。毕竟，数据这玩意儿，丢了就是丢了，神仙也救不回来。
