Mastodon・Misskeyのデータベースをバックアップする

「MastodonとMisskeyのデータベースは死守しろ」って村上さんが言ってた！ソース：[世界一大きなインスタンスでヤバい障害起こしちゃった話](https://blog.arkjp.net/2021/12/1003io/) ## 使用環境 - Mastodon kmyblueフォーク - さくらのVPS Misskeyで動作確認はしていませんが、同じPostgreSQLを使っているのでいけるはず。 ## バックアップ準備（ディレクトリ作成）バックアップをする前にディレクトリの作成し、ついでにパーミッションも変更しておきます。 ``` $ sudo mkdir /var/backup $ sudo chmod 777 /var/backup ``` ## バックアップを手動で行う場合アップデートやメンテナンスを行う前に、バックアップを残しておきたいときのコマンド。下記コマンドを入力したら`/var/backup/`ディレクトリー内にできてるはず。 ``` $ sudo -u postgres pg_dumpall | gzip -c > /var/backup/mastodon$(date +%Y%m%d%H%M)-backup.gz ``` ### could not change directory to "/root": Permission deniedが出る [サーバーのバックアップを取るメモ | とりのこし](https://blog.10rino.net/%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E3%81%AE%E3%83%90%E3%83%83%E3%82%AF%E3%82%A2%E3%83%83%E3%83%97%E3%82%92%E5%8F%96%E3%82%8B%E3%83%A1%E3%83%A2) 上記の記事を見て、エラーのこと書き忘れたと気づきました。申し訳ない。今私の環境で試したところ、下記の結果になりました。 - root権限：エラー表記あり - sudu権限を渡した一般ユーザーA：エラー表記なし多分`/var/backup`を作ったユーザーに権限があって、そのユーザーでバックアップコマンドを打たないとアクセス権限エラーが出るっぽいですね。ただ、エラーを吐いててもバックアップ自体はできてるのでヨシ！でもいいと思いますけれども（よくない） ### バックアップ時の挙動・バックアップファイル確認について上記のエラー文を吐いても吐かなくてもバックアップファイルができてることがあります。（バックアップしたよというコメントが出ないので、できていることに気づかない）そのため、一度FTPソフトで`/var/backup/`ディレクトリーを確認するか、下記のコマンドを入力してファイルがあるか確認してください。 ``` $ ls -l /var/backup ``` この時にファイルの容量も確認しておくと吉。一件ファイルができてるように見えても、データベースバックアップに作成失敗してて、データ容量がスッカスカになってることがあります。 ### コマンド解説 #### sudo -u postgres ユーザーをpostgresに変更します。 #### pg_dumpall データベースをすべてバックアップします。 #### gzip -c ファイルをgzip形式で保存します。 gzipは`$ sudo apt install gzip` で要インストールなので、注意。 #### /var/backup/calckey$(date +%Y%m%d%H%M)-backup.gz ディレクトリとファイル名です。この形式では`/var/backup/`に`mastodon202307200123-backup.gz`というファイルができます。 `202307200123`は出力した日付になるため、基本的にファイル名が重複しないはず。 ## cronで自動化する `/etc/cron.d`内に`dbackup`ファイルを作成、Nanoで`dbackup`ファイルを開きます。 ``` $ sudo nano /etc/cron.d/dbackup ``` ファイルを開いたら、下記の項目を記入して保存します。 ``` cron SHELL=/bin/sh MAILTO="" 0 2 * * * postgres pg_dumpall | gzip -c > /var/backup/calckey$(date +\%Y\%m\%d\%H\%M)-backup.gz ``` Winの場合は「`Ctrl+S`で保存、`Ctrl+X`でファイルを閉じる」と覚えておけばOK。ファイルを保存したら、パーミッションの変更とcronの再起動を行います。 ``` $ sudo chmod 644 /etc/cron.d/dbackup $ sudo systemctl restart cron ``` ### cron解説 #### SHELL=/bin/sh おまじない的に入れています。（完全に理解してない）多分なくても行けそう。 #### MAILTO="" cronを実行した時、logに`(CRON) info (No MTA installed, discarding output)`が出てたので、エラーをなくすために入れました。多分MTAなどを入れてるなら、エラーはでないはず。 #### 0 2 * * * 日時指定。左から「分/時/日/月/曜日」になっていて、この設定では毎日午前2時（サーバーの時刻）に設定されています。毎日0時に指定したい場合は`0 0 * * *`、毎日17時30なら`30 17 * * *`と設定すればOK。詳しい時刻記入仕様はここを見てください（ぶん投げ） [cronの日時指定を、基礎から学ぶ（分,時,日,月,曜日の指定、◯分ごと、月末起動、など） - YoheiM .NET](https://www.yoheim.net/blog.php?q=20190902) 余談ですが、サーバータイムゾーンが日本じゃない場合があります。私が使っているのはNYだったので、NYの時刻で時間設定をする必要があります。念のため、一度`date`コマンドを使ってサーバーの時刻を確認しとくといいかもしれません。 #### mastodon$(date +\%Y\%m\%d\%H\%M)-backup.gz 出力のファイル名になります。コマンド自体は手動コマンドとほぼ同じで、書き方が若干違います。 %の前に`\`が入ってる＝Cronの仕様上、書き方を変える必要があり、ファイル名を変えたい場合は気を付けましょう。 #### それ以外基本主導のコマンドと同じなので解説略。 ## 指定した日付より前のバックアップを削除する上記のcronのままだと、毎日延々とバックアップファイルを作ってしまい、ストレージを圧迫してしまいます。それを防ぐためにも、指定した日付より前（ここでは14日間）のバックアップファイルを削除するcronを作成しておきます。 `dbackup`ファイルの最終行に下記の項目追加して、cronを再起動すればOK。 ``` 5 2 * * * root find /var/backup -name '*.gz' -mtime +14 -delete ``` ### cron解説 #### 5 2 * * * 時刻。負荷軽減のためにバックアップの時間より数分遅く設定してあります。 #### root root権限で実行します。 #### find /var/backup -name '`*.gz `/var/backup`の`*.gz`が付いているファイルを探します。 #### -mtime +14 -delete 14日より前に作成したファイルを削除します。 ## 関連記事 - [[Mastodon・MisskeyのデータベースをR2にバックアップする]] - [[Mastodon・Misskeyのデータベースをリストアする]] ## 参考サイト（順不同） - [Misskeyのデータベースをバックアップしよう【OCIオブジェクトストレージ編】 | aqz/tamaina](https://hide.ac/articles/E2Ea3cauk) - [GCPで Misskey の PostgresDB とメディアファイルをバックアップする](https://zenn.dev/ganariya/articles/gcp-misskey-backup) - [【linux】蓄積されていくログファイルなどを定期的に削除する例 at softelメモ](https://www.softel.co.jp/blogs/tech/archives/4503) - [crontab の設定で日付の入った名前のファイルをつくろうとしたらエラーでたよ - ウマい話、ちょいくれや。](https://tamac.hatenadiary.org/entry/20101014/1287027443) - [cronの日時指定を、基礎から学ぶ（分,時,日,月,曜日の指定、◯分ごと、月末起動、など） - YoheiM .NET](https://www.yoheim.net/blog.php?q=20190902)