简介这份资源面向SQL Server数据库管理员与运维开发人员聚焦备份、还原与数据修复三大核心场景帮助应对数据丢失、MDF文件损坏及勒索病毒加密等突发状况。包内共1个docx文档约660KB以图文步骤形式梳理了手动单次备份、维护计划向导自动化备份、数据库还原流程以及PhotoRec恢复误删数据、Data Numen SQL Recovery修复损坏MDF文件等实用方法内容紧凑、查阅方便。目前已有717人学习下载适合希望系统掌握SQL Server数据安全保障思路、快速定位恢复方案的初中级从业者参考也可作为日常运维排错时的速查手册。1. SQL Server 备份还原修复一次误删数据后的三小时抢救复盘凌晨两点业务库一张核心订单表被误执行了DELETE没有WHERE。开发第一反应是找 DBA 要备份结果发现这台 SQL Server 的维护计划里只有一次全量备份还是三天前的事务日志从来没做过备份。三天数据靠日志也补不回来最后只能从另一台只读从库拼凑业务方对账对了整整一周。这件事之后我把这套「备份 还原 修复」的链路重新梳理了一遍。它解决的不是「怎么点一下备份按钮」而是三件事备份策略怎么设计才敢还原、还原时选全量还是日志、数据库已经坏了页损坏、误删、文件丢失时怎么把损失压到最小。适合正在管 SQL Server 的运维、后端和兼职 DBA尤其是那种「有备份但从没验证过能不能还原」的环境。下面按我实际落地的顺序讲从策略到命令到踩坑。2. 备份策略怎么定全量、差异、日志三种备份的取舍2.1 恢复模型决定了你能还原到什么程度很多人上来就问「多久做一次全量」其实顺序反了。先定恢复模型Recovery Model它直接决定你能不能做日志备份、能不能还原到某个时间点。SQL Server 有三种恢复模型恢复模型日志备份时间点还原适用场景完整FULL支持支持核心业务库不能丢数据大容量日志BULK_LOGGED支持部分受限大批量导入期间临时切换简单SIMPLE不支持不支持测试库、日志不重要的库核心库必须是 FULL。切到 FULL 之后日志会一直增长直到你做第一次完整备份日志空间才会被标记为可复用。这一点新手最容易翻车切了 FULL 没做全量备份日志文件几小时撑爆磁盘。-- 查看当前恢复模型 SELECT name, recovery_model_desc, log_reuse_wait_desc FROM sys.databases WHERE name YourDB; -- 切换到完整恢复模型 ALTER DATABASE YourDB SET RECOVERY FULL; -- 切换后必须立刻做一次完整备份否则日志无法截断 BACKUP DATABASE YourDB TO DISK D:\Backup\YourDB_FULL_20240101.bak WITH INIT, COMPRESSION, CHECKSUM, STATS 10;WITH后面几个参数值得说清楚INIT表示覆盖同名备份集不加会追加导致文件越来越大COMPRESSION压缩备份CPU 换空间一般能压到 20%~30%CHECKSUM写入校验和还原时能提前发现备份文件损坏这个参数我强烈建议默认加上STATS 10每 10% 打印进度长备份时心里有底。2.2 全量 差异 日志的经典组合单靠全量备份窗口和恢复点目标RPO很难同时满足。常见做法是每周日一次全量每天一次差异备份每 15 分钟或 30 分钟一次日志备份差异备份只记录上次全量以来的变化比全量小得多日志备份记录所有事务能支撑时间点还原。还原时的顺序是最近一次全量 → 最近一次差异 → 差异之后的所有日志一个都不能少。-- 差异备份 BACKUP DATABASE YourDB TO DISK D:\Backup\YourDB_DIFF_20240101.bak WITH INIT, COMPRESSION, CHECKSUM, DIFFERENTIAL, STATS 10; -- 日志备份注意不能用 INIT 覆盖日志备份要连续 BACKUP LOG YourDB TO DISK D:\Backup\YourDB_LOG_20240101_1200.trn WITH COMPRESSION, CHECKSUM, STATS 10;日志备份链一旦断掉比如中间某个 .trn 文件被删、磁盘写满导致备份失败后面的日志备份就接不上了时间点还原只能恢复到断链之前。所以日志备份文件要单独规划保留策略别和全量放一个目录一起被清理脚本误删。2.3 备份文件放哪异地备份不是可选项备份和数据库放同一块物理磁盘等于没备份。磁盘挂了两个一起没。我一般分三层本地快速恢复层同机房另一台存储保留 3~7 天用于快速还原同城异地层同城另一个机房保留 30 天归档层对象存储或磁带保留按合规要求异地备份的传输可以用BACKUP ... TO URL直接写云存储也可以本地备份完再同步。注意TO URL需要先创建凭据Credential这一步在 SQL Server 2016 以后才比较顺老版本折腾起来比较费劲。提示备份策略定完一定要做一次「还原演练」。没验证过的备份等于没有备份。我见过太多备份文件在还原时报「媒体集有 2 个媒体簇但只提供了 1 个」这种低级错误。3. 还原怎么做从完整还原到时间点还原的命令拆解3.1 完整还原与 WITH REPLACE 的坑最基础的还原是把一个全量备份盖回去。但直接RESTORE DATABASE经常报错因为目标库还存在、文件路径对不上。-- 先看备份文件里有什么别急着还原 RESTORE FILELISTONLY FROM DISK D:\Backup\YourDB_FULL_20240101.bak; -- 看备份集信息第几个备份集、类型、时间 RESTORE HEADERONLY FROM DISK D:\Backup\YourDB_FULL_20240101.bak; -- 完整还原覆盖现有库并移动文件到新路径 RESTORE DATABASE YourDB FROM DISK D:\Backup\YourDB_FULL_20240101.bak WITH REPLACE, RECOVERY, MOVE YourDB TO D:\Data\YourDB.mdf, MOVE YourDB_log TO D:\Log\YourDB_log.ldf, STATS 10;RESTORE FILELISTONLY返回的逻辑文件名就是MOVE里要写的名字写错了会报「无法覆盖文件」。REPLACE允许覆盖同名数据库不加的话如果库已存在会直接拒绝。RECOVERY表示还原后数据库可用如果后面还要接着还原差异或日志这里必须写NORECOVERY否则日志链就断了这是还原失败最常见的原因之一。3.2 时间点还原把误删挡在某个时刻之前回到开头那个误删场景如果日志备份齐全是可以还原到误删前一秒的。-- 第一步还原最近一次全量保持 NORECOVERY RESTORE DATABASE YourDB FROM DISK D:\Backup\YourDB_FULL_20240101.bak WITH NORECOVERY, REPLACE, MOVE YourDB TO D:\Data\YourDB.mdf, MOVE YourDB_log TO D:\Log\YourDB_log.ldf; -- 第二步还原差异如果有仍然 NORECOVERY RESTORE DATABASE YourDB FROM DISK D:\Backup\YourDB_DIFF_20240101.bak WITH NORECOVERY; -- 第三步还原日志到误删前的时刻 RESTORE LOG YourDB FROM DISK D:\Backup\YourDB_LOG_20240101_1200.trn WITH NORECOVERY, STOPAT 2024-01-01T11:59:00; -- 第四步恢复数据库可用 RESTORE DATABASE YourDB WITH RECOVERY;STOPAT是时间点还原的核心它把日志重放到指定时刻就停。注意STOPAT的时间是数据库服务器本地时间不是客户端时间跨时区环境要换算。另外如果误操作是TRUNCATE TABLE或DROP TABLE日志里记录的操作类型不同STOPAT依然有效但要在还原后立刻把数据导出别在原库上继续操作。3.3 页面级还原只修坏页不动整库如果只是某个数据页损坏比如磁盘坏道整库还原代价太大。SQL Server 支持页面级还原前提是有完整备份和日志备份。-- 检查数据库是否有页损坏 DBCC CHECKDB(YourDB) WITH NO_INFOMSGS; -- 从完整备份还原指定页面 RESTORE DATABASE YourDB PAGE 1:456 FROM DISK D:\Backup\YourDB_FULL_20240101.bak WITH NORECOVERY; -- 再用日志备份前滚 RESTORE LOG YourDB FROM DISK D:\Backup\YourDB_LOG_20240101_1200.trn WITH RECOVERY;PAGE 1:456里的1是文件 ID456是页号DBCC CHECKDB会直接告诉你坏页的 file:page。页面级还原要求数据库处于完整恢复模型且日志链完整否则前滚不了。4. 数据库坏了怎么修DBCC CHECKDB 与紧急模式4.1 先判断损坏程度别急着修数据库报「可疑」或者查询报「页校验和错误」时第一步不是修是评估。-- 查看数据库状态 SELECT name, state_desc, user_access_desc FROM sys.databases WHERE name YourDB; -- 只读方式检查不锁库太久 DBCC CHECKDB(YourDB) WITH NO_INFOMSGS, ALL_ERRORMSGS;DBCC CHECKDB会返回错误列表常见的有页校验和失败checksum mismatch物理损坏优先从备份还原索引不一致逻辑损坏可以DBCC CHECKDB ... REPAIR_REBUILD重建索引分配错误页归属混乱修复风险高4.2 紧急模式下的数据抢救如果备份不可用数据库又起不来可以进紧急模式EMERGENCY把数据导出来。-- 单用户模式进紧急状态 ALTER DATABASE YourDB SET EMERGENCY; ALTER DATABASE YourDB SET SINGLE_USER; DBCC CHECKDB(YourDB, REPAIR_ALLOW_DATA_LOSS); -- 抢救完切回多用户 ALTER DATABASE YourDB SET MULTI_USER;REPAIR_ALLOW_DATA_LOSS这个名字就是警告它会删掉损坏的页来让数据库可用被删的数据就没了。所以这一步之前能复制一份 .mdf/.ldf 就复制一份留个后悔药。修复完立刻做完整备份然后DBCC CHECKDB再确认一遍。4.3 日志文件损坏与误删的应对日志文件.ldf损坏或丢失数据库可能无法附加。如果数据库正常关闭过、且没有未提交事务可以尝试用ATTACH_REBUILD_LOG重建日志。-- 重建日志仅限干净关闭的库 CREATE DATABASE YourDB ON (FILENAME D:\Data\YourDB.mdf) FOR ATTACH_REBUILD_LOG;这个命令会新建一个日志文件但前提是数据文件是干净的。如果数据文件本身也不一致重建会失败只能从备份还原。所以日志文件千万别随手删它不是可有可无的。5. 避坑与排查还原修复中最容易翻车的五件事5.1 还原报「媒体集有 2 个媒体簇但只提供了 1 个」现象RESTORE时报媒体集不匹配明明备份文件就在那。原因备份时用了多个TO DISK或多个备份设备还原时只给了一个文件。或者备份文件被分卷striped backup少给了分卷。解决用RESTORE HEADERONLY看FamilyCount如果是 2说明备份跨了两个文件还原时要把所有分卷都列上。日常备份尽量单文件除非文件大到需要分卷。5.2 日志链断了时间点还原只能到断点现象还原日志时报「此日志备份无法应用因为数据库未处于还原状态」或「日志链中断」。原因中间某个日志备份丢失、失败或者有人对数据库做了BACKUP LOG ... WITH NO_LOG/TRUNCATE_ONLY老版本把日志截断了。解决只能还原到断链前最后一个可用日志。预防办法是日志备份任务加告警失败立刻处理别等到要还原时才发现。5.3 还原后数据库变成「正在还原」状态现象还原完数据库显示「正在还原Restoring」无法访问。原因还原时用了NORECOVERY但后面忘了执行RESTORE DATABASE ... WITH RECOVERY。解决执行RESTORE DATABASE YourDB WITH RECOVERY;即可。如果还有日志要还原就继续NORECOVERY全部还原完再RECOVERY。5.4 磁盘空间不足导致还原中途失败现象还原到一半报「磁盘空间不足」数据库卡在还原状态。原因还原需要同时容纳原库文件和新还原的文件空间需求是数据文件大小的 1.5~2 倍。压缩备份还原时还要额外临时空间。解决还原前用RESTORE FILELISTONLY看文件大小预留足够空间。空间不够时可以先删掉原库文件确认备份可用后或者还原到另一块盘再迁移。5.5 DBCC CHECKDB 修复后数据对不上现象REPAIR_ALLOW_DATA_LOSS修复后某些表行数变少或查询报错。原因修复过程删除了损坏页页上的数据永久丢失。解决修复前尽量导出可读数据修复后立刻全量备份然后和业务方核对关键表。能不用ALLOW_DATA_LOSS就不用优先从备份还原。6. 把还原演练做成例行任务一个可复用的验证脚本备份策略写得再漂亮不验证都是纸上谈兵。我现在的习惯是每周自动跑一次还原演练把生产库的最近全量 差异 日志还原到一台测试实例跑DBCC CHECKDB再对比几张核心表的行数。下面是一个简化版的验证脚本框架。-- 还原演练还原到测试库 YourDB_Verify -- 1. 还原全量 RESTORE DATABASE YourDB_Verify FROM DISK D:\Backup\YourDB_FULL_latest.bak WITH NORECOVERY, REPLACE, MOVE YourDB TO D:\Verify\YourDB_Verify.mdf, MOVE YourDB_log TO D:\Verify\YourDB_Verify_log.ldf; -- 2. 还原差异 RESTORE DATABASE YourDB_Verify FROM DISK D:\Backup\YourDB_DIFF_latest.bak WITH NORECOVERY; -- 3. 还原日志按顺序最后一个用 RECOVERY RESTORE LOG YourDB_Verify FROM DISK D:\Backup\YourDB_LOG_latest.trn WITH RECOVERY; -- 4. 一致性检查 DBCC CHECKDB(YourDB_Verify) WITH NO_INFOMSGS, ALL_ERRORMSGS; -- 5. 核心表行数对比示例 SELECT Orders AS TableName, COUNT(*) AS Cnt FROM YourDB_Verify.dbo.Orders UNION ALL SELECT Customers, COUNT(*) FROM YourDB_Verify.dbo.Customers;这个脚本的关键点还原顺序不能乱日志必须按备份时间顺序应用最后一个日志还原用RECOVERY让库可用。行数对比不用追求完全一致演练期间生产还在写但量级要对得上差太多说明还原链有问题。演练频率我一般设成每周一次核心库每天一次。演练实例可以和开发测试共用但要注意别把生产备份还原到有敏感数据的实例上。另外演练完记得清理别让测试库把磁盘占满。一个血泪教训我曾经因为备份文件放在网络共享上演练时发现共享权限被改过还原直接失败。后来所有备份路径都加了连通性和权限的预检。备份这件事平时多花十分钟验证出事时能省三天。希望帮到你。本文还有配套的精品资源点击获取