干这行十年，最怕听到的一句话就是“数据库挂了”。尤其是SQL 2008 R2，这老伙计虽然稳定，但真要出点岔子，恢复起来能把人急出一身汗。今天就把这些年踩坑踩出来的恢复经验，掰开揉碎了说给你听，从备份到还原，每一步都给你捋清楚，保证你看完心里有底。
先说备份。很多人觉得备份就是点一下“备份数据库”完事，太天真了。SQL 2008 R2的备份模式有三种：完整备份、差异备份、日志备份。完整备份是兜底的，差异备份是省时间的，日志备份是救命的。我见过不少同行，只做完整备份，结果数据丢失后只能恢复到昨天凌晨，当天白干。正确做法是：每天凌晨一次完整备份，每四小时一次差异备份，每半小时一次日志备份。别嫌麻烦，真出事的时候，你恨不得日志备份能精确到每分钟。
备份文件放哪儿也有讲究。放在本机磁盘？硬盘挂了怎么办。放在局域网共享？网络断了怎么办。最稳妥的方案是异地双备份，本地留一份，云盘或者另一台服务器放一份。我有个客户，机房漏水，服务器泡了，好在备份在另一栋楼的NAS上，数据毫发无损。另外，备份文件一定要定期验证，别等恢复的时候才发现备份文件是坏的，那感觉比吃苍蝇还难受。
说完备份说还原，这才是真正的技术活。还原之前，先确认你的备份文件是完整的。用RESTORE VERIFYONLY FROM DISK='你的备份文件路径'这条命令，能快速检查备份集是否可用。别嫌多这一步，我见过有人兴冲冲还原，跑了一半报错，才发现备份文件损坏，白折腾俩小时。如果备份文件完好，下一步就是确认你的数据库版本。SQL 2008 R2的备份文件，理论上能还原到更高版本，但反过来不行。要是你的服务器装的是2008（非R2），还原R2的备份，直接报版本不兼容，没得商量。
正式还原的时候，图形界面和T-SQL命令都行，但我更推荐用T-SQL，因为可控性强。基本语法是RESTORE DATABASE 你的数据库名 FROM DISK='备份文件路径' WITH REPLACE, RECOVERY。这里有几个关键参数得说清楚。REPLACE表示强制覆盖现有数据库，如果目标库存在且你想用备份覆盖它，这个参数必须有。RECOVERY表示还原后数据库处于在线可用状态，这是最终还原时用的。还有NORECOVERY，表示还原后数据库处于恢复状态，不能访问，这是做日志还原时用的。顺序别搞反了，先还原完整备份用NORECOVERY，再依次还原差异备份和日志备份，用RECOVERY收尾。
实际操作中，最常遇到的情况是还原到某个时间点。比如你下午三点误删了一批数据，想恢复到两点五十的状态。这时候日志备份就派上用场了。先还原完整备份（NORECOVERY），再还原一次差异备份（NORECOVERY），用STOPAT参数还原日志备份，指定到两点五十那一刻。命令长这样：RESTORE LOG 你的数据库名 FROM DISK='日志备份路径' WITH STOPAT='2024-01-15T14:50:00', RECOVERY。注意，STOPAT的时间格式是ISO标准格式，年月日之间用连字符，时分秒之间用冒号，中间用T隔开，写错格式直接报错。
还有个坑，很多人不知道，就是还原时的事务日志链断裂问题。如果你的数据库做了完整备份后，又做了几次日志备份，结果中间有一次日志备份文件丢了，那后面的日志备份全都白搭，因为日志链断了。这种情况只能恢复到丢日志备份之前的时间点。所以日志备份文件的管理一定要严谨，别乱删，也别随便改文件名。我习惯在备份脚本里加上时间戳，比如DB202401150250.bak，这样既能保证文件名唯一，又方便追溯。
说个真实案例。上个月有个客户打电话来，说业务系统突然连不上库了，一查，数据库文件损坏，无法访问。他们的备份策略是每天凌晨一次完整备份，没有差异和日志备份。好消息是昨天凌晨的完整备份是好的，坏消息是丢失了昨天凌晨到今天下午的全部数据。客户急得跳脚，但没办法，备份策略决定恢复上限。后来我们帮他们调整了备份策略，加了差异和日志备份，客户自己都说，早知道早点调整，也不至于损失一天的数据。
啰嗦一句，技术再熟练，不如提前演练。每季度挑个非业务高峰期，拿备份文件在测试环境做一次完整还原演练，确认备份文件可恢复，确认还原流程没问题。真出事的时候，你就能按流程走，不慌不忙。备份是防御，还原是反击，两者缺一不可。SQL 2008 R2虽然老，但只要备份策略合理，还原操作规范，它能稳稳当当地继续服役好几年。别等到数据丢了才后悔没好好看这篇文章，现在就去检查一下你的备份策略，该补的补上，该验证的验证，真到恢复的时候，每一步都不白走。
