"备份策略？不就是每天晚上全备一下吗？"
"反正有完整备份，丢了最多丢一天的数据。"
"日志备份开着干嘛，占空间……"
如果你也这么想，那大概率还没经历过真正的数据灾难。等你遇到"误删了整张表，老板问你能不能恢复到上午10点"的时候，你就知道什么叫"冷汗直流"了。
这篇文章不讲理论背书，只聊实际怎么搭、怎么用、踩过哪些坑。
一、先搞清三种备份各自是什么
一句话先说清楚，后面才好聊搭配。
| 类型 | 备份什么 | 能恢复到什么粒度 | 速度 | 文件大小 |
|---|---|---|---|---|
| 完整备份（Full） | 数据库的所有数据页 | 只能恢复到备份完成的那一刻 | 慢 | 大 |
| 差异备份（Diff） | 自上次完整备份以来变更过的数据页 | 恢复到差异备份完成的那一刻 | 中 | 中（随时间增长） |
| 日志备份（Log） ** | 自上次日志备份以来的事务日志记录 | 可以恢复到任意时间点（秒级） | 快 | 小（但频繁） |
一个关键认知：差异备份不是"和上次差异备份比"，而是"和上次完整备份比"。所以差异备份会随时间越来越大，直到下一次完整备份重置。
二、最经典的搭配方案：Full + Diff + Log
这是生产环境最常用、最推荐的组合，没有之一。
时间线示意
00:00 完整备份（Full） ──────────────────────────────────────▶ 下一次Full
↑06:00 ↑12:00 ↑18:00 ↑09:00 ↑15:00 ↑21:00
Diff1 Diff2 Diff3 Log1 Log2 Log3...
(小) (中) (大)
恢复时需要什么？
假设 周四下午 14:30 数据库崩了（或误删了数据需要回滚到 14:00）：
恢复步骤：
1. 周三 00:00 的完整备份（基础）
2. 周四 12:00 的差异备份（减少日志应用量）
3. 周四 12:00 ~ 14:00 之间的所有日志备份（逐条重放）
如果没有差异备份，你就需要：完整备份 + 从周三 00:00 到周四 14:00 所有日志备份——可能几百个文件，恢复时间窗口直接爆炸。
差异备份的核心价值：缩短恢复时间（RTO） 。
三、实操：具体怎么配
3.1 前置条件：恢复模式必须选对
这是最容易被忽略的坑。
-- 查看当前恢复模式 SELECT name, recovery_model_desc FROM sys.databases WHERE name = 'YourDB'; -- 必须设为完整恢复模式（Full Recovery） ALTER DATABASE YourDB SET RECOVERY FULL;
| 恢复模式 | 能用日志备份吗 | 能时间点恢复吗 |
|---|---|---|
| Simple | ❌ 不行 | ❌ 不行 |
| Full | ✅ 可以 | ✅ 可以 |
| Bulk-logged | ✅ 可以（有例外） | ⚠️ 部分可以 |
Simple 模式 = 自动截断日志 = 无法做时间点恢复。 很多"丢了数据只能认命"的案例，根因就是数据库跑在 Simple 模式下。
3.2 完整备份
BACKUP DATABASE [YourDB]
TO DISK = N'D:\Backups\YourDB_Full_20260818_0200.bak'
WITH
COMPRESSION, -- 压缩，省空间
CHECKSUM, -- 校验，防损坏
STATS = 10, -- 每10%输出进度
NAME = N'YourDB Full Backup 2026-08-18';
频率建议：
- 中小库（< 500GB）：每周 1 次
- 大库（> 1TB）：考虑每月 1 次 + 文件组备份（进阶话题）
- 业务低峰期执行
3.3 差异备份
BACKUP DATABASE [YourDB]
TO DISK = N'D:\Backups\YourDB_Diff_20260818_1400.bif'
WITH
COMPRESSION,
CHECKSUM,
STATS = 10,
NAME = N'YourDB Differential Backup 2026-08-18 14:00';
频率建议：
- 每日 1 次（在完整备份之外）
- 数据变更量大：每天 2–4 次
- 搭配日志备份使用，差异频率不需要太高
3.4 日志备份（最关键的那个）
BACKUP LOG [YourDB]
TO DISK = N'D:\Backups\YourDB_Log_20260818_1430.trn'
WITH
COMPRESSION,
CHECKSUM,
STATS = 10,
NAME = N'YourDB Log Backup 2026-08-18 14:30';
频率建议：
- 常规业务：每 15 分钟
- 金融/交易系统：每 5 分钟甚至 1 分钟
- 日志增长快的库：频率更高（防止日志文件爆盘）
日志备份不频繁的最大风险不是丢数据，而是日志文件撑爆磁盘。 没有日志备份，日志文件永远不会自动截断（Full 模式下）。
四、恢复实操：真出事了怎么搞
4.1 恢复到最新时间点（灾难恢复）
-- Step 1: 查看备份历史，确认恢复链
SELECT
backup_start_date,
type, -- D=Full, I=Diff, L=Log
physical_device_name
FROM msdb.dbo.backupset bs
JOIN msdb.dbo.backupmediafamily bmf ON bs.media_set_id = bmf.media_set_id
WHERE database_name = 'YourDB'
ORDER BY backup_start_date DESC;
-- Step 2: 恢复完整备份（NORECOVERY = 还要继续恢复）
RESTORE DATABASE [YourDB]
FROM DISK = N'D:\Backups\YourDB_Full_20260818_0200.bak'
WITH NORECOVERY, REPLACE;
-- Step 3: 恢复最新差异备份（NORECOVERY）
RESTORE DATABASE [YourDB]
FROM DISK = N'D:\Backups\YourDB_Diff_20260818_1400.bif'
WITH NORECOVERY;
-- Step 4: 逐个恢复日志备份（最后一个用 RECOVERY）
RESTORE LOG [YourDB]
FROM DISK = N'D:\Backups\YourDB_Log_20260818_1400.trn'
WITH NORECOVERY;
RESTORE LOG [YourDB]
FROM DISK = N'D:\Backups\YourDB_Log_20260818_1415.trn'
WITH NORECOVERY;
-- 最后一个日志备份，用 RECOVERY 让数据库上线
RESTORE LOG [YourDB]
FROM DISK = N'D:\Backups\YourDB_Log_20260818_1430.trn'
WITH RECOVERY;
4.2 恢复到指定时间点（误删数据场景）
这是 DBA 最常遇到的"救火"场景。
-- 恢复到 2026-08-18 14:00:00（误删操作之前）
RESTORE LOG [YourDB]
FROM DISK = N'D:\Backups\YourDB_Log_20260818_1430.trn'
WITH
STOPAT = '2026-08-18 14:00:00',
RECOVERY;
关键前提：数据库必须处于 NORECOVERY 状态（即正在恢复链中），才能用 STOPAT。
五、最容易踩的 8 个坑
坑 1：只做完整备份，不做日志备份
后果：
- 日志文件无限增长，最终撑爆磁盘
- 数据库挂起，所有写入停止
- 无法做时间点恢复
自检：
-- 日志文件是否异常大？
SELECT
name,
size * 8 / 1024 AS size_mb,
max_size
FROM sys.database_files
WHERE type = 1; -- 1 = 日志文件
坑 2：日志备份失败，没人发现
日志备份断了，恢复链就断了。完整备份还在，但中间的日志接不上，时间点恢复直接废掉。
建议：
- 备份作业加告警
- 定期做恢复演练（后面会讲）
坑 3：备份文件跟数据库在同一块磁盘
磁盘坏了 = 数据没了 + 备份也没了。
原则：备份文件必须存到独立存储（异地/云端/不同物理磁盘）。
坑 4：备份了但从来没恢复过
"备份不等于可恢复。"
见过太多"备份文件损坏、恢复报错、没人知道"的案例。
建议：每季度至少做一次恢复演练到备用实例。
坑 5：差异备份越来越大，恢复反而慢
差异备份是相对于最近一次完整备份的增量。如果完整备份是上周日的，到周六的差异备份可能已经很大了。
解法：
- 缩短完整备份周期
- 或引入日志备份减少差异依赖
坑 6：收缩日志文件（SHRINK）当日常操作
很多人看到日志文件大就 DBCC SHRINKFILE，然后日志又涨，又收缩……
后果：日志碎片严重，性能下降，恢复变慢。
正确做法：
- 加大日志文件初始大小 + 自动增长步长设大一些
- 保持合理频率的日志备份
- 不要频繁 SHRINK
坑 7：COPY_ONLY 忘了加，打断恢复链
手动做临时备份时（比如给测试环境拷贝数据），如果不加 COPY_ONLY，会重置差异备份的基准。
-- 临时备份一定要加这个！ BACKUP DATABASE [YourDB] TO DISK = N'D:\Temp\YourDB_AdHoc.bak' WITH COPY_ONLY;
坑 8：没有备份 msdb 和 master
你记得所有备份文件的路径吗？恢复链的顺序呢？
这些信息存在 msdb 里。如果 msdb 没了，你只能靠文件时间戳"猜"恢复顺序——痛苦程度可想而知。
建议：系统数据库（master、msdb、model）也要定期备份。
六、一个可直接落地的备份策略模板
| 项目 | 配置 |
|---|---|
| 恢复模式 | FULL |
| 完整备份 | 每周日 02:00 |
| 差异备份 | 每天 14:00（业务低峰） |
| 日志备份 | 每 15 分钟（24×7） |
| 备份保留 | 本地 7 天 + 异地/云 30 天 |
| 校验 |
备份时 CHECKSUM + 每月 RESTORE VERIFYONLY
|
| 恢复演练 | 每季度一次到备用实例 |
| 告警 | 备份失败 5 分钟内通知 DBA |
七、进阶：验证备份是否可用
-- 不实际恢复，只验证备份文件完整性 RESTORE VERIFYONLY FROM DISK = N'D:\Backups\YourDB_Full_20260818_0200.bak'; -- 更狠一点：RESTORE WITH VERIFYONLY 对日志也做 RESTORE VERIFYONLY FROM DISK = N'D:\Backups\YourDB_Log_20260818_1430.trn';
八、总结一句话
完整备份决定你能恢复到多近，日志备份决定你能恢复到多细，差异备份决定你恢复得多快。
三者不是"选一个"的关系，而是搭班子：
- 没有完整备份 → 一切免谈
- 没有日志备份 → 最多丢一天（或更久）的数据
- 没有差异备份 → 恢复时间可能从 30 分钟变成 3 小时
以上就是SQL Server数据库完整备份、差异备份与日志备份的实操指南的详细内容，更多关于SQL Server备份的资料请关注其它相关文章！
