Shell on 寻 Mi 处

写了十几版之后，我的备份脚本终于靠谱了

Thu, 05 Mar 2026 11:30:00 +0800

我最早的那个备份脚本只有一行：

`1`	`tar -czf /backup/site-$(date +%F).tar.gz /srv/www`

放在 crontab 里，每天跑一次。跑了三个月，我从来没打开看过。

后来有一次我要恢复一个误删的文件，才发现那个目录里堆了九十多个压缩包，最大的一个只有 12 字节。

原因是 /srv/www 下面有个目录权限不对，tar 读不了，直接失败。但因为命令在 crontab 里，报错输出到邮件，而我没配邮件，所以什么都没看到。

九十天的备份，全是空的。

从那之后，我把这个脚本重写了十几遍，加了一堆东西。这篇记录一下最终的样子，以及每一处为什么要那么写。

最基础的要求

一个好的备份脚本，至少要满足这几条。

跑失败的时候要能知道。不能像我第一次那样，默默失败九十天。

备份文件本身要能验证。不能只看退出码，得实际检查文件大小和内容完整性。

不能并发跑。如果上一次还没跑完，下一次又启动，两个进程同时写同一个文件，结果就是坏的。

过期的东西要清理。不然磁盘会被占满，最后连带把系统搞挂。

异地要有一份。本机的备份防不了磁盘坏和机器丢。

脚本

#!/usr/bin/env bash
set -Eeuo pipefail
IFS=$'\n\t'

# ---------- 配置 ----------
BACKUP_ROOT="/backup"
SOURCE_DIRS=("/srv/www" "/srv/git" "/etc/nginx")
KEEP_DAYS=14
LOG_FILE="/var/log/backup.log"
LOCK_FILE="/var/run/backup.lock"
REMOTE="remote:mybackup"
TG_TOKEN=""
TG_CHAT=""

# ---------- 工具函数 ----------
log() {
    printf '[%s] %s\n' "$(date '+%F %T')" "$*" | tee -a "$LOG_FILE"
}

fail() {
    log "ERROR: $*"
    notify "备份失败: $*"
    exit 1
}

notify() {
    [[ -z "$TG_TOKEN" ]] && return 0
    curl -s -X POST "https://api.telegram.org/bot${TG_TOKEN}/sendMessage" \
        -d "chat_id=${TG_CHAT}" \
        -d "text=$1" >/dev/null || true
}

cleanup() {
    local code=$?
    if [[ $code -ne 0 ]]; then
        log "脚本异常退出，退出码 $code"
    fi
    rm -f "$LOCK_FILE"
}
trap cleanup EXIT

# ---------- 主流程 ----------
exec 9>"$LOCK_FILE"
if ! flock -n 9; then
    log "上一次备份还在运行，本次跳过"
    exit 0
fi

DATE=$(date '+%F_%H%M')
ARCHIVE="${BACKUP_ROOT}/backup-${DATE}.tar.gz"

mkdir -p "$BACKUP_ROOT"

log "开始备份"

tar -czf "$ARCHIVE" \
    --exclude='*/cache/*' \
    --exclude='*/node_modules/*' \
    --exclude='*.log' \
    "${SOURCE_DIRS[@]}" 2>>"$LOG_FILE" || fail "tar 打包失败"

# 校验
[[ -s "$ARCHIVE" ]] || fail "备份文件为空"

SIZE=$(stat -c %s "$ARCHIVE")
if [[ $SIZE -lt 1048576 ]]; then
    fail "备份文件异常小: ${SIZE} 字节"
fi

# 完整性校验
gzip -t "$ARCHIVE" || fail "压缩包损坏"

log "备份完成，大小 $(numfmt --to=iec "$SIZE")"

# 清理过期
find "$BACKUP_ROOT" -name 'backup-*.tar.gz' -type f -mtime +"$KEEP_DAYS" -delete
log "已清理 ${KEEP_DAYS} 天前的备份"

# 异地同步
if command -v rclone >/dev/null 2>&1; then
    rclone sync "$BACKUP_ROOT" "$REMOTE" --max-age 24h 2>>"$LOG_FILE" \
        || log "WARN: 异地同步失败"
    log "异地同步完成"
fi

notify "备份完成: $(basename "$ARCHIVE")"

逐段解释

set -Eeuo pipefail 这四个选项，每一个都有用。

-e 让任何命令返回非零就退出。-u 让引用未定义变量时报错。-o pipefail 让管道里任何一个环节失败都能被捕获。-E 让 ERR trap 能被子 shell 继承。

IFS=$'\n\t' 是改字段分隔符。默认是空格、制表、换行。如果某个文件名里有空格，不加这个的话，for f in $files 会把一个文件名拆成两个。改成只认换行和制表，能避免大部分问题。

不过要注意，改 IFS 之后，"$@" 这种引用是安全的，但 $* 的行为会变。所以尽量用 "$@"。

锁

1
2

exec 9>"$LOCK_FILE"
flock -n 9 || exit 0

exec 9> 是把文件描述符 9 指向这个锁文件。flock -n 尝试加锁，-n 是非阻塞，拿不到锁就立刻返回失败。

这个锁的作用是防止两个实例同时跑。如果没有它，cron 设的间隔比备份耗时短的时候，就会出现多个进程同时写同一个 tar 文件，结果一定是坏的。

为什么用文件描述符而不是 flock -n /path/to/lock command 这种写法？因为后者在命令结束之后会自动释放，但如果脚本中途被 kill -9，锁文件会留下，虽然不影响下次加锁（flock 的锁是内核管理的，进程死了自动释放），但用 fd 的方式更清晰，而且 trap 里能统一清理。

校验

`1`	`[[ -s "$ARCHIVE" ]] \|\| fail "备份文件为空"`

-s 是文件存在且大小大于零。

`1`	`gzip -t "$ARCHIVE"`

这个会完整解压一遍检查 CRC，不输出内容。对于几百兆的文件，大概花几秒。值得。

`1`	`[[ $SIZE -lt 1048576 ]]`

这个阈值是拍脑袋定的。我的站点正常备份在几百兆，如果小于一兆，说明肯定有问题。

这个值要根据你的实际情况调。太小了起不到检查作用，太大了会误报。

清理

`1`	`find "$BACKUP_ROOT" -name 'backup-*.tar.gz' -type f -mtime +14 -delete`

-mtime +14 是修改时间超过十四天。注意 +14 是大于十四天，也就是第十五天开始删。

有个细节，-mtime 是按二十四小时算的，不是按自然日。所以如果备份是每天同一时间跑，这个判断是准的。

异地同步

`1`	`rclone sync "$BACKUP_ROOT" "$REMOTE" --max-age 24h`

sync 会让目标端和源端一致，包括删除。这一点要注意，如果本地文件被误删了，云上的也会被删。

想要更安全，用 copy 而不是 sync：

`1`	`rclone copy "$BACKUP_ROOT" "$REMOTE" --max-age 24h`

copy 只添加和更新，不删除。这样云上会越攒越多，需要另外配生命周期规则来清理。

我选了 sync，因为云上的生命周期规则更难调。但我加了对象存储的版本控制，就算被同步删除，历史版本还在。

--max-age 24h 只同步一天内的新文件，避免每次都全量比对。文件多了之后，这个参数能省很多时间。

告警

我用的是 Telegram Bot，因为它免费、稳定、API 简单。

`1`	`notify "备份完成: $(basename "$ARCHIVE")"`

成功也发一条。有人觉得成功不用通知，但我觉得正好相反。如果只有失败才通知，你就不知道"没收到通知"到底是成功了还是脚本根本没跑。

每天收到一条"备份完成"，心里踏实。

|| true 是让通知失败不影响主流程。告警本身挂了不应该导致备份失败。

cron 的写法

sudo tee /etc/cron.d/backup <<'EOF'
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

15 3 * * * root /usr/local/bin/backup.sh >> /var/log/backup-cron.log 2>&1
EOF

cron.d 的格式比 crontab -e 多一个用户字段，就是那个 root。少了这个字段，cron 不会执行，也不报错。

SHELL 和 PATH 这两行最好显式写。cron 的环境变量非常精简，很多命令找不到。

脚本里的 >> /var/log/backup-cron.log 是双保险。脚本自己会写 LOG_FILE，但万一脚本在写日志之前就挂了，cron 的 stderr 能兜住。

日志轮转

/var/log/backup.log 会一直涨，得配 logrotate。

sudo tee /etc/logrotate.d/backup <<'EOF'
/var/log/backup.log {
    weekly
    rotate 8
    compress
    missingok
    notifempty
    copytruncate
}
EOF

copytruncate 是复制一份然后清空原文件，而不是改名。因为脚本一直在往这个文件写，改名之后文件描述符还指向旧的，会写到已经轮转的文件里。

几个我踩过的坑

有一次备份跑到一半，机器重启了，tar 文件是截断的。但脚本没有检查，第二天 cron 又跑了一次，生成了新的。旧的那个截断文件一直躺在目录里，直到过期被删。

后来我加了 gzip -t 检查，但那只检查新的那个。旧文件坏了还是不知道。

再后来我加了个每周一次的巡检，遍历所有备份文件，跑 gzip -t，有坏的就告警。

还有一次，rclone 同步的时候网络断了，同步失败，但脚本只记了 WARN 没退出。第二天我看云上的备份，少了三天。

现在我把异地同步的失败也升级成了告警，至少能知道。

定期演练

这一点最重要，也最容易被忽略。

我现在的习惯是每季度做一次恢复演练。随便挑一个备份文件，解压到临时目录，对比一下文件数量和关键文件的大小。

mkdir -p /tmp/restore-test
tar -xzf /backup/backup-2026-03-04_031500.tar.gz -C /tmp/restore-test
find /tmp/restore-test -type f | wc -l
diff -r /tmp/restore-test/srv/www /srv/www | head

如果 diff 没有输出，说明恢复出来的内容和现在的完全一致。

这一步花十分钟，但它能证明你的备份是真的有用的。

现在

这套脚本跑了快一年，中间成功恢复过两次。

一次是我误删了 nginx 的配置，一次是数据库写坏了一个表。

两次都在半小时内解决。那种"还好有备份"的感觉，是之前九十天空备份给不了我的。

备份这件事，最难的从来不是写脚本，是坚持验证。脚本写完就扔在那儿，跟没写差不多。

数据库备份这件事，我从手动导出做到全自动

Thu, 20 Mar 2025 03:45:00 +0800

我一直觉得备份是件很枯燥的事。

直到有一次，我在服务器上执行了一条 DELETE FROM comments WHERE id > 100，本来想删测试数据，结果忘了自己不在测试库。

那条语句跑完，生产库少了两千多条评论。

我坐在那儿愣了大概十秒钟，然后想起来，昨天晚上的备份还在。

从那次之后，我对备份的态度完全变了。

备份到底要解决什么问题

先说清楚，备份不是"把数据复制一份"这么简单。

它要能应对几种不同的场景。

误删数据，需要恢复到删除前的某个时间点。

磁盘损坏，需要换台机器把服务重新拉起来。

程序 bug 写坏了数据，需要回滚到某个版本。

被勒索软件加密，需要有离线副本。

这几种场景对备份的要求不一样。误删需要时间点密集，磁盘损坏需要副本在别的机器上，勒索需要副本不可写。

所以一个靠谱的方案，至少要有三个特征。定期自动跑，副本存在别的地方，而且真的能恢复。

最后一条最容易被忽略。很多人备份跑了半年，真要恢复的时候才发现文件是空的。

最基础的 mysqldump

小站用这个就够了。

mysqldump \
  --single-transaction \
  --quick \
  --routines \
  --triggers \
  --events \
  --default-character-set=utf8mb4 \
  -u root -p \
  myapp > /backup/myapp-$(date +%F).sql

几个参数都值得说一下。

--single-transaction 是关键。它在 InnoDB 上开一个一致性快照，导出过程中不会锁表，业务可以继续写。导出来的数据是开始那一刻的状态，不会出现前后不一致。

注意这个参数只对 InnoDB 有效。如果你的表还有 MyISAM，那就得用 --lock-tables，会锁表，业务会卡。

--quick 让 mysqldump 一行一行往客户端发，而不是全部读进内存。大表不加这个，很容易把内存撑爆。

--routines --triggers --events 这三个，默认是不导出的。不加上，恢复之后存储过程、触发器、定时任务全都没了。我第一次恢复的时候就踩了这个坑，恢复完发现定时清理任务不跑了。

--default-character-set=utf8mb4 防止中文乱码。如果源库是 utf8mb4，导出的时候不指定，有时候会被转成 latin1。

加压缩和加密

纯 sql 文件很大，压缩一下能小到十分之一：

`1`	`mysqldump ... \| gzip > /backup/myapp-$(date +%F).sql.gz`

如果数据里有敏感信息，还得加密：

`1`	`mysqldump ... \| gzip \| openssl enc -aes-256-cbc -pbkdf2 -salt -pass file:/etc/backup.key > /backup/myapp-$(date +%F).sql.gz.enc`

-pbkdf2 是让 openssl 用更安全的密钥派生方式，不加的话会有警告。

-pass file: 从文件读密码，比写在命令行里安全，因为命令行参数在 ps 里能看到。

/etc/backup.key 权限设成 600，只有 root 能读。

恢复的时候：

`1`	`openssl enc -d -aes-256-cbc -pbkdf2 -pass file:/etc/backup.key -in backup.sql.gz.enc \| gunzip \| mysql -u root -p myapp`

写成脚本

手动跑总会忘，得自动化。

#!/bin/bash
set -euo pipefail

BACKUP_DIR=/backup/mysql
KEEP_DAYS=14
DATE=$(date +%F_%H%M)
DB=myapp

mkdir -p "$BACKUP_DIR"

mysqldump \
  --single-transaction --quick --routines --triggers --events \
  --default-character-set=utf8mb4 \
  -u root -p"$(cat /etc/mysql/backup.pass)" \
  "$DB" | gzip > "$BACKUP_DIR/${DB}-${DATE}.sql.gz"

# 校验文件不是空的
SIZE=$(stat -c %s "$BACKUP_DIR/${DB}-${DATE}.sql.gz")
if [ "$SIZE" -lt 1024 ]; then
  echo "备份文件异常小：$SIZE 字节" >&2
  exit 1
fi

# 清理过期
find "$BACKUP_DIR" -name "${DB}-*.sql.gz" -mtime +$KEEP_DAYS -delete

echo "备份完成：${DB}-${DATE}.sql.gz ($SIZE 字节)"

set -euo pipefail 这三件套一定要加。-e 让任何命令失败就退出，-u 让未定义变量报错，-o pipefail 让管道里任何一个环节失败都能被捕获。

没有 pipefail 的时候，mysqldump | gzip 如果 mysqldump 失败了，整个管道还是返回成功，因为 gzip 成功了。这是很隐蔽的坑，我吃过一次，备份文件是空的，脚本还报成功。

那个 SIZE 校验也是必须的。空文件、截断的文件，靠退出码是发现不了的。

用 cron 跑

sudo tee /etc/cron.d/mysql-backup <<'EOF'
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

30 3 * * * root /usr/local/bin/mysql-backup.sh >> /var/log/mysql-backup.log 2>&1
EOF

每天凌晨三点半跑。这个时间业务量最低。

cron.d 的格式比 crontab -e 多一个用户字段，就是 root 那个位置。写错了会不执行，而且没有任何提示。

增量备份

全量备份对数据量小的站够用，但如果库有几个 G，每天全量就不太现实了。

增量有两种做法。

一种是 binlog。MySQL 的 binlog 记录了所有数据变更，配上定期全量，可以把数据恢复到任意时间点。

先确认 binlog 开着：

`1`	`SHOW VARIABLES LIKE 'log_bin';`

如果是 ON，那 binlog 文件在 datadir 下面，名字形如 mysql-bin.000001。

备份 binlog：

1
2

mysqlbinlog --read-from-remote-server --host=127.0.0.1 --user=repl --password=xxx \
  --raw --stop-never mysql-bin.000001

这个会持续拉取新的 binlog。实际用的时候一般配合 --result-file 和定期切换。

另一种是 --incremental 配合 xtrabackup。Percona 的工具，支持热备和增量，适合大库。不过它需要单独装，配置也复杂一些。

我这个小站没到那个量级，用的还是每天全量。库里不到一百兆，压缩完十几兆，存三十天也就四百多兆。

存到别的地方

本地备份只能防误删，防不了磁盘坏或者机器没了。

所以至少要有两份，一份在本机，一份在别处。

我用的是 rclone 同步到对象存储：

`1`	`rclone sync /backup/mysql remote:mybackup/mysql --max-age 24h`

--max-age 24h 只同步一天内的新文件，不用每次全传。

对象存储那边开了版本控制，就算本地文件被勒索软件加密了，云上的历史版本还在。

还有一个细节，云上的凭据要单独放，不要和备份放在同一台机器上。不然机器被攻破，凭据一起泄露，备份也保不住。

真正的考验是恢复

这一步我建议每个人都做一次。

找个测试环境，把备份文件恢复进去，看看数据对不对。

`1`	`gunzip -c myapp-2025-03-19.sql.gz \| mysql -u root -p testdb`

然后：

1
2

SELECT COUNT(*) FROM comments;
SELECT MAX(created_at) FROM comments;

数字对得上，时间对得上，才算备份有效。

我第一次做这个演练的时候，发现恢复出来的库少了三张表。原因是那三张表是 MyISAM，--single-transaction 对它们无效，mysqldump 直接跳过了。后来改成全部 InnoDB 才好。

这种问题，只有真的恢复一次才能发现。

恢复的流程也要写下来

出事的时候人是慌的，容易漏步骤。

我把恢复流程写成了一个文档，放在 /srv/docs/restore.md，内容包括：

先停掉应用，防止有新的写入。

备份当前的数据库（哪怕是坏的，先留一份）。

创建新的库，导入备份。

检查表数量、行数、最新的记录时间。

确认无误之后，改应用的连接配置，启动。

最后记录这次事故的时间线和原因。

有这个文档，真出事的时候照着做就行，不用临场想。

现在的情况

这套东西跑了快一年，中间用上了两次。一次是我自己误删，一次是磁盘满了导致写入失败。

两次都在半小时内恢复，业务中断时间不到一小时。

备份这件事，平时感觉不到它的价值。它唯一的价值就在出事的那一刻，而那一刻你没有任何补救的机会，只能靠之前准备好的东西。

所以我现在对它的态度是，不追求多先进，但一定要简单、可靠、验证过。