背景
服务器上的 MariaDB 存着监控数据，虽然不多，但没了就没了。
做了个备份脚本：
dockerexecmy-mariadb mariadb-dump-uroot-p密码 --all-databases>backup.sql但从来没验证过——备份文件真的能恢复吗？
原因
备份不算备份，能恢复的才叫备份。
很多人做了备份，但从没验证过。真出事时才发现：
备份文件是空的（dump 命令写错了）
备份文件中途中断（数据库太大，命令超时被杀）
备份文件格式不对（编码问题、换行问题）
根本没配定时任务（备份文件是半年前的）
没演练过的备份，等于没有备份。
解决
第一步：写备份脚本
#!/bin/bashset-euopipefailBACKUP_DIR="/home/YOUR_USER/db-backups"KEEP_DAYS=7mkdir-p"$BACKUP_DIR"TS=$(date+%F-%H%M)BACKUP_FILE="$BACKUP_DIR/all-databases-$TS.sql"# 备份dockerexecmy-mariadb mariadb-dump\-uroot-pYOUR_DB_PASSWORD\--all-databases\--single-transaction\--routines--triggers--events\>"$BACKUP_FILE"# 验证：结尾必须有 "Dump completed"if!tail-5"$BACKUP_FILE"|grep-q"Dump completed";thenecho"❌ 备份不完整"rm-f"$BACKUP_FILE"exit1fi# 清理 7 天前的备份find"$BACKUP_DIR"-name"*.sql"-mtime+$KEEP_DAYS-deleteecho"✅ 备份完成:$BACKUP_FILE"关键参数：
| 参数 | 作用 |
|---|---|
--all-databases | 备份所有库 |
--single-transaction | 不锁表（InnoDB） |
--routines | 包含存储过程 |
--triggers | 包含触发器 |
--events | 包含定时事件 |
第二步：加到定时任务
crontab -e加一行（每天凌晨 3 点备份）：
0 3 * * * /home/YOUR_USER/backup.sh >> /home/YOUR_USER/backup.log 2>&1第三步：灾难恢复演练（关键）
这一步才是重点。
假设服务器挂了，要在新服务器上恢复。步骤：
- 拉一个干净的 MariaDB 容器
docker run -d --name test-mariadb \ -e MYSQL_ROOT_PASSWORD=临时密码 \ mariadb:latest- 等它健康
sleep 30 docker exec test-mariadb mariadb -uroot -p临时密码 -e "SELECT 1;"- 恢复备份
dockerexec-itest-mariadb mariadb-uroot-p临时密码<~/db-backups/all-databases-2026-10-06.sql- 验证数据真的恢复了
dockerexectest-mariadb mariadb-uroot-p临时密码-e"SHOW DATABASES;"dockerexectest-mariadb mariadb-uroot-p临时密码 test_db-e"SELECT COUNT(*) FROM server_metrics;"看到数据条数正常，才算恢复成功。
5. 清理测试容器
dockerstop test-mariadb&&dockerrmtest-mariadb第四步：把演练写进 SOP
每次改过备份脚本或升级数据库版本后，必做一次演练。
三个坑
坑 1：备份文件没验证完整性
mariadb-dump 中途超时被杀，会生成一个半截的 sql 文件，看着有几十 M，其实恢复不了。
验证方法：文件结尾必须有 – Dump completed on …。没有就不算成功。
坑 2：只备份，不演练
备份脚本写得再漂亮，没演练过就不知道能不能用。等到真出事才发现备份坏了——那就晚了。
建议：每季度演练一次，把恢复流程跑一遍。
坑 3：备份文件没异地、没保留策略
备份全在同一台服务器上——服务器硬盘坏了，备份也没了。
建议：
保留 7 天（本地）
每周拉一份到对象存储（腾讯云 COS、阿里云 OSS）
3 个月内不删除
阅读分享：强烈推荐一本小说《黎明之剑》。它既有宏大的世界观，也融入了对信息、网络与文明安全的思考。喜欢宏大叙事和网络安全题材的朋友，相信会读得很过瘾。
