最近帮一个朋友处理数据库崩溃的事，差点没把他急哭。他们的核心业务系统跑在SQL Server上，好几年没正经做过一次完整的备份。硬盘一挂，数据全没了，连个恢复的抓手都没有。花了三天时间找第三方数据恢复公司，花了三万块钱，才捞回来七成的数据。这个教训太深刻了——备份恢复不是技术问题，是生存问题。你如果手头有SQL Server在跑，不管是测试环境还是生产环境，今天这篇文章就得好好看完。
SQL Server的备份机制其实不复杂，但很多人一上来就被那些术语给唬住了。完整备份、差异备份、事务日志备份，听起来像三座大山，其实拆开看就三句话。完整备份就是把整个数据库拍张快照，包括数据文件、日志文件，全给你装进一个.bak文件里。差异备份只拍和上一次完整备份之间的变化，相当于只记录新增和修改的部分。事务日志备份更细，把每一条增删改查的操作都记下来，精确到秒级。这三者配合使用，才能在出事后做到最小数据丢失。就像你每天拍一张全家福，每3个小时拍一张新变化，每分钟拍一张小动作，哪天手机丢了，也能基本还原到丢之前的状态。
很多人觉得做备份就是点个“备份数据库”按钮就完事了，其实真正要命的是恢复策略。你得提前想清楚，如果服务器着火了怎么办？如果硬盘被勒索病毒加密了怎么办？如果某个DBA手抖把表删了怎么办？这些问题不提前想，等出事再想就晚了。举个例子，一个电商系统，每天23点做完整备份，每4小时做差异备份，每15分钟做事务日志备份。某天上午10点出了事故，你恢复的顺序必须是：先恢复昨天的完整备份，再恢复今天凌晨4点的差异备份，按时间顺序恢复从4点到10点的所有事务日志备份。顺序错了，恢复就废了。很多人就是栽在这上面，要么忘了恢复差异备份，要么漏了一个日志文件，结果恢复出来的数据又旧又不完整。
说到恢复，不得不提SQL Server里那个容易被人忽略的核心选项——恢复模式。简单恢复模式、完整恢复模式、大容量日志恢复模式，这三者的区别直接决定了你能恢复到什么时间点。简单恢复模式下，事务日志会被自动截断，你只能恢复到上一次完整备份的时间点，中间的数据全丢。完整恢复模式保留了所有事务日志，可以做到任意时间点恢复，但日志文件会疯狂增长，不注意管理硬盘会爆。大容量日志恢复模式是个折中方案，适合做大批量数据导入的时候临时切换，平时别长期开着。我建议，生产环境一律用完整恢复模式，日志文件定期做备份后截断，这样既能保证恢复精度，又能控制硬盘空间。
备份文件怎么存，也大有讲究。很多人图省事，把备份文件和数据库放在同一块硬盘上。这就像把备用钥匙挂在锁旁边，小偷来了直接一锅端。正确的做法是把备份文件存到独立的存储设备上，最好是异地或者云端。现在SQL Server原生支持备份到Azure Blob Storage，操作起来比想象中简单，设置一条备份语句就能搞定。如果公司预算有限，至少也要备份到另一台服务器的共享文件夹里。还有一点容易被忽略，备份文件要定期验证。你辛辛苦苦做了半年的备份，结果恢复时发现文件损坏了，那心情比没做备份还崩溃。SQL Server自带RESTORE VERIFYONLY命令，专门用来验证备份文件完整性，你可以在备份脚本后面加上这行检查，养成习惯。
恢复操作本身也有技巧。最常用的恢复方式是通过SQL Server Management Studio的图形界面，右键数据库，选“还原数据库”，然后按向导一步步操作。但如果你是DBA，最好学会写T-SQL恢复命令。因为生产环境往往需要在命令行下快速操作，或者通过自动化脚本执行。举个例子，RESTORE DATABASE [YourDB] FROM DISK = N'D:BackupYourDB.bak' WITH NORECOVERY，这条命令的意思是用NORECOVERY模式恢复，这样数据库不会立即可用，方便你继续追加差异备份和日志备份。等到所有备份都恢复完了，再用WITH RECOVERY让数据库上线。这个细节很关键，很多人直接用RECOVERY模式恢复，结果后续的差异备份和日志备份根本加不上去，只能从头再来。
备份恢复这件事，最难的不是技术，而是习惯。很多团队刚开始做备份时热情高涨，排了详尽的计划，每天都自动跑。但时间一长，人就会懈怠。备份文件越积越多，没人清理；备份脚本报错了，没人关注；异地备份的存储空间满了，没人扩容。等灾难真的来了，才发现备份系统已经瘫痪了大半年。我见过最离谱的一个案例，某公司每天做完整备份，备份文件4TB，但只保留最近7天的数据。那天第六天的备份文件损坏了，第七天的备份因为硬盘空间不足没跑成功。结果要恢复时，只能恢复五天前的数据，丢了整整两天的交易记录。所以备份策略不仅要考虑怎么做，还要考虑怎么检查、怎么维护、怎么清旧。
说一句，备份恢复不是IT部门的事，是整个公司的事。你作为DBA或者运维人员，有责任让老板知道，如果没有可靠的备份恢复方案，公司随时可能一夜回到解放前。建议你每个月做一次恢复演练，找个测试环境，完整走一遍从备份到恢复的流程，记录下耗时和异常。这样既能验证备份文件的有效性，也能让团队熟悉应急流程。顺便说一句，别把备份密码设成123456，我见过有人这么干，结果备份文件被同事误删后，想恢复都不知道密码是什么。SQL Server的备份恢复，说到底就是一个“提前想，认真做，经常练”的过程。你花在备份上的每一分钟，都是在给未来的自己买保险。
