全量备份必须用 WITH CHECKSUM 和 INIT：CHECKSUM 防文件损坏无法检测，INIT 确保独立文件、避免多备份集混存；日志备份需检查 log_reuse_wait_desc 并在主节点执行；还原须 DBCC CHECKDB 及抽样校验；备份路径权限、空间监控应脱离 SQL Agent，改用 PowerShell 调度。
全量备份必须带 WITH CHECKSUM 和 INIT 参数
不加 WITH CHECKSUM 的备份文件损坏了也检测不出来，恢复时才发现问题，已经晚了。SQL Server 默认不校验页完整性，必须显式开启。
INIT 不是可选项——它决定备份集是否覆盖旧文件。用 NOINIT（默认）追加到同一个文件里，时间一长，一个 .bak 里混着几十个备份集，恢复时要指定 FILE = N 编号，极易选错。生产环境应统一用 INIT，每个备份生成独立文件，命名含时间戳，比如 db_full_20240521_2300.bak。
- 示例命令：
BACKUP DATABASE [MyDB] TO DISK = 'D:ackupMyDB_full_20240521_2300.bak' WITH CHECKSUM, INIT, FORMAT -
FORMAT配合INIT使用，避免因媒体头不匹配报错 - 别依赖“自动清理旧备份”脚本——先确认备份写入成功，再删老文件；否则磁盘满导致新备份失败，又没留旧的，直接宕库
日志备份间隔不能只看“每15分钟”，得盯住 log_reuse_wait_desc
设了每15分钟跑一次 BACKUP LOG，不代表日志就真能截断。如果 sys.databases.log_reuse_wait_desc 显示 ACTIVE_TRANSACTION 或 REPLICATION，日志空间就卡住不释放，ldf 文件持续膨胀。
真正可靠的策略是：日志备份任务前加检查，用 SELECT log_reuse_wait_desc FROM sys.databases WHERE name = 'MyDB'，非 NOTHING 时跳过本次备份并告警，而不是硬执行——执行了也白执行，还掩盖了事务卡住的问题。
- 日志备份文件同样要用
WITH CHECKSUM, INIT - 如果数据库用了 Always On，日志备份必须在主节点做，且需确认所有副本同步状态（
sys.dm_hadr_database_replica_states.synchronization_state_desc） - 不要把日志备份和全量备份放在同一块物理盘——磁盘故障时两者同时丢
还原测试不能只跑通语法，得验证数据一致性
很多团队每月“成功执行了还原脚本”，但没查过 DBCC CHECKDB 结果，也没比对关键表行数或校验和。备份文件可能能读、能挂载，但页已损坏，RESTORE VERIFYONLY 只校验头部，不读数据页。
最小可行验证流程：还原 → DBCC CHECKDB WITH NO_INFOMSGS → 抽样查 3–5 张核心表的 COUNT(*) 和 BINARY_CHECKSUM(*)（注意 NULL 处理）→ 记录结果存档。
- 测试必须在隔离环境做，不能连生产网络，避免误操作污染
- 还原目标实例 SQL Server 版本不能低于源版本（如不能用 2019 还原 2022 的备份）
- 如果用了透明数据加密（TDE），备份文件本身不加密，但还原需要原数据库的证书和私钥——这些必须和备份文件一起归档，且私钥密码另存安全位置
备份路径权限和磁盘空间监控必须脱离 SQL Agent 单点依赖
SQL Server Agent 用 NT SERVICESQLSERVERAGENT 账户运行，该账户对网络路径或加密卷常无写入权；更麻烦的是，Agent 崩溃或被禁用时，备份静默失败，没人知道。
可靠做法是：用 Windows Task Scheduler 调用 PowerShell 脚本，脚本内完成权限检查、空间预警（Get-PSDrive）、调用 sqlcmd 执行备份、捕获 $LASTEXITCODE 和输出流，失败立即发邮件+写 Windows Event Log。
- 磁盘剩余空间阈值建议设为备份文件预估大小的 3 倍（压缩备份也要按未压缩大小估算）
- 网络路径优先用 UNC（
\servershare），别映射成 Z: 盘符——Agent 服务看不到用户会话的映射 - 别把备份存到系统盘（C:）或 SQL 数据目录同盘——IO 竞争严重，且 C 盘满会导致整个实例 hang 死
