备份策略：数据库、附件、配置

关于备份只有一句话是重要的：没验证过能恢复的备份，等于没有备份。

备份什么

附件目录通常最大但变化最慢，所以不用天天全量备。

自动备份脚本

#!/bin/bash
set -e

BACKUP_DIR=/data/backup
SITE_DIR=/www/wwwroot/yourdomain.com
DATE=$(date +%Y%m%d)
KEEP_DAYS=14

mkdir -p "$BACKUP_DIR"

# 数据库
mysqldump -u root -p"$DB_PASS" --single-transaction \
    --default-character-set=utf8mb4 shop_db \
    | gzip > "$BACKUP_DIR/db_$DATE.sql.gz"

# 配置
tar -czf "$BACKUP_DIR/config_$DATE.tar.gz" -C "$SITE_DIR" config

# 清理过期备份
find "$BACKUP_DIR" -name "*.gz" -mtime +$KEEP_DAYS -delete

echo "backup done: $DATE"

加到 crontab，每天凌晨 3 点跑：

0 3 * * * /root/backup.sh >> /var/log/backup.log 2>&1

:::danger 别把备份放在同一台服务器 服务器挂了备份跟着一起没。至少要传一份到别的地方——对象存储、另一台机器、甚至你自己的电脑都行。 :::

同步到对象存储可以用 rclone：

rclone copy /data/backup remote:shop-backup --max-age 24h

恢复演练

这是最容易被跳过、也是最重要的一步。每季度做一次：

1. 找一台测试机（或本地 Docker）
2. 用最新的备份还原出一个完整站点
3. 打开首页、下一个测试单、看后台数据

演练能发现的问题包括：备份文件损坏、漏备了某个目录、数据库版本不兼容、恢复步骤记错了。

:::tip 把恢复步骤写下来 真出事的时候人是慌的，不要指望临时回忆。写一份「恢复手册」，演练时照着走一遍，顺便验证手册是不是准确的。 :::

保留策略

一个够用的方案：

• 每日备份保留 14 天
• 每周备份保留 8 周
• 每月备份保留 12 个月

存储成本很低，但能覆盖「三个月前的数据被误改了」这种场景。