SQL Server 备份与高可用

SQL Server 备份恢复围绕完整备份、差异备份、日志备份和恢复模式展开。

恢复模式

模式	特点
Simple	日志自动截断，不能做任意时间点恢复
Full	支持日志备份和时间点恢复
Bulk-logged	大批量操作日志较少，恢复能力有边界

核心业务库通常使用 Full。

备份类型

类型	作用
Full Backup	完整备份
Differential Backup	从上次完整备份后的变化
Transaction Log Backup	日志备份，可用于时间点恢复

恢复链路

flowchart TD
    A["完整备份"] --> B["差异备份"]
    B --> C["日志备份 1"]
    C --> D["日志备份 2"]
    D --> E["恢复到指定时间点"]

恢复时顺序不能乱。

Always On

Always On Availability Groups 是 SQL Server 常见高可用方案，提供多个副本、故障转移和只读副本能力。

sequenceDiagram
    participant P as Primary Replica
    participant L as Transaction Log
    participant S as Secondary Replica
    P->>L: 写日志
    L->>S: 传输日志块
    S->>S: 重做日志

零基础先理解：恢复模式决定你能恢复到哪里

SQL Server 每次数据修改都会写事务日志。事务日志不只是“操作记录”，它是事务回滚、崩溃恢复、日志备份、时间点恢复和高可用同步的核心。

如果数据库使用 Simple 恢复模式，日志会在检查点后被截断，适合测试库或可丢数据场景。核心业务库通常用 Full 恢复模式，因为它允许你通过日志备份恢复到某个具体时间点。

flowchart TD
    A["业务写入"] --> B["写事务日志"]
    B --> C["数据页稍后刷盘"]
    C --> D{"恢复模式"}
    D -- "Simple" --> E["日志可被自动截断"]
    D -- "Full" --> F["必须做日志备份才能截断"]
    F --> G["支持时间点恢复"]

为什么 Full 模式下日志会暴涨

Full 模式中，如果你只做完整备份，不做事务日志备份，日志文件不会按预期截断，可能持续增长。

常见误区：

误区	正确理解
做了 Full Backup 日志就会变小	完整备份不等于日志备份
shrink 日志是常规运维	shrink 只是临时释放空间，根因是日志备份链路
日志文件越小越好	太小会频繁增长，影响性能
Simple 模式更省心	省心的代价是不能做完整时间点恢复

生产库要建立日志备份任务，并监控日志使用率和磁盘空间。

备份链怎么理解

一次可用恢复通常依赖完整备份、可选差异备份、多个日志备份。恢复顺序不能乱。

flowchart TD
    A["周日完整备份"] --> B["周一差异备份"]
    B --> C["日志备份 10:00"]
    C --> D["日志备份 10:15"]
    D --> E["日志备份 10:30"]
    E --> F["恢复到 10:24"]

恢复时：

1. 先还原完整备份，保持 NORECOVERY。
2. 再还原最近的差异备份，保持 NORECOVERY。
3. 按顺序还原日志备份。
4. 最后一段日志使用 STOPAT 指定时间点。
5. 最后 RECOVERY 打开数据库。

示例：

restore database AssetDb
from disk = 'D:\backup\AssetDb_full.bak'
with norecovery;

restore database AssetDb
from disk = 'D:\backup\AssetDb_diff.bak'
with norecovery;

restore log AssetDb
from disk = 'D:\backup\AssetDb_log_1015.trn'
with norecovery;

restore log AssetDb
from disk = 'D:\backup\AssetDb_log_1030.trn'
with stopat = '2026-07-06T10:24:00',
     recovery;

误删数据怎么处理

如果 10:25 误删资产数据，不要马上把主库整体恢复到 10:24。整体回退会丢失 10:24 之后其他正常业务。

更稳妥的商业流程：

flowchart TD
    A["确认误删时间和范围"] --> B["用备份恢复到临时库"]
    B --> C["恢复到误删前时间点"]
    C --> D["导出被误删的数据"]
    D --> E["在主库校验冲突和依赖"]
    E --> F["走补偿脚本回灌"]
    F --> G["复核数据和业务状态"]

这个流程体现了“恢复能力”和“业务补偿”要结合。数据库恢复只是把数据找回来，业务上还要确认订单、库存、流水、审批状态是否一致。

Always On 原理

Always On Availability Groups 通过主副本写入日志、辅助副本接收并重做日志来同步数据。

sequenceDiagram
    participant App as 应用
    participant P as Primary
    participant L as Log Block
    participant S as Secondary
    App->>P: 写入事务
    P->>P: 写本地事务日志
    P->>L: 发送日志块
    L->>S: 传到辅助副本
    S->>S: Redo日志

同步提交和异步提交的区别：

模式	特点	适合
同步提交	主库等待副本确认，数据丢失风险低，但延迟更高	同城核心业务
异步提交	主库不等待远端确认，性能好，但故障时可能丢数据	异地容灾

Always On 可以做故障转移和只读副本，但不能替代备份。误删、误更新会同步到副本。

日志传送、复制、Always On 区别

方案	原理	优点	边界
Log Shipping	定时备份日志、复制、还原	简单，适合容灾	延迟较高，切换手工较多
Replication	按发布订阅复制对象或数据变化	适合分发部分数据	不等于完整高可用
Always On AG	日志块传输和重做	高可用、只读副本	版本和许可、网络、运维复杂
Backup Restore	备份文件恢复	防误删、防灾难	恢复时间取决于备份和演练

商业备份策略示例

核心订单库或资产库常见策略：

项目	策略
恢复模式	Full
完整备份	每周一次
差异备份	每天一次
日志备份	每 5 到 15 分钟
备份校验	RESTORE VERIFYONLY 加定期真实恢复
异地保存	至少一份异地或对象存储
恢复演练	每月恢复到临时环境
监控	作业失败、日志空间、备份时长、AG 延迟

RPO/RTO 要和业务方确认。支付、订单、库存通常要求很低的数据丢失；报表和日志库可以接受更长恢复窗口。

常见坑

坑	后果	正确做法
Full 模式不做日志备份	日志文件持续增长	建日志备份作业
只备份不恢复演练	故障时发现备份不可用	定期恢复到临时库
把 Always On 当备份	误删同步到副本	Always On + 备份都要有
随意 shrink 日志	反复增长，影响性能	先修复备份链路，再规划日志大小
恢复链断裂	无法恢复到目标时间点	保存完整、差异、日志备份链

面试标准回答

SQL Server 备份恢复要理解恢复模式。Simple 模式不能做完整的时间点恢复，Full 模式配合完整备份、差异备份和事务日志备份可以恢复到指定时间点。恢复时通常先还原完整备份，再还原差异备份，最后按顺序还原日志备份。高可用常见方案是 Always On Availability Groups，通过主副本和辅助副本同步日志实现故障转移和只读扩展。