外观
OceanBase 备份恢复规范
备份恢复体系架构
1.1 总体架构
OceanBase备份恢复体系采用分层设计,包含以下核心组件:
- 备份源:生产OceanBase集群,提供备份数据
- 备份管理:OBD或OCP,负责备份策略管理和任务调度
- 备份存储:独立的存储系统,用于存储备份数据
- 恢复目标:目标OceanBase集群,用于恢复备份数据
- 恢复管理:OBD或OCP,负责恢复任务管理和执行
1.2 组件职责
| 组件 | 主要职责 |
|---|---|
| 备份源 | 提供备份数据,执行备份操作 |
| 备份管理 | 制定备份策略,调度备份任务,监控备份状态 |
| 备份存储 | 安全存储备份数据,提供数据访问接口 |
| 恢复目标 | 接收恢复数据,执行恢复操作 |
| 恢复管理 | 制定恢复计划,调度恢复任务,监控恢复状态 |
备份策略规范
2.1 备份类型定义
| 备份类型 | 定义 | 适用场景 |
|---|---|---|
| 全量备份 | 备份所有数据 | 定期备份,建立恢复基准 |
| 增量备份 | 备份自上次备份以来的变化数据 | 日常备份,减少备份时间和空间 |
| 差异备份 | 备份自上次全量备份以来的变化数据 | 特定场景下的备份需求 |
| 日志备份 | 备份Redo日志 | 实时数据保护,支持PITR |
2.2 备份频率规范
| 数据类型 | 全量备份频率 | 增量备份频率 | 日志备份频率 |
|---|---|---|---|
| 核心业务数据 | 每周1次 | 每天1次 | 实时 |
| 重要业务数据 | 每2周1次 | 每天1次 | 每小时1次 |
| 一般业务数据 | 每月1次 | 每2天1次 | 每4小时1次 |
| 归档数据 | 每季度1次 | 按需 | 按需 |
2.3 备份保留期规范
| 备份类型 | 保留期 | 备注 |
|---|---|---|
| 全量备份 | 30天 | 核心业务可延长至90天 |
| 增量备份 | 与对应全量备份相同 | 随全量备份自动清理 |
| 日志备份 | 与对应全量备份相同 | 随全量备份自动清理 |
| 归档备份 | 1年以上 | 根据合规要求调整 |
备份操作规范
3.1 备份前准备
| 检查项 | 检查内容 | 责任人 |
|---|---|---|
| 集群状态 | 确认集群状态正常,无异常告警 | 运维工程师 |
| 存储空间 | 确认备份存储有足够空间 | 运维工程师 |
| 网络状态 | 确认备份源与存储之间网络通畅 | 运维工程师 |
| 业务负载 | 确认当前业务负载处于低峰期 | 应用负责人 |
| 备份策略 | 确认备份策略配置正确 | 运维工程师 |
3.2 备份执行流程
- 发起备份任务:通过OBD或OCP发起备份任务
- 备份任务验证:验证备份任务参数和配置
- 执行备份操作:集群执行备份操作,生成备份集
- 备份集校验:自动校验备份集的完整性
- 备份状态确认:确认备份任务成功完成
- 备份日志记录:记录备份操作日志和结果
3.3 备份命令规范
使用OBD执行备份
bash
# 全量备份nobd cluster backup obcluster --type full --destination file:///data/backup --retention-days 30
# 增量备份nobd cluster backup obcluster --type incremental --destination file:///data/backup --retention-days 30使用SQL命令执行备份
sql
-- 全量备份
BACKUP FULL FOR TENANT tenant_name TO 'full_backup_20230601' BACKUP_DESTINATION = 'file:///data/backup';
-- 增量备份
BACKUP INCREMENTAL FOR TENANT tenant_name TO 'incr_backup_20230601' BACKUP_DESTINATION = 'file:///data/backup';备份存储规范
4.1 存储介质要求
| 存储类型 | 性能要求 | 可靠性要求 | 适用场景 |
|---|---|---|---|
| SSD | 高IOPS,低延迟 | 99.999% | 核心业务备份 |
| SAS | 中等IOPS,中等延迟 | 99.99% | 重要业务备份 |
| NAS | 共享访问,易管理 | 99.9% | 一般业务备份 |
| 对象存储 | 高扩展性,低成本 | 99.99% | 归档数据备份 |
4.2 存储位置规范
- 物理隔离:备份存储应与生产集群物理隔离,避免单点故障
- 异地存储:核心业务备份应存储在异地,距离生产中心至少50公里
- 多副本存储:备份数据应采用至少3副本存储,确保数据可靠性
- 访问控制:备份存储应设置严格的访问控制,仅允许授权用户访问
4.3 存储加密规范
- 传输加密:备份数据传输过程应采用TLS/SSL加密
- 存储加密:备份数据存储应采用AES-256加密
- 密钥管理:加密密钥应采用独立的密钥管理系统,定期轮换
- 加密验证:定期验证加密状态,确保备份数据安全
恢复操作规范
5.1 恢复分类
| 恢复类型 | 定义 | 适用场景 |
|---|---|---|
| 完全恢复 | 恢复到备份结束时的状态 | 数据完全丢失场景 |
| 时间点恢复(PITR) | 恢复到指定时间点 | 数据逻辑错误场景 |
| 日志点恢复 | 恢复到指定LSN位置 | 精确恢复场景 |
| 表级恢复 | 仅恢复特定表 | 表数据丢失场景 |
| 库级恢复 | 仅恢复特定数据库 | 库数据丢失场景 |
5.2 恢复前准备
| 检查项 | 检查内容 | 责任人 |
|---|---|---|
| 恢复需求确认 | 确认恢复范围、时间点和目标 | 业务负责人 |
| 备份集可用性 | 确认所需备份集存在且完整 | 运维工程师 |
| 恢复目标状态 | 确认恢复目标集群状态正常 | 运维工程师 |
| 存储空间 | 确认恢复目标有足够空间 | 运维工程师 |
| 业务影响评估 | 评估恢复对业务的影响范围和时间 | 业务负责人 |
5.3 恢复执行流程
- 制定恢复计划:明确恢复范围、时间点、步骤和责任人
- 停止业务访问:根据恢复类型,停止相关业务访问
- 执行恢复操作:通过OBD或OCP执行恢复任务
- 恢复验证:验证恢复后的数据完整性和一致性
- 恢复后测试:进行功能测试和性能测试
- 恢复业务访问:逐步恢复业务访问
- 恢复日志记录:记录恢复操作日志和结果
5.4 恢复命令规范
使用OBD执行恢复
bash
# 全量恢复nobd cluster restore obcluster --backup-set full_backup_20230601 --destination file:///data/restore
# 增量恢复nobd cluster restore obcluster --backup-set incr_backup_20230601 --destination file:///data/restore
# 时间点恢复nobd cluster restore obcluster --backup-set full_backup_20230601 --destination file:///data/restore --time "2023-06-01 12:00:00"使用SQL命令执行恢复
sql
-- 全量恢复
RESTORE FULL FROM 'full_backup_20230601' BACKUP_DESTINATION = 'file:///data/backup' RESTORE_DESTINATION = 'file:///data/restore' TENANT = tenant_name;
-- 增量恢复
RESTORE INCREMENTAL FROM 'incr_backup_20230601' BACKUP_DESTINATION = 'file:///data/backup' RESTORE_DESTINATION = 'file:///data/restore' TENANT = tenant_name;
-- 时间点恢复
RESTORE INCREMENTAL FROM 'incr_backup_20230601' BACKUP_DESTINATION = 'file:///data/backup' RESTORE_DESTINATION = 'file:///data/restore' TENANT = tenant_name UNTIL TIME '2023-06-01 12:00:00';备份恢复监控规范
6.1 监控指标
备份监控指标
| 指标名称 | 监控频率 | 告警阈值 | 告警级别 |
|---|---|---|---|
| 备份任务成功率 | 实时 | <95% | 严重 |
| 备份完成时间 | 实时 | >预期时间2倍 | 警告 |
| 备份集大小增长率 | 每天 | >50% | 警告 |
| 备份存储使用率 | 每小时 | >80% | 警告 |
| 备份存储使用率 | 每小时 | >90% | 严重 |
恢复监控指标
| 指标名称 | 监控频率 | 告警阈值 | 告警级别 |
|---|---|---|---|
| 恢复任务成功率 | 实时 | <100% | 严重 |
| 恢复完成时间 | 实时 | >RTO | 严重 |
| 恢复数据一致性 | 实时 | 不一致 | 严重 |
| 恢复后性能下降 | 实时 | >20% | 警告 |
6.2 监控工具
| 工具 | 适用场景 | 功能特点 |
|---|---|---|
| OCP | 企业级监控 | 可视化界面,全面监控,告警管理 |
| OBD | 命令行监控 | 轻量级,适合测试环境 |
| Prometheus + Grafana | 自定义监控 | 灵活配置,丰富的可视化图表 |
| Zabbix | 传统监控 | 广泛使用,成熟稳定 |
6.3 告警处理流程
- 告警触发:监控系统检测到异常,触发告警
- 告警通知:通过邮件、短信、钉钉等方式通知相关人员
- 告警确认:接收告警人员确认告警,记录告警信息
- 问题排查:根据告警信息,排查问题原因
- 问题处理:采取相应措施处理问题
- 告警恢复:确认问题解决,恢复告警状态
- 告警复盘:分析告警原因,优化监控策略
备份恢复验证规范
7.1 备份验证
| 验证项目 | 验证内容 | 验证频率 | 责任人 |
|---|---|---|---|
| 备份集存在性 | 确认备份集已生成并存储 | 每次备份后 | 运维工程师 |
| 备份集完整性 | 验证备份集的完整性校验和 | 每次备份后 | 运维工程师 |
| 备份集可用性 | 验证备份集可以被访问和读取 | 每周 | 运维工程师 |
| 备份策略合规性 | 验证备份策略符合规范要求 | 每月 | 运维主管 |
7.2 恢复验证
| 验证项目 | 验证内容 | 验证频率 | 责任人 |
|---|---|---|---|
| 恢复成功率 | 验证恢复任务能够成功执行 | 每月 | 运维工程师 |
| 恢复数据完整性 | 验证恢复后数据完整 | 每月 | 运维工程师 |
| 恢复数据一致性 | 验证恢复后数据一致 | 每月 | 运维工程师 |
| 恢复时间 | 验证恢复时间符合RTO要求 | 每月 | 运维工程师 |
| 恢复后性能 | 验证恢复后性能符合要求 | 每月 | 运维工程师 |
7.3 验证方法
备份集完整性验证
bash
# 使用OBD验证备份集nobd cluster backup validate --backup-set full_backup_20230601 --destination file:///data/backup
# 使用SQL命令验证备份集
SELECT * FROM oceanbase.__all_backup_set WHERE name = 'full_backup_20230601' AND is_valid = 1;恢复数据验证
bash
# 数据量验证
SELECT COUNT(*) FROM table_name;
# 数据一致性验证
CHECKSUM TABLE table_name;
# 业务逻辑验证
-- 执行业务关键SQL,验证结果正确性备份恢复文档规范
8.1 文档类型
| 文档类型 | 主要内容 | 适用场景 |
|---|---|---|
| 备份恢复策略文档 | 备份策略、恢复流程、责任分工 | 总体指导 |
| 备份操作手册 | 备份操作步骤、命令示例、注意事项 | 日常备份操作 |
| 恢复操作手册 | 恢复操作步骤、命令示例、注意事项 | 恢复操作指导 |
| 备份恢复报告 | 备份恢复执行情况、结果分析 | 定期汇报 |
| 故障恢复演练报告 | 演练过程、结果、改进措施 | 演练总结 |
8.2 文档内容要求
- 完整性:包含所有必要的信息,无遗漏
- 准确性:内容准确无误,与实际情况一致
- 清晰性:结构清晰,语言简洁,易于理解
- 可操作性:提供详细的操作步骤和命令示例
- 及时性:定期更新,确保与当前环境一致
- 可追溯性:包含版本信息、修改记录和审批信息
8.3 文档管理
- 存储位置:文档应存储在统一的文档管理系统中
- 访问权限:根据角色设置不同的访问权限
- 版本控制:使用版本控制系统管理文档变更
- 定期更新:每季度至少更新一次,环境变化时及时更新
- 审核机制:文档更新需经过审核,确保质量
备份恢复演练规范
9.1 演练类型
| 演练类型 | 定义 | 频率要求 |
|---|---|---|
| 常规演练 | 按照计划进行的恢复演练 | 每月1次 |
| 应急演练 | 模拟真实故障场景的恢复演练 | 每季度1次 |
| 全流程演练 | 包含备份、存储、恢复的全流程演练 | 每半年1次 |
| 跨集群演练 | 跨集群的备份恢复演练 | 每年1次 |
9.2 演练流程
- 演练计划制定:明确演练目标、范围、时间和人员
- 演练准备:准备演练环境、备份集和工具
- 演练执行:按照计划执行演练步骤
- 演练监控:监控演练过程,记录关键指标
- 演练验证:验证演练结果,确认恢复成功
- 演练总结:总结演练经验,提出改进措施
- 演练报告:编写演练报告,提交相关人员
9.3 演练评估
| 评估维度 | 评估内容 | 评分标准 |
|---|---|---|
| 演练准备充分性 | 演练环境、备份集和工具准备情况 | 0-10分 |
| 演练执行规范性 | 演练步骤执行的规范性和准确性 | 0-10分 |
| 恢复成功率 | 恢复任务的成功比例 | 0-10分 |
| 恢复时间 | 恢复完成时间是否符合RTO要求 | 0-10分 |
| 数据完整性 | 恢复后数据的完整性和一致性 | 0-10分 |
| 团队协作 | 演练过程中团队的协作情况 | 0-10分 |
| 问题处理能力 | 演练过程中问题的处理能力 | 0-10分 |
备份恢复安全规范
10.1 访问控制
| 控制项 | 要求 |
|---|---|
| 备份管理系统访问 | 采用强密码认证,开启多因素认证 |
| 备份存储访问 | 限制IP访问,采用最小权限原则 |
| 备份数据访问 | 加密传输,身份认证 |
| 恢复操作授权 | 分级授权,审批机制 |
| 审计日志访问 | 仅允许审计人员访问 |
10.2 数据保护
| 保护措施 | 要求 |
|---|---|
| 备份数据加密 | 采用AES-256加密算法 |
| 加密密钥管理 | 独立存储,定期轮换 |
| 备份数据脱敏 | 敏感数据备份前脱敏处理 |
| 备份数据销毁 | 符合合规要求,确保数据不可恢复 |
10.3 合规要求
| 合规类型 | 要求 |
|---|---|
| 数据备份保留 | 符合行业法规要求,如金融行业要求保留5年以上 |
| 备份恢复审计 | 所有备份恢复操作必须记录审计日志 |
| 数据恢复审批 | 重要数据恢复必须经过审批 |
| 演练记录 | 演练过程和结果必须记录归档 |
备份恢复自动化规范
11.1 自动化范围
| 自动化类型 | 具体内容 |
|---|---|
| 备份任务自动化 | 自动执行备份任务,无需人工干预 |
| 备份验证自动化 | 自动验证备份集的完整性和可用性 |
| 备份清理自动化 | 自动清理过期备份,释放存储空间 |
| 恢复测试自动化 | 自动执行恢复测试,验证备份可恢复性 |
| 监控告警自动化 | 自动监控备份恢复状态,触发告警 |
| 报告生成自动化 | 自动生成备份恢复报告,定期发送 |
11.2 自动化工具
| 工具 | 适用场景 | 功能特点 |
|---|---|---|
| OCP | 企业级自动化 | 全面的备份恢复自动化功能 |
| OBD | 命令行自动化 | 轻量级,适合脚本集成 |
| Ansible | 配置管理自动化 | 灵活的自动化编排 |
| Shell脚本 | 简单任务自动化 | 快速开发,易于维护 |
11.3 自动化流程设计
- 需求分析:明确自动化需求和目标
- 流程设计:设计自动化流程,包含异常处理
- 脚本开发:编写自动化脚本,包含日志记录
- 测试验证:在测试环境中验证自动化流程
- 上线部署:在生产环境中部署自动化流程
- 监控维护:监控自动化流程运行情况,定期维护
备份恢复常见问题处理
12.1 备份失败处理
| 失败原因 | 处理方法 |
|---|---|
| 存储空间不足 | 清理过期备份或扩展存储空间 |
| 网络连接中断 | 检查网络连接,重新执行备份 |
| 集群状态异常 | 修复集群问题,重新执行备份 |
| 备份配置错误 | 修正备份配置,重新执行备份 |
| 权限不足 | 检查权限设置,授予所需权限 |
12.2 恢复失败处理
| 失败原因 | 处理方法 |
|---|---|
| 备份集损坏 | 使用其他可用备份集,或重新备份 |
| 恢复目标空间不足 | 清理空间或扩展存储,重新执行恢复 |
| 恢复配置错误 | 修正恢复配置,重新执行恢复 |
| 数据一致性问题 | 检查备份集,使用一致性备份 |
| 版本不兼容 | 确保备份集与目标集群版本兼容 |
12.3 恢复后问题处理
| 问题类型 | 处理方法 |
|---|---|
| 性能下降 | 优化配置,调整资源,监控性能变化 |
| 数据不一致 | 检查恢复过程,重新执行恢复 |
| 功能异常 | 检查应用配置,修复应用问题 |
| 安全问题 | 检查权限设置,修复安全漏洞 |
备份恢复持续改进
13.1 改进机制
- 定期评审:每季度对备份恢复体系进行评审
- 问题分析:分析备份恢复过程中出现的问题
- 经验总结:总结备份恢复经验,形成最佳实践
- 技术更新:跟踪OceanBase备份恢复技术发展,及时更新
- 流程优化:优化备份恢复流程,提高效率和可靠性
13.2 改进指标
| 指标名称 | 目标值 | 测量频率 |
|---|---|---|
| 备份成功率 | ≥99% | 每月 |
| 恢复成功率 | 100% | 每月 |
| 恢复时间 | ≤RTO | 每次恢复 |
| 备份存储利用率 | ≤80% | 每月 |
| 演练覆盖率 | 100% | 每季度 |
13.3 最佳实践分享
- 内部分享:定期组织内部分享会,交流备份恢复经验
- 外部交流:参加行业会议,学习外部最佳实践
- 文档沉淀:将最佳实践沉淀为文档,便于传播和复用
- 案例库建设:建立备份恢复案例库,供参考和学习
附则
14.1 规范适用范围
本规范适用于所有使用OceanBase数据库的生产环境、测试环境和开发环境。
14.2 规范生效日期
本规范自发布之日起生效,如有修订,以最新版本为准。
14.3 规范解释权
本规范的解释权归OceanBase运维团队所有。
14.4 违规处理
违反本规范的行为,将根据情节轻重给予相应的处理,包括口头警告、书面警告和绩效考核扣分等。
常见问题(FAQ)
Q1: 如何确定合适的备份频率?
A1: 备份频率应根据数据变更频率、业务重要性和存储成本综合考虑。核心业务建议每周1次全量备份,每天1次增量备份;一般业务建议每2周1次全量备份,每2天1次增量备份。
Q2: 备份数据应该存储多久?
A2: 备份数据的保留期应根据业务需求和合规要求确定。核心业务建议保留30-90天,一般业务建议保留7-30天,归档数据建议保留1年以上。
Q3: 如何验证备份的可恢复性?
A3: 定期进行恢复演练是验证备份可恢复性的最佳方法。建议每月进行1次常规恢复演练,每季度进行1次应急演练,每半年进行1次全流程演练。
Q4: 什么是时间点恢复(PITR)?
A4: 时间点恢复是指将数据库恢复到指定的时间点,而不是备份结束的时间点。这需要结合全量备份和日志备份来实现,适用于数据逻辑错误的场景。
Q5: 如何提高恢复速度?
A5: 提高恢复速度的方法包括:缩短备份链长度、使用高性能存储、增加恢复并发度、优化恢复配置、定期进行恢复测试等。
Q6: 备份恢复自动化的好处是什么?
A6: 备份恢复自动化可以提高效率、减少人为错误、确保备份恢复的及时性和一致性、便于监控和管理,同时降低运维成本。
Q7: 如何选择备份存储介质?
A7: 备份存储介质的选择应考虑性能、可靠性、成本和扩展性等因素。核心业务建议使用SSD或高性能NAS,一般业务可以使用普通NAS或对象存储。
Q8: 备份恢复审计的重要性是什么?
A8: 备份恢复审计可以记录所有备份恢复操作,便于追溯和 accountability,同时有助于发现异常操作和安全漏洞,确保数据安全和合规要求。
