这事儿我得先给你讲个真事儿。上个月我有个朋友，干了好几年 DBA 的老手，手滑在 SQL Server 2012 里把生产库给覆盖了。当时他脸都绿了，嘴里念叨着“完蛋了，完蛋了”，手指抖着点恢复选项。结果你猜怎么着？他平时备份策略做得不错，恢复成功了，但折腾了大半天。这事儿让我特别想聊聊 SQL Server 2012 的数据库恢复——这活儿看着简单，关键时刻细节却能要你命。
先说说恢复的基本盘吧。SQL Server 2012 里的恢复，说白了就三种模式：完整恢复、简单恢复和大容量日志恢复。大多数人平时用的是完整恢复模式，因为能点对点还原，精确到某个时间点。比如你凌晨三点删了个表，只要日志没被截断，就能恢复到两点五十九分。简单恢复模式省事儿多了，日志不保留，恢复只能回到最近一次完整备份。但如果业务对数据丢失容忍度低——比如银行交易系统，用简单恢复模式简直是自杀。大容量日志模式是折中方案，适合批量导入数据时使用，恢复时能保住大部分日志，性能比完整模式好一点。你得先搞清楚自己库的模式，不然恢复时就像无头苍蝇。
接着说备份类型，这玩意儿跟恢复直接挂钩。SQL Server 2012 支持完整备份、差异备份和事务日志备份。完整备份就是全量拷贝，差异备份只备份上次完整备份后变动的数据，日志备份记录所有事务。最经典的恢复套路是：先还原最近一次完整备份，再还原最近一次差异备份，随后依次还原差异备份之后的所有日志备份。这就像拼图，少一块都不行。我见过最惨的案例，有人只做了完整备份，没做日志备份，结果恢复时只能回到上次备份的时间点，中间好几小时的数据全丢了。备份策略不是随便定的，得根据业务数据变化频率来决定：数据变动频繁的，日志备份可以设成 15 分钟一次；变动少的，一天一次也凑合。
具体到操作，SQL Server 2012 的恢复分图形界面和 T‑SQL 两种。图形界面在 SSMS 里，右键数据库→任务→还原→数据库，然后选源设备、点备份集、定还原状态。这里有个坑：还原状态有三个选项，RESTORE WITH RECOVERY 让数据库在线可用，RESTORE WITH NORECOVERY 保持恢复状态以便继续还原更多备份，RESTORE WITH STANDBY 为只读状态。很多人第一次操作时直接选了 RECOVERY，结果想继续还原日志就报错了。正确的流程是：先还原完整备份时选 NORECOVERY，差异备份和日志备份也选 NORECOVERY，最后再选 RECOVERY。顺序错一步，就得重来。
T‑SQL 命令更灵活，适合自动化。比如还原完整备份的命令是：接着还原差异备份：再还原日志备份：你可以在脚本里加参数，例如 ，精确还原到那个时间点。这招特别实用，比如你知道数据出问题是在下午两点零三分，那直接恢复到两点整，数据就全回来了。
还有一种情况是库文件损坏，比如 MDF 或 LDF 物理坏了，但备份还在。这时候可以用紧急模式恢复。先把库设为紧急模式：然后检查一致性：如果只是单页损坏，可以尝试从备份里还原该页：这招不一定每次都灵，但总比直接宣布数据丢了强。我见过一个 DBA，MDF 文件坏了一半，靠紧急模式加页级还原，硬是把核心表数据救回来了，虽然丢了点日志，但比全丢强多了。
说到这里，得提一嘴 SQL Server 2012 的一个坑：它的日志文件增长策略默认是自动增长，且增长步长按百分比算。比如库有 100 GB，日志默认增长 10%，每次就增长 10 GB。恢复时日志文件需要空间来写操作，如果空间不够，恢复会直接报错。我碰到过一次，恢复一个 200 GB 的库，日志自动增长，结果数据盘只剩 20 GB，恢复到一半就挂了。解决办法是提前调整日志增长策略，改成固定 MB 增长，例如每次增长 500 MB，同时确保磁盘有足够空闲空间。这细节没人提醒，踩坑了才懂。
说说恢复后的验证。很多人恢复完一看库在线了，就以为完事了。大错特错。你得跑一遍 检查一致性，或者写个脚本核对关键表的行数，跟备份前做个对比。我有个同事，恢复后没验证，第二天业务反馈数据对不上，才发现恢复时有个约束丢了，导致部分数据重复。SQL Server 2012 的恢复机制本身靠谱，但你必须确保备份文件完整，恢复过程没有出岔子。定期做恢复演练是最好的办法——每个月找个测试环境，把备份还原一遍，看看能否正常跑。别等真出事了再临时抱佛脚，那时候哭都没有地方哭。数据库恢复这事儿，七分靠策略，三分靠运气；只要把七分做好，运气自然也跟着好。
