那天晚上十一点，朋友老张给我打电话，声音里带着哭腔。他说自己手贱，在 SQL Server Management Studio 里点了个“删除数据库”，结果整个生产库没了。那是一个跑了三年的电商系统，订单、用户、商品数据全在里面。备份？他倒是做了，但备份文件放在同一台服务器的 D 盘上，删除数据库时顺手把备份也清了。这种事儿在 DBA 圈子里太常见了，常见到大家都不想聊，因为聊起来全是泪。
先说最基本的情况：如果你用的是 SQL Server 的完整恢复模式，而且日志文件还在，是可以恢复的。SQL Server 在完整恢复模式下会记录每一条事务日志，只要日志没被截断或损坏，理论上可以恢复到任意时间点。具体操作是：先建一个同名数据库，但别恢复任何数据，然后执行 RESTORE LOG 命令，带上 STOPAT 参数指定时间点。这里有个坑——必须先做一次完整备份的还原，并且加上 NORECOVERY 选项，这样数据库才会保持在“正在还原”状态，才能继续应用日志。很多人第一次操作时直接点了恢复，结果数据库直接上线，日志再也应用不上，等于把后路堵死了。
那如果连日志文件都没了呢？比如老张那种情况，整个数据库文件被物理删除了。这时候别慌，还有一根稻草——页级还原。SQL Server 的数据是按 8 KB 一页组织的，删除数据库其实只是把这些页标记为可用，并没有真正覆写磁盘内容。只要磁盘上没有被新数据写入，那些页就还在。可以用第三方工具扫描磁盘，把属于该数据库的页捞出来，再拼成新的数据文件。我试过 ApexSQL Recover 和 Stellar Repair，前者对页损坏的容忍度更高，后者在恢复约束和索引时更稳定。不过这套操作有前提——需要知道数据库的页 ID 范围，通常可以从系统表或备份的元数据里查到。
还有一种情况是备份文件本身损坏。比如完整备份在拷贝过程中中断，或磁盘坏道导致备份文件部分不可读。这时候别急着扔，SQL Server 的备份文件是分段存储的，损坏的往往只是其中一小段。可以先用 RESTORE VERIFYONLY 检查备份，它会报告损坏的位置。随后在 RESTORE DATABASE 时加上 CONTINUEAFTERERROR 选项，SQL Server 会跳过损坏的段继续恢复。但要注意，恢复出来的数据库可能缺少部分数据，需要后续用事务日志或差异备份补全。
除了技术操作，我特别想聊一个被很多人忽略的问题：权限。很多 DBA 或开发者恢复数据库时习惯用 sa 账号或 Windows 管理员权限操作。但恢复过程会继承数据库的所有者信息，如果用 sa 恢复了原本属于某个域用户的数据库，恢复后所有对象的 owner 都会变成 sa，导致存储过程、函数、视图等依赖 schema 的对象失效，因为权限链断了。正确做法是：恢复前先用 ALTER AUTHORIZATION 把数据库所有者改成当前登录名，或者恢复后用 spchangeuserslogin 重新映射用户。这事儿我踩过两次坑，每次都是半夜被叫起来处理。
还有一种更隐蔽的情况是数据库处于“可疑”状态。比如服务器突然断电，或磁盘空间满导致写入失败，SQL Server 会把数据库标记为可疑。这时候很多人直接点“分离数据库”再重新附加，结果发现附加失败，因为数据文件已经不一致。正确的操作是：先执行 ALTER DATABASE … SET EMERGENCY 让数据库进入紧急模式，这时可以读取部分数据。然后用 DBCC CHECKDB 检查一致性，再用 ALTER DATABASE … SET SINGLEUSER WITH ROLLBACK IMMEDIATE 切换到单用户模式，执行 DBCC CHECKDB WITH REPAIRALLOWDATA_LOSS。注意，这会丢失不一致的页数据，但总比整个数据库报废强。
说点实在的。我见过太多人把恢复数据库当成拼运气，但真到数据丢失那一刻，拼的是平时有没有做好两件事：一是备份策略要区分全备、差异备和日志备份，别把备份文件放在同一块磁盘上；二是定期做恢复演练，别等出事了才去翻文档。我的习惯是每个月在测试环境里模拟一次数据库损坏，按流程恢复一遍，记录每个步骤的耗时。这样真出问题时，心里有底，手上有数。老张那次，我远程帮他恢复到了前一天的数据，丢了大概八小时的订单。他后来请我吃了三顿饭，每次都念叨同一句话：“备份这事儿，真不能偷懒。”
