私は https://bikers.social という、バイカー向けのMastodonインスタンスを運営しています 🏍️

インスタンスのバックアップで最も重要なのはPostgresです。DBを失えば終わりです。シークレットもバックアップしています。

以前のMastodonのバックアップ方法は、定期的に pg_dumps を実行して scp で別のマシンに転送するというものでした。そのマシン自体もローカルのNASにバックアップされていたので、これで十分でした。ただ、古いバックアップを半定期的に手動で削除する必要がありましたし、インスタンスの運用期間も長くなってきたので、そろそろもっと良い方法が欲しいところでした。

最近、Cloudflare R2を使うように少し構成を見直しました。

R2

インスタンスのすべてのアセットの保存にR2を使っています。ストレージ料金はS3よりずっと安く、しかも転送量（egress）の料金がかかりません！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か月間保持するようにライフサイクルルールを設定しました。

スクリプト

バックアップスクリプトはとてもシンプルです。実行すると当日の日付のファイルを作成し、指定されたprefixとともに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

prefixが指定されなかった場合は、日次バックアップとして扱われます。

バックアップには 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 によるバックアップとリストアの手順はとてもシンプルです。データベースのサイズが大きくなりすぎたり、ポイントインタイムリカバリが必要になったりしたら、再検討するつもりです。