SQL报表系统容灾核心是保障关键报表按时生成、历史结果可追溯、配置与调度逻辑不丢失；需分层备份元数据库、中间表/快照、调度脚本及前端报表文件，并通过协同恢复与轻量级方案实现低成本高可用。
SQL报表系统的容灾核心目标
报表系统本身不直接承载交易数据，但一旦失效，会影响经营分析、监管报送和决策响应。容灾设计重点不是“零中断”，而是保障关键报表可按时生成、历史结果可追溯、配置与调度逻辑不丢失。这意味着需区分对待：数据库（含报表元数据、缓存表、快照）、调度服务（如SQL Server Agent、Airflow、Quartz）、前端展示层（如Power BI Report Server、自研Web平台）三者灾备等级不同。
分层备份策略：什么该备、怎么备、多久备
按数据价值与变更频率分级处理：
- 报表元数据库（必全量+日志备份）：含用户权限、报表定义、参数模板、执行日志表。启用SQL Server完整恢复模式，每2小时日志备份，每日凌晨全备，保留7天；关键变更（如大屏上线、权限批量调整）后手动触发一次差异备份。
- 报表中间表/汇总快照（按业务周期备份）：月结报表的汇总表每日全备一次，保留30天；实时看板依赖的小时级缓存表只保留最近48小时物理备份，其余靠上游ODS重算。
- 调度任务配置与脚本（版本化管理）：SQL作业、存储过程、Python调度脚本统一纳入Git仓库，每次部署自动打Tag并关联Jira工单号；禁止在生产库中直接修改未入源码的作业。
- 前端报表定义文件（导出+校验）：Power BI使用pbix文件导出+XML元数据提取；自研平台提供“报表包导出”功能，含SQL语句、参数绑定、样式JSON，导出后自动MD5校验并上传至对象存储。
灾备恢复的实操要点
恢复不是简单还原数据库，而是一套协同动作：
- 优先恢复元数据库，验证用户角色、报表目录树、最近3次调度日志是否完整；
- 检查上游数据源连通性及时间窗口——若ODS尚未同步昨日数据，强行恢复报表快照会导致结果错误；
- 用备份的调度脚本重建Agent Job或Airflow DAG，但禁用自动触发，先人工执行一次dry-run确认SQL兼容性（尤其注意SQL Server升级后语法变更）；
- 前端恢复后，需重新绑定数据源连接字符串，并刷新嵌入式Token或OAuth凭据（避免因密钥过期导致报表加载白屏）；
- 恢复完成后，自动运行一组“黄金报表”校验任务（如营收日报、用户活跃TOP10），比对灾备库与原库近3天输出哈希值，生成差异报告。
低成本高可用的轻量级容灾方案
非金融类业务无需RPO=0的双活架构，推荐组合方式：
- 主库为SQL Server Standard，灾备库用相同版本的Standard实例，通过Always On可用性组（仅含元数据库和关键快照库），同步模式设为异步，降低主库压力；
- 报表调度服务采用主备模式：主调度节点故障时，备用节点每5分钟拉取Git最新DAG并启动，依赖ZooKeeper做选主，避免双写冲突；
- 前端静态资源（JS/CSS/报表模板）存放于CDN+对象存储，故障时切换CNAME即可，无需服务器重建；
- 每月最后一周执行一次全流程恢复演练，记录从告警发现到首张关键报表可查看的耗时，目标控制在45分钟内。
