给我的博客服务器做一次异地备份：七牛云低频存储 + Restic

博客搭起来以后，人很容易有一种错觉：页面能打开，后台能登录，文章能正常发布，这件事就算结束了。

但我后来想了一下，其实不是。

博客本身重新搭一遍并不难。难的是里面那些慢慢积累出来的东西，比如文章、数据库、图片、配置文件、反向代理、Docker Compose、环境变量、定时任务。服务器如果哪天硬盘坏了，或者我手滑删错目录，再或者系统升级的时候出问题，这些东西不一定能靠“重新部署”找回来。

所以我最后还是决定给博客服务器做一个异地备份。

我这里选的是七牛云的低频存储，备份工具用 Restic，频率是一周一次。不是多高级的方案，但对个人博客来说已经够用了。

这篇文章主要是记录我自己的操作过程。以后如果服务器真出问题，我至少还能照着这篇文章把东西恢复回来。

为什么要做异地备份

很多人说备份，第一反应就是在服务器本地复制一份。

比如：

cp -r /www /backup/www

这种当然也算备份，但问题是它还在同一台机器上。

如果只是误删一个文件，本地备份有用。 但如果是硬盘坏了、服务器系统崩了、整台机器访问不了了，本地备份也一起没了。

所以我觉得比较稳的方式应该是：

• 服务器本地跑博客。
• 备份放到另外一个地方。
• 平时不用管它。
• 真出事的时候能拉回来恢复。

这就是我这次选择对象存储的原因。

为什么选七牛云低频存储

七牛云对象存储有不同类型，比如标准存储、低频存储、归档存储。

博客备份这种东西有个特点：平时基本不会下载，只有真的出问题的时候才会拿出来恢复。

所以标准存储有点浪费，归档存储又太麻烦。低频存储刚好在中间，适合这种“不经常访问，但又希望需要的时候能取回来”的数据。

不过低频存储也不是完全没有坑。

它一般会有最短存储时间，比如低频存储通常有 30 天最短保存时间。如果你上传以后很快删除，可能还是要按最低保存时间计费。

还有一个点是，低频存储在恢复下载的时候会有取回费用。也就是说，平时放在那里比较便宜，但你真要下载恢复的时候，会额外产生一点费用。

所以我的策略很简单：

• 一周备份一次。
• 不要天天删。
• 不要只保留一个备份。
• 保留最近几个月的备份就够了。

我最后设置的是保留最近 12 个每周备份，也就是差不多 3 个月。

为什么不用压缩包直接上传

一开始我想过最简单的方法：每周打一个压缩包，然后上传到七牛云。

比如：

tar -czf blog-backup.tar.gz /www /etc/nginx

这个方法确实简单，但我想了一下，后面会有几个麻烦。

第一，每次都是全量备份。 如果网站目录有 30GB，每周就要重新打包、重新上传 30GB。哪怕这一周只改了一篇文章，也得重新传一遍。

第二，版本不好管理。 时间久了以后，会有很多压缩包。哪个是好的，哪个包含数据库，哪个恢复过，自己都容易忘。

第三，加密要自己处理。 博客里面可能有数据库、配置文件、密钥、环境变量，如果只是普通压缩包，直接放到对象存储里，我总觉得不太放心。

第四，恢复体验一般。 真要恢复的时候，还得下载压缩包、解压、确认路径、手动覆盖。

后来我看了一下，七牛 Kodo 支持 S3 兼容接口，而 Restic 可以直接备份到 S3，所以最后就选了 Restic。

Restic 是什么

Restic 是一个备份工具。它不是单纯把文件打包上传，而是会把备份做成一个仓库。

它有几个优点：

• 支持增量备份。
• 支持去重。
• 默认加密。
• 可以查看历史快照。
• 可以恢复到指定时间点。
• 可以对接 S3 兼容对象存储。

简单说就是，第一次备份会上传比较多，后面每次只上传变化的部分。

比如我这周只改了几篇文章，Restic 不会傻傻地把整个博客重新上传一遍。它会识别变化，然后只上传需要上传的内容。

这对每周备份来说比较合适。

先确认自己要备份什么

备份之前，我觉得最重要的一步不是写命令，而是先想清楚：到底要备份哪些东西。

因为很多人一上来就想备份整个服务器根目录：

/

这个看起来最稳，其实不一定。

整个系统里有很多东西是不需要备份的，比如缓存、日志、临时文件、Docker 镜像层。这些东西体积很大，而且恢复的时候也不一定有用。

我真正关心的是这些：

/www
/var/www
/opt
/etc/nginx
/etc/systemd/system

不同人的服务器路径不一样，所以不能直接照抄。

如果你是用 1Panel 部署的博客，可能要重点看：

/opt/1panel
/opt/1panel/apps
/www

如果你是用 Docker Compose 部署的博客，要重点备份：

• docker-compose.yml
• .env
• 挂载出来的数据目录
• 数据库导出文件

如果你的博客有数据库，一定要单独导出数据库。 只备份网站文件，不备份数据库，恢复以后很可能只有程序，没有文章数据。

不建议备份的东西

下面这些目录，我一般不建议直接备份进去：

/var/log
/tmp
/var/tmp
/var/lib/docker/overlay2
node_modules
.cache
logs

原因也简单。

日志会一直增长，恢复博客的时候一般用不上。 临时目录没有必要备份。 node_modules 可以重新安装。 Docker 的 overlay2 很大，而且不适合直接复制恢复。 缓存目录备份了也只是浪费空间。

备份不是越多越好。 该备份的东西必须备份，不该备份的东西不要往里面塞。

安装 Restic

我的服务器是 Ubuntu，所以直接用 apt 安装：

sudo apt update
sudo apt install -y restic

装完以后看一下版本：

restic version

能看到版本号，就说明安装好了。

准备七牛云的信息

接下来需要准备七牛云的几个信息：

• Access Key
• Secret Key
• Bucket 名
• Region ID

Access Key 和 Secret Key 在七牛云后台可以看到。

Bucket 名就是你创建的对象存储空间名称。

Region ID 要看你的空间在哪个区域。比如华东、华南、华北、新加坡这些区域，对应的 Region ID 不一样。

Restic 连接七牛 Kodo 的 S3 地址格式大概是这样：

s3:s3.<Region-ID>.qiniucs.com/<bucket_name>

举个例子，如果你的 Region ID 是：

cn-east-1

Bucket 名是：

my-blog-backup

那仓库地址可以写成：

s3:s3.cn-east-1.qiniucs.com/my-blog-backup/blog-server

最后这个 blog-server 是我自己加的路径，用来区分这个 bucket 里面的不同备份内容。

如果你以后还想备份 NAS、照片、其他服务器，也可以在同一个 bucket 里分不同目录。

创建 Restic 配置文件

我不想每次命令都手动输入 AK、SK、仓库地址和密码，所以把这些东西单独放到一个配置文件里。

先创建目录：

sudo mkdir -p /etc/restic

然后创建配置文件：

sudo nano /etc/restic/blog.env

写入下面内容：

export AWS_ACCESS_KEY_ID="你的七牛AccessKey"
export AWS_SECRET_ACCESS_KEY="你的七牛SecretKey"
export QINIU_REGION="cn-east-1"
export RESTIC_REPOSITORY="s3:s3.cn-east-1.qiniucs.com/你的bucket名/blog-server"
export RESTIC_PASSWORD="你自己设置一个很长的备份密码"

这里需要改成自己的：

• 你的七牛AccessKey
• 你的七牛SecretKey
• cn-east-1
• 你的bucket名
• 你自己设置一个很长的备份密码

RESTIC_PASSWORD 一定要保存好。

这个密码不是七牛云密码，而是 Restic 用来加密备份仓库的密码。以后恢复备份的时候也要用它。

如果这个密码丢了，就算七牛云里的文件还在，也恢复不出来。

保存以后，把配置文件权限收紧一点：

sudo chmod 600 /etc/restic/blog.env

这样普通用户就不能随便读取里面的密钥。

初始化备份仓库

第一次使用 Restic，需要初始化仓库。

执行：

sudo bash -c 'source /etc/restic/blog.env && restic -r "$RESTIC_REPOSITORY" -o s3.region="$QINIU_REGION" init'

如果成功，会看到类似这种提示：

created restic repository ...

如果这里报错，先不要继续往下做。一般要检查这几个地方：

• Access Key 有没有写错。
• Secret Key 有没有写错。
• Bucket 名有没有写错。
• Region ID 有没有写错。
• 服务器能不能访问七牛的 S3 接口。

这一步跑通以后，再继续。

先用小目录测试，不要直接备份正式数据

我建议先不要急着备份整个博客。

先拿一个小目录测试一下，确认上传和恢复都没问题。

创建测试目录：

mkdir -p /tmp/qiniu-test
echo "hello backup" > /tmp/qiniu-test/test.txt

备份这个小目录：

sudo bash -c 'source /etc/restic/blog.env && restic -r "$RESTIC_REPOSITORY" -o s3.region="$QINIU_REGION" backup /tmp/qiniu-test'

查看快照：

sudo bash -c 'source /etc/restic/blog.env && restic -r "$RESTIC_REPOSITORY" -o s3.region="$QINIU_REGION" snapshots'

如果能看到刚刚生成的快照，就说明备份已经传上去了。

接着测试恢复：

sudo mkdir -p /tmp/qiniu-restore
sudo bash -c 'source /etc/restic/blog.env && restic -r "$RESTIC_REPOSITORY" -o s3.region="$QINIU_REGION" restore latest --target /tmp/qiniu-restore'

查看恢复出来的文件：

cat /tmp/qiniu-restore/tmp/qiniu-test/test.txt

如果能看到：

hello backup

说明备份和恢复都没问题。

这一步虽然看起来有点多余，但我觉得很重要。因为备份工具不是只要能上传就行，必须确认能恢复。

写正式备份脚本

测试没问题以后，就可以写正式的备份脚本了。

创建脚本：

sudo nano /usr/local/bin/backup-blog-to-qiniu.sh

写入下面内容：

#!/usr/bin/env bash
set -euo pipefail

source /etc/restic/blog.env

DATE="$(date +%F_%H-%M-%S)"
TMP_DIR="/tmp/blog-backup-$DATE"
LOG_FILE="/var/log/blog-qiniu-backup.log"

mkdir -p "$TMP_DIR"

echo "==== $(date) backup start ====" >> "$LOG_FILE"

# 如果你使用 MySQL / MariaDB，可以把下面这行取消注释，并改成自己的数据库信息
# mysqldump -u root -p'你的数据库密码' --single-transaction --routines --triggers --all-databases > "$TMP_DIR/mysql-all.sql"

# 如果你的 MySQL 在 Docker 容器里，可以用类似下面这种方式
# docker exec mysql容器名 mysqldump -u root -p'你的数据库密码' --single-transaction --routines --triggers --all-databases > "$TMP_DIR/mysql-all.sql"

# 如果你使用 PostgreSQL，可以用下面这种方式
# sudo -u postgres pg_dumpall > "$TMP_DIR/postgres-all.sql"

restic -r "$RESTIC_REPOSITORY" \
  -o s3.region="$QINIU_REGION" \
  backup \
  /www \
  /var/www \
  /opt \
  /etc/nginx \
  /etc/systemd/system \
  "$TMP_DIR" \
  --exclude='**/node_modules' \
  --exclude='**/.cache' \
  --exclude='**/logs' \
  --exclude='**/log' \
  --exclude='**/tmp' \
  --exclude='/var/lib/docker/overlay2' \
  --verbose >> "$LOG_FILE" 2>&1

restic -r "$RESTIC_REPOSITORY" \
  -o s3.region="$QINIU_REGION" \
  forget \
  --keep-weekly 12 \
  --prune >> "$LOG_FILE" 2>&1

restic -r "$RESTIC_REPOSITORY" \
  -o s3.region="$QINIU_REGION" \
  check >> "$LOG_FILE" 2>&1

rm -rf "$TMP_DIR"

echo "==== $(date) backup finished ====" >> "$LOG_FILE"

保存以后，给脚本执行权限：

sudo chmod +x /usr/local/bin/backup-blog-to-qiniu.sh

这里有几个地方要根据自己的服务器改。

如果你没有 /var/www，可以删掉。 如果你没有 /www，也可以删掉。 如果你的博客数据在其他目录，就把对应目录加进去。 如果你的数据库在 Docker 里，要把数据库导出命令改成自己的容器名。

不要照抄路径以后就不管了。 备份脚本最重要的是符合自己的服务器实际情况。

第一次手动运行

脚本写好以后，先手动跑一次：

sudo /usr/local/bin/backup-blog-to-qiniu.sh

第一次会慢一点，因为它需要上传所有需要备份的数据。

执行完以后看日志：

tail -n 100 /var/log/blog-qiniu-backup.log

再看快照：

sudo bash -c 'source /etc/restic/blog.env && restic -r "$RESTIC_REPOSITORY" -o s3.region="$QINIU_REGION" snapshots'

如果能看到新的快照，就说明正式备份成功。

设置每周自动备份

我这里准备每周备份一次，比如每周一凌晨 4 点。

编辑 root 的定时任务：

sudo crontab -e

加入这一行：

0 4 * * 1 /usr/local/bin/backup-blog-to-qiniu.sh

这行的意思是：

每周一凌晨 4 点，执行备份脚本。

保存后查看一下：

sudo crontab -l

如果能看到刚才那行，就说明定时任务已经加好了。

还可以看一下服务器时区：

timedatectl

如果服务器时区不是自己想要的，可以改成韩国时间：

sudo timedatectl set-timezone Asia/Seoul

恢复备份的方法

备份只是第一步，恢复才是关键。

先查看有哪些快照：

sudo bash -c 'source /etc/restic/blog.env && restic -r "$RESTIC_REPOSITORY" -o s3.region="$QINIU_REGION" snapshots'

恢复最新备份到 /restore/blog：

sudo mkdir -p /restore/blog
sudo bash -c 'source /etc/restic/blog.env && restic -r "$RESTIC_REPOSITORY" -o s3.region="$QINIU_REGION" restore latest --target /restore/blog'

如果要恢复指定快照，可以把 latest 换成快照 ID：

sudo bash -c 'source /etc/restic/blog.env && restic -r "$RESTIC_REPOSITORY" -o s3.region="$QINIU_REGION" restore 快照ID --target /restore/blog'

我不建议恢复的时候直接覆盖线上目录。

更稳的做法是先恢复到一个临时目录，比如：

/restore/blog

确认文件完整、数据库 dump 存在、配置没问题以后，再决定怎么覆盖回去。

如果有 MySQL 备份文件，恢复时可以类似这样：

mysql -u root -p < mysql-all.sql

如果 MySQL 在 Docker 容器里，可能是这样：

docker exec -i mysql容器名 mysql -u root -p数据库密码 < mysql-all.sql

具体命令要看自己的数据库环境。

关于费用

低频存储的费用主要不是“上传流量”，而是这几部分：

• 存储容量费用。
• 请求费用。
• 恢复时的数据取回费用。
• 下载到外网时的流出流量费用。

如果只是每周备份一次，平时不恢复，费用一般不会很夸张。

真正容易让费用变高的情况是：

• 把整个 Docker 目录都备份进去。
• 把日志、缓存、临时文件都备份进去。
• 备份里有大量图片、视频、附件。
• 频繁删除低频存储里的对象。
• 频繁从低频存储下载恢复。

所以我才没有选择“一周备份一次，然后只保留一个”。 低频存储不适合频繁删除，保留最近 12 个每周备份会更稳一点。

Restic 的保留命令是：

restic forget --keep-weekly 12 --prune

这代表保留最近 12 个每周备份。

如果以后博客数据越来越大，可以再调整策略，比如保留 8 周、12 周、24 周，具体看自己的数据量和预算。

我最后的备份思路

整理一下，我自己的备份思路大概是这样：

• 博客文件要备份。
• Nginx 配置要备份。
• Docker Compose 和环境变量要备份。
• 数据库要单独导出。
• 缓存、日志、node_modules 不备份。
• 每周自动跑一次。
• 保留最近 12 个每周快照。
• 隔一段时间手动恢复测试一次。

对个人博客来说，这个方案不算复杂，也不会太贵。

最重要的是，服务器真出问题的时候，自己不会完全没办法。

以前我总觉得备份是“以后再说”的事情。 但服务器这种东西，真正出问题的时候，一般不会提前通知你。

所以这次干脆把它补上。

博客可以慢慢写，服务器也可以慢慢折腾，但数据最好不要只放在一个地方。