数据库备份策略设计说明书

数据库备份策略设计说明书一、总则1.1目的与适用范围备份不是"把数据拷走"这么简单——它是灾难发生时企业最后一道、也是唯一一道数据防线。本说明书用于指导生产数据库备份体系的规划、实施、验证与应急恢复，适用于本公司所有承载业务数据的生产库（MySQL8.0主从集群、PostgreSQL14、Oracle19c单实例）、准生产环境数据库（按生产策略50%频率执行），不适用于纯静态配置类数据。读者对象为DBA（执行主体）、运维值班人员（夜间响应）、研发负责人（确认业务数据重要性分级）与IT总监（审批资源与演练计划）。1.2术语与恢复目标术语定义本公司目标值RPO恢复点目标，即灾难时可容忍的最大数据丢失时长核心业务≤5分钟，一般业务≤1小时RTO恢复时间目标，即从故障确认到业务恢复的最大时长核心业务≤2小时，一般业务≤8小时全量备份对数据库全部数据页做完整拷贝每周1次增量备份仅备份自上次备份以来变更的数据页每日1次日志归档持续备份事务日志（binlog/WAL/redo）准实时，延迟≤1分钟RPO/RTO由业务方在《数据重要性分级表》（附件1）中签字确认，DBA无权单方面放宽或收紧。任何调整走变更流程（见6.3）。二、数据分级与策略矩阵2.1数据重要性分级不同级别的数据对备份频率、保留期、验证强度的要求差异极大，"一套策略管所有库"要么浪费存储、要么在关键时刻不够用。分级标准：•A级（核心）：直接产生收入或承担法定留存义务的数据。订单库、支付流水库、用户账户库。特征：中断30分钟即触发客服工单激增，数据丢失涉及资损或监管处罚。•B级（重要）：支撑内部运营的数据。ERP、CRM、内部权限库、内容管理库。特征：可容忍4小时手工补录。•C级（一般）：可从源头重新生成的数据。日志分析库、测试环境衍生数据、报表缓存库。特征：丢失后重建成本低于备份存储成本。2.2备份策略矩阵数据级别全量备份增量备份日志归档本地保留异地保留恢复验证A级每周日01:00每日01:00准实时30天90天每月1次B级每周日02:00每日02:30每15分钟14天30天每季度1次C级每月1日03:00无无7天无每年1次备份窗口统一安排在01:00—05:00（业务流量最低时段，据近90天监控，该时段QPS不足峰值10%）。A级库全量备份必须使用从库执行，禁止在主库发起（全量备份的IO与CPU消耗会引起主库主从延迟突增，进而触发基于binlog的准实时日志推送中断——这正是RPO失守的典型链条）。三、备份实施规范3.1备份方式选择存在多种技术路线时按以下优先级执行：•优先使用物理备份（MySQL用XtraBackup8.0，PostgreSQL用pg_basebackup+WAL归档，Oracle用RMANlevel0/1）：物理备份恢复速度最快，A级库RTO2小时的硬指标只有物理备份能满足。TB级库逻辑备份恢复动辄10小时以上。•若数据库版本过旧（低于XtraBackup支持矩阵）或单库容量小于200GB，可用逻辑备份mysqldump--single-transaction替代，且必须附加--set-gtid-purged=ON（否则恢复到新实例时GTID断裂，主从无法接入）。•严禁对InnoDB表使用LOCKTABLES方式的mysqldump（会阻塞业务写入，造成全库DML挂起）；严禁在主库直接cp数据目录（拷贝期间数据页持续变更，备份集内部不一致，恢复后必然起库失败或数据页损坏）。3.2备份脚本要点以下为核心库备份脚本骨架（cron调度，实际部署时补全密钥管理部分）：#!/bin/bash

#A级MySQL从库每日增量备份

set-euopipefail

BACKUP_DIR=/data/backup/mysql/$(date+%F)

LOG_FILE=$BACKUP_DIR/backup.log

mkdir-p$BACKUP_DIR

#--safe-slave-backup:暂停SQL线程直至relaylog回放完毕，

#确保备份的是一致性快照；不开启则备份期间数据页对应binlog位点漂移

xtrabackup--backup--target-dir=$BACKUP_DIR\

--safe-slave-backup--slave-info\

--stream=xbstream|gzip>$BACKUP_DIR/full.xb.gz2>$LOG_FILE

#校验备份完整性：gzip测试压缩流完整性+xtrabackupprepare前检查

gzip-t$BACKUP_DIR/full.xb.gz

#上传异地（对象存储），开启CRC校验

rclonecopy$BACKUP_DIR/full.xb.gzremote:mysql-$(hostname-s)/$(date+%F)/\

--checksum--transfers4

#备份成功后推送通知，失败触发告警

[$?-eq0]&&curl-s"$ALERT_URL?msg=backup_ok_$(hostname-s)"\

||curl-s"$ALERT_URL?msg=backup_FAIL_$(hostname-s)"关键约束：1.每个备份任务必须有独立的成功/失败通知。"没有消息就是好消息"在备份领域等于灾难——备份静默失败三个月后才发现，是最常见的真实事故形态。2.传输必须带校验（rclone--checksum或手工md5sum比对），对象存储上传中断导致的截断文件，不做校验无法察觉。3.备份文件必须加密后落盘异地：使用opensslenc-aes-256-cbc，密钥存放于独立密钥管理系统，禁止与备份文件同目录存放（否则异地副本泄露等于加密失效）。4.备份账号权限最小化：仅SELECT、RELOAD、LOCKTABLES、REPLICATIONCLIENT、BACKUP_ADMIN，禁止使用root备份。3.3日志归档（RPO5分钟的实现手段）A级库的准实时保护不靠高频全量，靠日志链。以MySQL为例：•开启log_bin与GTID模式，使用mysqlbinlog--read-from-remote-server--raw--stop-never持续拉取binlog到独立日志服务器，再由日志服务器推送至异地对象存储。•拉取延迟监控阈值：SHOWSLAVESTATUS中日志同步位点落后超过60秒触发P2告警（为什么是60秒：RPO目标5分钟，监控必须在RPO破线前留出人工处置窗口）。•错误做法后果：仅靠每日增量备份，主库磁盘整列损坏时丢失当日0点后全部数据——对订单库意味着当日全部交易流水不可追溯。四、备份验证——不做恢复演练的备份等于没有备份这是本策略中最容易被砍掉、也最不能砍掉的章节。备份文件存在且校验通过≠可以恢复成功，字符集、版本兼容、加密密钥丢失、隐藏的页损坏，只有真实恢复才能暴露。4.1验证方式分级•每日自动验证：备份完成后自动在验证沙箱（1台独立恢复主机，配置与生产从库同级）执行恢复至--apply-log完成阶段并起库，执行CHECKSUMTABLE抽查10张核心表，结果写入验证台账。全程自动化，耗时约40分钟（按A级库800GB估算，恢复吞吐约350MB/h，需提前规划）。•每月人工演练：每月第2个周三，DBA从最近备份集中随机抽取1个，完整恢复到指定时间点（PITR，回放binlog至随机选定的事务位点），比对SELECTCOUNT(*)与关键业务表抽样行内容。产出《月度恢复演练报告》，48小时内归档。•季度全链路演练：模拟主库整机故障场景——切断主库、在备用机房从零拉起实例、切换DNS/连接串、业务验证，全程计时并对照RTO2小时目标。演练未达标必须出具整改项并限期30天闭环。4.2异常处置验证失败时：首先冻结该备份集并标记为不可用（重命名加_INVALID后缀，防止误用于恢复）；立即对该库发起一次紧急全量备份；排查失败原因（TOP3原因：磁盘满、版本不匹配、加密密钥错误）并在24小时内出具分析；连续2次验证失败的库，上报IT总监并升级为P1事件。五、备份存储与保留管理•存储分层：本地磁盘保留最近7天备份（供快速恢复，RTO贡献最大）；30天内备份存对象存储标准型；超过30天转低频/归档存储（成本约为标准型1/3，据行业公开定价水平）。•保留期刚性约束：异地副本90天（A级）到期后自动删除，删除动作由对象存储生命周期策略执行，DBA手工恢复删除需双人复核。设置保留期上限的原因：无限保留会使存储成本线性膨胀（按当前数据增速估算，A级库年增约1.5TB原始数据，对应备份存储年增约4TB），同时过期备份的法律合规风险反而上升。•3-2-1原则落地：至少3份副本、2种介质（本地磁盘+对象存储）、1份异地（跨可用区存储，严禁同城单可用区存放全部副本——机房级断电/水灾/火灾场景下同区副本会同时灭失）。•恢复主机、备份盘空间必须预留120%数据容量余量，磁盘使用率达到85%触发告警（预留15%余量是恢复操作本身的缓冲空间，恢复过程临时文件、日志回放都需要额外空间，满了会导致恢复中途失败且无法续传）。六、应急恢复流程与故障分级6.1故障分级级别判定标准启动权限处置原则P3单表误删/误更新，主库仍可用DBA值班人员使用binlog闪回或延迟从库（STOPSLAVE;STARTSLAVEUNTIL定点恢复），窗口期业务侧冻结该表写入P2从库故障或备份任务连续失败超24小时DBA负责人优先重建从库；备份失效期间对该库加严监控，评估是否执行紧急全量P1主库数据不可访问（存储损坏、误删整库、勒索加密）IT总监+DBA负责人双人确认启动灾难恢复：从最近有效备份+日志归档做PITR，通知业务方进入降级/停服流程P1的双人确认机制不可省略——误判为P1而触发全量恢复，本身会引入1—2小时的业务中断；反过来，确认拖延则扩大数据丢失窗口。确认通道：值班电话+企业IM群同步，15分钟内未联系上第一顺位负责人则自动升级至第二顺位（通讯录见附件2）。6.2P1恢复操作顺序1.确认故障范围（防止把可用从库误毁）：15分钟内完成，先只读隔离主从所有节点。2.选定恢复目标时间点：以误操作/故障发生的binlog位点或时间戳为界，恢复至该点前1个事务，业务方签字确认该时间点。3.在备用主机执行恢复：还原最近全量→应用最近增量→回放binlog至目标位点。全程每30分钟在事故群通报进度。4.起库后执行数据一致性校验：核心表行数比对、最近100笔交易抽查、业务方回归验证，业务方书面（IM截图归档）确认后切流。5.恢复完成不等于事件结束：72小时内必须完成事故复盘报告，至少回答三个问题——RPO实际损失多少、RTO实际耗时多少与目标差距、哪个环节的预防措施失效。6.3变更管理备份策略变更（频率、保留期、存储位置、脚本）一律走变更流程：提交变更单（含变更内容、影响分析、回退方案）→DBA负责人评审→IT总监审批（涉及A级库时）→变更实施后连续2个备份周期验证有效。紧急修复类变更可先执行后补单，但补单必须在24小时内完成。七、职责分工与考核•DBA：备份任务运维、验证执行、异常处置、月度演练报告。备份成功率月度指标≥99%，验证通过率100%。•运维值班：夜间备份告警响应（P2以上告警15分钟内响应，先按runbook止血，DBA到场前不做恢复类操作）。•研发/业务负责人：数据分级确认、恢复演练的业务侧校验、P1恢复时间点签字。•IT总监：策略审批、季度演练观摩、资源保障（验证主机、异地存储预算）。附件1：数据重要性分级登记表（样表）库名级别业务负责人（确认签字）RPO/RTO日均数据增量保留期备注order_dbA张某某5min/2h约4GB本地30天/异地90天支付关联库crm_dbB李某某1h/8h约800MB本地14天/异地30天report_tmpC王某某24h/24h约2GB本地7天可由源数据重建附件2：备份与恢复应急通讯录（样表）角色姓名值班电话备用联系方式升级顺位DBA值班张某某138******企业IM@dba-oncall1DBA负责人李某某139******137******2运维值班值班台136******——1（仅P2止血）IT总监王某某135******——3（P1确认）附件3：每日备份检查表（打印版）检查项判定标准结果备注昨夜A级库备份任务状态通知渠道收到backup_ok□是□否