データベースのバックアップとそれを使わないと行けなかった話: Misskey Advent Calendar 2025

この記事は、Misskey Advent Calendar 2025の23日目の記事です

はじめましての方ははじめまして、そうでないかたはこんにちは。Porlamです。

はじめて建てた自鯖(りんごぱい)が経ってから今年で3年が経過しました。(まだMisskey v12だったときです)

今回はりんごぱいで行っているバックアップ方法とそれを使わなければいけなかったことについて話していこうと思います。

バックアップの取り方

りんごぱいでは午前2時と午後2時の1日2回バックアップを取っています。そしてそのバックアップを都度ドイツにあるストレージサーバーに送っています。

バックアップコマンドはこのような形です。(一部改変していますが概ね同じものです)

sudo -u postgres pg_dump -Fc -v -d mk1 > dump.dump 2> log.log
gpg --encrypt --recipient "mail@04.si" dump.dump
rsync -avPh backup/ backup:backup > log.log

1番上のコマンドではデータベースのダンプを出力させています。

-Fcパラメーターでpg_restoreの入力に最適な形式で出力されるようにしています。

こうすることで特定のテーブルのみの復元などがおこないやすくなります。(こうなった経緯は後で書きます)

またデフォルトで圧縮されているので都度圧縮する必要もなくなります。

2個目のコマンドでは出力したダンプファイルを暗号化させています。 最初はopensshでやろうとしましたが、データベースのダンプサイズが大きすぎて失敗するのでgpgをつかっています。

やらかした話

ここから本題です(?)

PostgreSQLを17から18にアップグレードしようとしたときにエラーが起きたので、それに対処しようとして設定をいじっていました。

最初はこんな感じのエラーでした。

このときはまだ普通に動いていました。

old cluster does not use data checksums but the new one does
Failure, exiting

もともと調子が悪そうなPostgreSQLにトドメをさしかけたのがこのあたりからでした。

(少し前なので記憶があいまいですが)、このようなエラーが出始めてデータベースが立ち上がっては落ちるという状況が続いていました。

The database system is in recovery mode.

このあたりからほんとに焦りました。立ち上がっている間はまだ作業ができていましたが、こうなると普通の方法では繋げられなくなっていました。

復旧作業を朝の5時ぐらいまでやっていたので記憶がほとんどありませんが、なんとか一時的に起動できダンプを取れる状況になりました。

ダンプを取れるようになったのでデータベースのvmごと再構築することに決めました。

しかしダンプを取るときに特定のテーブルを取得し始めたときにエラーを吐いて落ちるようになりました。

ERROR: missing chunk number 0 for toast value xxxxxxx in pg_toast_xxxxxxx

今回は特定のテーブルでかつそれほど更新頻度も高くないものだったので一度そのテーブルを飛ばしてあとはバックアップから戻すことにしました。

このときはバックアップをsql形式で取っていたので一度仮のデータベースに全データを流し込んてから、対象のテーブルだけダンプして再度本番用のデータベースに流し込みました。

障害発生から16時間後にようやく復旧できました。

ユーザー、連合の皆さん長時間のダウンタイムすいませんでした。

終わりに

Misskeyはデータベース(とファイル)を死守すればあとはなんとかなるので、バックアップは取ることを強くおすすめします。個人的には他のストレージや暗号化して外部のサーバーに移して置くこともおすすめです。

今回書いた障害もバックアップがなければ復旧が無理な状態になっていたかもしれないと考えると、バックアップを取っていてよかったなとつくづく思います。

追記

新しいVMに移したときにバックアップスクリプトの定期実行がうまく行っていなくて2～3週間の間バックアップが全く取れていなかったことに気がついたときはかなり寒気がしました。

このときに何もなくてほんとによかった