我是 https://bikers.social 的管理员，这是一个面向摩托车爱好者的 Mastodon 实例 🏍️

Postgres 是实例备份中最重要的部分。一旦丢了数据库，就彻底完了。我的密钥等敏感信息也会一并备份。

我过去的 Mastodon 备份策略是定期执行 pg_dumps，然后用 scp 传到另一台机器上。这套方案完全够用，因为那台机器也会再备份到我的本地 NAS。不过我得时不时手动清理旧备份，现在实例已经运行了一段时间，很需要一套更完善的方案。

最近我对它做了一番改造，改用了 Cloudflare R2。

R2

实例的所有静态资源我都放在 R2 上。它的存储费用比 S3 便宜得多，而且没有出站流量费！用 S3 的话，我总担心会收到意外的带宽账单。

截至 2023 年 5 月，R2 也开始支持生命周期策略了

准备工作

首先，新建一个 R2 存储桶，用来存放备份。请确保不要将其设为公开访问！

接下来要在本地配置 AWS CLI。我创建了一个仅针对该存储桶的 API 令牌，授予对象读写权限，并限制为仅允许我的 Mastodon 服务器 IP 访问。运行 aws configure，然后粘贴你的新账户 ID 和密钥。

AWS CLI 默认会认为你要连接的是 Amazon 的节点。新版 CLI 可以在配置文件中进行配置，但你的软件源里的版本很可能已经过时了。因此对于后续的所有命令，我都设置了

alias aws='aws --endpoint-url https://<account ID>.r2.cloudflarestorage.com'

然后就可以配置生命周期策略了。

进入存储桶设置，找到生命周期策略

我设置了一条生命周期规则：每日备份保留一周，每周备份保留 6 周，每月备份保留 6 个月。

脚本

我的备份脚本非常简单。运行时，它会为当天创建一个文件，然后按指定的前缀上传到 R2。

#! /bin/bash

prefix=${1:-daily}
date=$(date '+%Y-%m-%d')

pg_dump -Fc -Z 0 -U mastodon mastodon_production | xz -T4 > $date.sql.xz

aws --endpoint-url https://<account ID>.r2.cloudflarestorage.com s3 cp ./$date.sql.xz s3://<bucket name>/$prefix/$date.sql.xz

如果没有指定前缀，则默认为 daily 备份。

备份压缩我选用了 xz。它的压缩率是最高的之一，代价是速度很慢。我的 Mastodon 实例配置相当过剩，因为用的是 Hetzner 的机器，而实例本身的流量并不大。

pg_dump -Fc -Z 0 —— 使用自定义格式，但禁用其自带的压缩，因为我们会用 xz 来压缩

xz -T4 会使用 xz 压缩，且最多启用 4 个线程。我试过 -T0，结果直接占满了全部 16 个线程，有点太夸张了。用 4 个线程速度也足够快。

Crontab

手动测试一下：

./backup.sh daily
./backup.sh weekly
./backup.sh monthly

确认所有文件都能正常生成后，我配置了 crontab

0 12 * * * /home/mastodon/backup.sh daily
0 13 * * 0 /home/mastodon/backup.sh weekly
0 14 1 * * /home/mastodon/backup.sh monthly

这里会有一些重复工作，但这不是什么大问题。我把任务都安排在了我白天清醒的时间段，因为我还设置了备份完成后在 Telegram 上提醒我。

后续改进

以后我可能会改用 wal-g。就目前而言，这有点杀鸡用牛刀，而且用 pg_dump 备份和恢复的过程非常简单。如果以后数据库变得太大，或者确实需要时间点恢复功能，我再考虑切换。