我是 https://bikers.social 的管理員，這是一個給機車騎士的 Mastodon 執行個體 🏍️

Postgres 是執行個體備份中最重要的一環。如果資料庫丟了，就真的玩完了。我的 secrets 也會一併備份。

我以前的 Mastodon 備份策略很簡單，就是定期執行 pg_dumps，再用 scp 傳到另一台機器。這樣其實已經很夠用了，因為那台機器也會再備份到我本地的 NAS。不過我得半定期手動清理舊備份，而且站台已經跑了一段時間，有個更好的方案會更好。

最近我稍微重整了一下，改用 Cloudflare R2。

R2

我把執行個體的所有靜態檔案都放在 R2 上。它的儲存費用比 S3 便宜很多，而且沒有輸出費用！用 S3 的話，我會有點擔心收到意料之外的頻寬帳單。

到 2023 年 5 月為止，R2 也開始支援生命週期原則

設定

首先，建立一個新的 R2 儲存桶。這會用來存放備份。請務必確認它沒有對外公開！

接著要在本機設定 aws cli。我建立了一個限定於這個儲存桶的 API token，擁有物件讀寫權限，而且只限我的 Mastodon 伺服器的 IP 位址存取。執行 aws configure，然後貼上你的新帳號 ID 和 secret。

AWS cli 預設會假設你要使用的端點是 Amazon。比較新的 CLI 版本可以在 config 裡設定，但你的套件庫版本很可能已經過時了。接下來的所有指令，我都加上了

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 的備份／還原流程非常簡單。如果資料庫變得太大，或是真的需要時間點還原（point-in-time recovery）功能時，我再來重新考慮。