Zenn
💾

Misskeyの自鯖を破壊してDBロールバックして復旧することになった話

2023/12/30に公開
Docker
#
hyperv
MicroK8s
#
kubenetes
tech

経緯

前提

  • 構成はWindows11上のHyper-V VM→Ubuntu 22.04→MicroK8s
  • 本Misskeyインスタンスと同一のVM上にMicroK8sのクラスタを用意して、移行しようとした
  • もともとはWindows11上のHyper-V VM→Ubuntu 22.04→docker(compose)で稼働していた。移行作業中は停止

事故当時の状況

  • 行き先がローカルのストレージになるPersistentVolumeを設定し、PostgreSQLクラスタのデータ保存先にした
  • そこに対してkubectlの機能を使ってport-forwardしたうえで、pg_restoreしてDBの復元を実行した
pg_restore -h 127.0.0.1 -U misskey -d misskey -Ft ./db/231230-0726.tar

起きたこと

  • pg_restoreから下記のようなエラーが出た(一部)
pg_restore: while PROCESSING TOC:
pg_restore: from TOC entry 4653; 1259 22037 INDEX IDX_171e64971c780ebd23fae140bb misskey
pg_restore: error: could not execute query: ERROR:  invalid page in block 6273 of relation base/16385/17439
  • VMからの応答がなくなる
  • Hyper-V管理画面からも状態がオフ-重大となり、仮想マシンの構成記憶域に接続できなくなった

  • 同時に、当該VMの仮想HDDが配置されていた物理SSDにもアクセスができなくなった

  • ホストPCの再起動後、当該SSDへのアクセスは復活したが、VMは変わらず起動しないままであった

試したこと

当該VMに接続されていた仮想HDDを別のVMにアタッチし、復元を目指す

当該VMのチェックポイントには、8月17日時点の1つが存在していた

最新のデータが入っていたavhdxをアタッチし、復活を試みる
  • ファイルシステムが破損していたため、fsckでの復活を目指す
    • 移行時に使用したダンプファイルが取り出せたため、こちらを利用したdbリストアを試すも、ファイル自体も破損していたのか失敗した
チェックポイントが取られた時点でのvhdxをアタッチし、復活を試みる(解決)
  • ファイルシステムに問題はなかったため、dbコンテナの起動とダンプをした
  • デプロイ対象VMからscpコマンドを利用してダンプファイルを転送した
  • デプロイ対象VMでdbコンテナを上げ、手動で下記のようにしてリストアし、成功した
\i /path/to/your/dumpfile.sql

対策

定期バックアップ

当然中の当然のこと、いい加減やります、、、
また、ダンプファイルがVMと物理的に同じディスクにあるのもマズいので、rcloneか何かでWasabiに上げるようにする

チェックポイント作成

今回これに救われた
定期的に取るようにする

Kubernetesクラスタはそれ専用にマシン用意する

多分これもある
あれこれ兼用するとdockerコンテナ立ち上げるたびにクラスタ内のpod全滅したり全滅したりします（すでに怪しい

Discussion