‹ Escapism

Misskeyのデータベースのバックアップと復元のこと

Sep 26, 2020

Misskeyインスタンスのデータベースをダンプファイルから復元するのに手間取ったので備忘メモです。

多分こうやるといいよという結論

Misskeyのdefault.ymlで設定したユーザ名とデータベース名を使います。
(ここではユーザ名=misskey,データベース名=misskeydbとします)

Misskeyのバージョンはv12.47.1、PostgreSQLのバージョンは9.6.19です。

1. バックアップをとる

misskeyユーザでログインします。 pg_dumpコマンドでダンプファイル(名前はmk1とする)を出力します。

pg_dump misskeydb > mk1.sql

2. 復元(リストア)

データベースに中身があるときはデータベースを削除して再作成します。 一旦ログアウトして、Misskeyを止めてから削除権限のあるpostgresユーザ(ロール)でログインします。

sudo -u postgres psql

postgres=# という表示で入力待ちになったらコマンドを入力します(セミコロンを忘れずに)

DROP DATABASE misskeydb;

DROP DATABASE

CREATE DATABASE misskeydb OWNER misskey;

CREATE DATABASE

\q

完了したら、misskeyユーザでログインしてバックアップしたファイルを取り込みます。

psql misskeydb < mk1.sql

処理が走ります。入力待ちになったらMisskeyを再起動して完了です。

どこでハマったのか

というふうにとてもシンプルなのですが、自分がなぜうまくいかなかったかというとpostgresユーザで全て実行していたのが原因のようです。

失敗例

バックアップは次のように実行しました。
(当初Cloud SQLを試してみたかったということもありCloud SQLドキュメントを参考にしたコマンドになっています)

pg_dump -U misskey --no-owner --ncl --format=plain misskeydb > mk1.sql

そして、次のようにリストア実行。

psql -U misskey -d misskeydb -f mk1.sql

するとテーブル作成などの処理はされるのですが、Misskeyを起動させるとInternal Server Errorとなり表示されませんでした。

journalctl -xeでログを見るとPermission deniedやらの文字列から権限の絡みでエラーが出ているのがわかります。

どうやら--no-ownerオプションをつけたこととリストアをpostgresユーザで実行したことにより、データベースの中身の所有者がpostgresに書き換わってしまったため、misskeyユーザがアクセスできないということが起きていたのではないだろうか?と考えています。

他のやり方

自分はスクリプト形式(.sql)でバックアップをとったのですが、この他にアーカイブ形式(.dump)で出力する方法もあるようです。

pg_dumpのオプションに--format=customまたは-Fcを設定するとアーカイブファイルが出力されます。 その場合はリストアはpg_restoreを使います。

Misskeyと同じくPostgreSQLを使ってるMastodonは、公式ドキュメント(Migrating to a new machine)にサーバー移行時の手順が詳細に書かれていて、そちらではpg_restoreを使っています。こちらのほうがリストア時にロールを設定できたりで使いやすいかもしれません。

詳しくはPostgreSQL文書を読めば間違いなさそうです(情報量…) https://www.postgresql.jp/document/9.6/html/app-pgrestore.html

大切なこと

  • バックアップは復元するときを考えてとる
  • 事前に復元まで練習をしておく
  • うまくいかなくなったら何度でもデータベースを作りなおす

良きMisskeyライフを。