备份做了却恢复不了？多半是没做过恢复演练

来源：互联网时间：2026-09-29

有站长告诉我，他每天定时备份，觉得万无一失。直到一次误删库，兴冲冲去恢复，才发现备份文件是零字节，或者导进去后网站报错打不开。那一刻才明白：备份存在不等于能恢复。没演练过的备份，只是心理上的安慰剂。

恢复演练不是可选项，是备份流程里和“备份”同等重要的一半。下面把常见的“假备份”和一套能落地的演练动作拆开讲，照着做一遍，你就知道自己的备份到底靠不靠谱。

先认清几种最常见的假备份

第一种是空壳文件。脚本因为密码错误、权限不足悄悄失败，却照样生成了一个几 KB 的压缩包。第二种是只备了文件没备数据库，恢复后前台能开、后台数据全空。第三种是数据库用了 myisam 表却没锁表，导出过程中正好有写入，恢复出来表是坏的。第四种是备份在了同一块磁盘，磁盘一挂，备份和数据一起没。

下面这段检查脚本能帮你排掉头两种坑：它遍历最近的备份目录，逐项核对文件大小、SQL 是否解压可读、是否同时含文件和数据库。要改的是 BACKUP_ROOT 指向你的备份根目录。跑完看输出，哪一项标了“异常”就去修哪一项。

# 备份体检：检查最近 N 份备份是否为有效非空文件

#!/bin/bash

BACKUP_ROOT="/backup/local"

for d in $(ls -t "$BACKUP_ROOT" | head -7); do

dir="$BACKUP_ROOT/$d"

f="$dir/files.tar.gz"; s="$dir/db.sql.gz"

fsize=$(stat -c%s "$f" 2>/dev/null || echo 0)

ssize=$(stat -c%s "$s" 2>/dev/null || echo 0)

headchk=$(zcat "$s" 2>/dev/null | head -1)

echo "$d -> files:$fsize db:$ssize sql_head:${headchk:0:20}"

done

输出里如果 db 的大小是 0，或者 sql_head 看不出 CREATE TABLE 这类关键字，这份备份就是废的，趁早重配脚本。别等出事才发现。

恢复演练的标准动作

演练要在隔离环境做，不要直接动生产库。步骤固定为四步：解压文件到临时目录、建一个全新的测试库、把数据库导进去、用测试域名把站点挂起来看页面。每一步都要能走通，才算这次演练合格。下面把数据库导入这步单独拎出来，因为它最容易被忽略——很多人从没真正导入过，只看过文件存在。

# 在测试库真实导入一次，验证备份可恢复

#!/bin/bash

TEST_DB="restore_drill_$(date +%F)"

mysql -u root -p"$ROOT_PASS" -e "CREATE DATABASE $TEST_DB"

zcat /backup/local/$(date +%F)/db.sql.gz | mysql -u root -p"$ROOT_PASS" "$TEST_DB"

tbl=$(mysql -u root -p"$ROOT_PASS" -N -e "SHOW TABLES FROM $TEST_DB" | wc -l)

echo "测试库 $TEST_DB 已恢复，表数量：$tbl

表数量和你熟悉的线上表数一致，且没有报错，说明数据库备份是健康的。如果表数为 0，立刻回去查 mysqldump 的账号权限，多半是备份账号没有对应库的 SELECT 权限，导出来是空库。

演练频率和记录不能省

频率怎么定？核心业务站建议每月一次完整演练，至少每季度一次。低频站可以拉长，但别超过半年，因为环境会变、脚本会悄悄坏。每次演练后留一行记录：日期、恢复耗时、数据是否完整、发现的问题。这份记录是你对备份信任度的唯一依据。

把演练结果接回备份配置

演练发现的问题要反向改配置：空壳文件就加大小校验和告警；只备文件就补上数据库导出；同盘就加异地同步。一个良性的循环是：备份自动跑、脚本自检、定期演练、问题回修。断了任何一环，备份都会慢慢变成摆设。