我要评论"备份策略？不就是每天晚上全备一下吗？"
"反正有完整备份，丢了最多丢一天的数据。"
"日志备份开着干嘛，占空间……"
如果你也这么想，那大概率还没经历过真正的数据灾难。等你遇到"误删了整张表，老板问你能不能恢复到上午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备份的资料请关注代码网其它相关文章！
发表评论