データベースボリュームがいっぱいになった後にJellyfinを修復する方法

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How to Repair Jellyfin After Its Database Volume Fills Up - Zima Store Online

Jellyfinのデータベースボリュームがいっぱいになった場合は、新たな書き込みを停止し、データベースとWALファイルを保持して安全に空き容量を確保し、通常のジョブを再開する前にデータベースを検証してください。

ボリュームの空き容量がゼロになった後、Jellyfinが起動しない、SQLiteエラーが表示される、またはユーザーが欠落した状態で開くことはありませんか？データベースファイルをすぐに削除したり、クリーンアップタスクを実行したりしないでください。まず、ボリューム、空きバイト数、データベースのファイル名、コンテナの状態、最後に正常だったバックアップを記録します。

障害を大量書き込みに発展させない

Jellyfinと、同じボリュームに書き込むインポーター、スキャナー、サイドカーを停止します。inodeを含め、どのマウントがいっぱいなのかを確認し、メインデータベースと、関連する`-wal`または`-shm`ファイルを保持します。ディスクがいっぱいになると、設定ファイルが空または部分的に書き込まれた状態になることがあります。バージョン固有のインシデントから、空き容量を確保するだけでは起動が復旧しない場合があることが分かります（ボリューム完全消費からの復旧事例）。

永続状態をコピーした後に限り、不要なログ、完了済みのトランスコードファイル、または再構築可能であることが確認されたキャッシュから空き容量を確保します。最初の手順としてデータベースを削除することは絶対に避けてください。

クリーンアップ前に、データベースのサイズ、WALファイル、ログ、キャッシュ、残りの空き容量を記録します。これにより、ボリュームがデータベースの肥大化、トランスコード出力、ログ、または別のコンテナによっていっぱいになったのかを特定できます。

修復を試みる前にデータベースの整合性を確認する

Jellyfinを停止したまま、データベースのコピーに対して作業します。環境で利用できるSQLiteツールを使って整合性チェックを実行し、ログで「disk full」、「malformed image」、「unable-to-open」などのエラーを確認します。チェックに合格した場合は、空き容量を確保してから一度だけ再起動し、ユーザー、ライブラリ、再生を確認します。

データベースが不正な形式になっている場合は、まず最後に正常だったバックアップを復元します。管理された復旧手順では、コピーに対してSQLiteのリカバリーツールを使用することもできますが、これは検証済みバックアップの代替にはならず、稼働中のデータベースに対して実行してはいけません（コピーを使った復旧手順）。

再構築可能なデータだけを削除して空き容量を確保した後、データベースファイルが一緒に存在し、読み取り可能であることを確認します。この確認前に再起動すると、不完全な書き込みが2度目の障害につながる可能性があります。