Linux MariaDB备份策略是什么

Linux MariaDB备份策略

一 策略总览

• 备份层级与目标
  • 明确RPO/RTO目标（如允许丢失的数据量、可接受的停机时间），据此选择备份类型与频率。
  • 采用3-2-1备份原则：至少保留3份副本、存放在2种不同介质、其中1份异地/离线。
• 备份类型组合
  • 生产常用组合为：全量 + 增量（或全量 + 差异），用全量保障基线，用增量/差异缩短恢复时间并节省空间。
  • 结合二进制日志（binlog）实现时间点恢复（PITR），覆盖误操作场景。
• 备份对象范围
  • 数据文件（InnoDB/MyISAM）、二进制日志与InnoDB事务日志、存储过程/函数/触发器/事件、配置文件（如 my.cnf）、以及必要的操作系统与账号凭据。
• 存储与保留
  • 本地保留满足快速回滚的窗口（如7–14天），远程/云端保留更长周期（如30–90天），并配置定期校验与清理策略。

二 方法选择与适用场景

三 推荐备份策略模板

• 通用中小型实例（InnoDB为主）
  • 全量：每日02:00用mysqldump执行全库备份，启用**–single-transaction --master-data=2 -F -R -E --triggers --hex-blob**，并压缩归档。
  • 增量：开启binlog，每日滚动一次；保留7–14天的binlog用于PITR。
  • 传输与保留：本地保留7–14天，通过rsync/scp或企业备份平台同步到远程/云端；定期清理过期备份。
  • 校验与演练：每周抽样还原演练，校验表数量/行数/关键业务数据一致性。
• 大型/高并发实例（InnoDB为主）
  • 全量：每周一次用Mariabackup/XtraBackup做热备全量；准备阶段执行**–prepare**。
  • 增量：每日1–3次做增量备份（基于上次全量/增量），保留7–14天增量集。
  • PITR：全量时间点 + 增量/或binlog回放到故障前；关键业务建议定期演练PITR。
  • 高可用：部署主从/组复制用于快速切换，但不替代备份；备份仍按全量+增量执行。

四 关键配置与实施要点

• 启用二进制日志
  • my.cnf 配置：log-bin，建议与数据目录分盘；定期FLUSH LOGS并归档旧binlog。
• 备份账号与权限
  • 建议创建专用备份账号：GRANT RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT ON . TO ‘backupuser’@‘localhost’。
• 一致性快照流程（LVM）
  • 执行：FLUSH TABLES WITH READ LOCK; FLUSH LOGS; SHOW MASTER STATUS; 记录File/Position→创建只读快照→立即UNLOCK TABLES→拷贝快照→删除快照。
• 物理备份准备与回滚
  • 全量准备：mariabackup/xtrabackup --prepare --target-dir=…；合并增量时用**–redo-only**（最后一个增量不加）。
  • 恢复：systemctl stop mariadb → 数据目录清空 → –copy-back/move-back → chown -R mysql:mysql → 启动服务。
• 时间点恢复（PITR）
  • 从全量备份的CHANGE MASTER/xtrabackup_binlog_info位点开始，使用mysqlbinlog导出增量SQL并回放；如涉及误删，可在导出文件中剔除DROP/TRUNCATE语句后再导入。

五 监控 验证与常见误区

• 监控与告警
  • 监控备份成功率、时长、备份大小、保留天数；对失败/延迟设置告警；定期校验备份可用性（抽样还原）。
• 常见误区
  • 仅依赖主从复制而不做备份（误删同样复制到从库）。
  • binlog与数据同盘（同盘故障导致日志与数据同时丢失）。
  • 只做全量不做增量/PITR（恢复时间不可控）。
  • 备份后不校验与演练（恢复时才发现不可用）。