みなさまインスタンスのバックアップはしていますか？
私もそろそろ真面目に考えねばと思い始めています。
個人インスタンスで volumes をディスクにそのまま乗せていれば、 mastodon を止めて mastodon/ を丸ごと tar なり何なりして保存してしまえば良さそうではあります。
しかし、中〜大規模インスタンスの管理者様は、無停止でやろうとか、大きなファイルをどうするとか、特別な対策やノウハウをお持ちだったりしますか？
是非ともバックアップのあれこれを自慢・啓蒙しましょう。
そういえばこれは私の GNU Social のインスタンスでやっていることですが、ディレクトリをバックアップするとき
tar czf - "backup_dir" | split -b 1G --suffix-length 3 --numeric-suffix - "backup/backup_20990101-2359.tgz."
などのようにすると、 backup_dir が固められて 1GiB 単位で分割されたのち backup/backup_20990101-2359.tgz.000 のように連番で出てきます。
こうして保存の段階で予め分割してしまえば、あとはサーバが稼働状態でも各ファイルについて cloud-dl などを呼んでやってバックアップを owncloud 等に飛ばすこともできます。
cloud-dl:
素朴バックアップ勢の参考にどうぞ。
私はお一人様インスタンスということもあって特別何もしていないです。
メディアはS3に置いてあるので、DBの中身と.env.productionファイルさえ確保できれば大丈夫かなあと構えています。
定期的にバックアップした方がいいよなーということで自動化も検討しているのですがどうしたものかという感じです。
僕のぼっちインスタンスも特別何もしていないです。
メディアはS3を信用してバックアップなし、コード、環境変数として保持している設定、Postgresはプラットフォームにおまかせです。（裏でS3とPostgresのWALでのレプリケーションが活躍してます。）Redisは安いプランなので止まると内容がないよー、ということになってしまいますが、まあ。
mastodon:media:remove_remote＆redis-cli bgsaver＆pg_dumpallを掛けて、
それらとpublic/system の中身をrsyncでNASにコピー、という作業を
毎日利用者の少ない早朝に行っています。
4月から運営してる総トゥート数46万というインスタンスで、
一回20分程度、40GBほどになってます。
※osaponさんの指摘をいただき、処理修正しましたので記事記載も併せて修正しやした！
我が家では、勉強の意味も兼ねて以下のようにしてます。
(aboutにも書いてますが、毎日5:00-6:00に実行してます。およそ実際の処理時間は20分程度で終わってます)
我が家の自宅側NFSサーバは集合NASと化しており、他にブログのデータやメールボックスのデータなど、様々なサーバの共有ストレージとして動いてます。それらも含めたデータを災害対策の一環として全部転送しています。
この時、APサーバ/DBサーバ側のサービスは全止めしてますが、Redisサーバはそのまま生かしてます。
11/20時点まではDBサーバのサービスも生かしてたんですが、osaponさんの指摘より、タイミングによっては自動vaccum処理が走ってるのをころっと忘れてました。今はDB停止処理も突っ込んでます。
何かしらの設備障害が発生した場合は、本番設備の暫定復旧をかけて、ReverseSyncをして復旧する感じになります。
(これは災対拠点側のIPアドレスが、事情により固定ではない&頻繁に変わることが原因です)
実際運用していて何度か復旧作業を実施する羽目になったことが何度かあるのですが、その際わかったことは以下の通りでした。
本当は論理バックアップを取得するのが望ましいんだろうなーと思ってますので、他鯖缶各位の方式が望ましいんだろうなとは思ってます。サービス停止を伴わせてファイルを単純取得してる分、方式としては劣るかなって感じです。ただ、実は過去にDB移行を論理バックアップを使用して挑み、大失敗した経験があるため、なかなかそっち側に思考が傾かないのが現状です。(そもそも仕事であんましDBに関する仕事はやらない)
この方法ですが、DBを動かしたままNFS経由でrsyncでコピーしているのでしょうか？
DB書き込み中にコピーされると、管理用のデータと実データで不整合が出たりしないでしょうか？
使う人が少ない時間帯でも、PostgreSQLのバキュームが走っている可能性があります。
pg_dumpの保存先がNFSとかになっているなら大丈夫だとは思うのですが・・・。
意外とどうにかなってますね。
2回リカバリー実績がある(1回はストレージ破損、1回は論理破損)んですが、いずれも復旧はしてます。
というか、仰るように停止処理を入れるべきであるし、Hinemosでジョブ化してるんでそれ自体そんなに難しくないんですが・単にサボってるだけですねぇ（笑）
実質お一人様インスタンスになってるからこそ出来る芸当ですかね。
というわけで、実際にDB停止起動処理をぶっこみました。
vacuum処理がpg_heroによって自動で走ってることを失念してました・・・
現在テスト中っす。
んで、無事動いたから元のスケジュールで回してます。
私の管理しているインスタンスも、おひとりさまインスタンスということもあり、サーバー自体の再起動時などにDBのバックアップを実施することはありますが、定期的なバックアップなどは設定していないですね…
一応、不定期にやっているものの内容としては
いまさらですがコメントします。