私は、バイク乗り向けのMastodonインスタンス https://bikers.social の管理者です 🏍️

インスタンスのバックアップで最も重要なのは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ならconfigで設定できますが、使っているパッケージリポジトリの内容が古い可能性もあります。以降のコマンドでは、次のように設定しました。

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

これで、ライフサイクルポリシーを設定できます。

バケットの設定を開き、ライフサイクルポリシーに移動します。

毎日のバックアップは1週間、毎週のバックアップは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

プレフィックスを指定しなかった場合は、毎日のバックアップとして扱います。

バックアップの圧縮には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を使ったバックアップとリストアの手順はとてもシンプルです。データベースのサイズが大きくなりすぎた場合や、ポイントインタイムリカバリが必要になった場合には、改めて検討します。