ホームNASで稼働中のデータベースコンテナを一貫性のある状態でバックアップする方法は何ですか？

ほとんどのホームNASおよびセルフホストサーバーユーザーにとって、最も安全なデフォルトは、データベースが稼働中に作成されたデータベースネイティブの論理バックアップであり、そのダンプとコンテナ設定およびアプリファイルを通常のバックアップで保存することです。ダウンタイムが許容される場合は短時間の停止コンテナコピーを使用し、データベースがフラッシュ、ロック、チェックポイント、またはスナップショット用に準備されている場合にのみ調整されたファイルシステムスナップショットを使用してください。ライブデータベースボリュームの単純コピーは一貫性のあるバックアップ方法ではありません。

「一貫性のある」とはデータベースが受け入れる復元を定義する

一貫性のあるバックアップは単なる完全なフォルダーツリーではありません。復元後、データベースエンジンは起動し、トランザクションを正しく回復し、整合性チェックに合格し、アプリケーションが使用できる時点の状態を提示しなければなりません。Immich、Nextcloud、Paperless-ngx、Home Assistant、または他のセルフホストアプリを実行するホームサーバーでは、データベース、アップロード、設定、シークレットが互いに整合している必要があります。

コンテナの永続性はファイルの保存場所を説明するだけであり、稼働中のデータベースを安全にコピーできるわけではありません。データベースにはアクティブなトランザクション、キャッシュされたページ、書き込み先行ログ、一時ファイル、またはNASバックアップソフトウェアがボリュームを読み取っている間に変化するメタデータが存在する可能性があります。

方法1：ホームNASのデフォルトとしてデータベースネイティブ論理ダンプを使用する

論理ダンプは、データベースエンジンにスキーマとレコードの一貫した表現をエクスポートするよう要求します。家庭用NAS上の控えめなPostgreSQLやMariaDBコンテナでは、これは通常、スケジュール設定、検査、オフサイトコピー、クリーンな置換コンテナへの復元が最も簡単な方法です。最新のDockerバックアップガイドでは、スケジュールされたバックアップコンテナからデータベースネイティブダンプを実行するパターンを示しています。

ダンプをライブデータボリューム外の専用バックアップディレクトリに書き込みます。その後、NASバックアップジョブでダンプ、Composeファイル、環境テンプレート、アプリ設定、アップロードデータを保護します。ダンプファイル名や保護されていないログに本番パスワードを露出させないでください。

方法2：ボリュームをコピーする前にデータベースを一時停止する

停止したコンテナのコピーはシンプルで物理的に完全です。まずアプリケーションの書き込みを停止し、データベースをクリーンに停止し、プロセスが終了したことを確認してから、永続ボリューム全体またはバインドマウントされたデータベースディレクトリをコピーし、その後スタックを再起動します。DockerとMariaDBのガイドでは、物理ボリュームコピーは高速だがバージョン依存で通常はダウンタイムに結びつくと説明しています。

この方法は、数分のメンテナンスが許容され、リストア時に互換性のあるデータベースバージョンを使用する小規模なホームNASに適しています。論理ダンプよりも移植性は低く、ボリュームが大きい場合はダウンタイムが延長される可能性があります。バックアップ時にデータベースのイメージタグとストレージレイアウトを保持し、物理ファイルを互換性のないエンジンバージョンにリストアしないようにしてください。

方法3：データベースと高速スナップショットを連携させる

ZFS、Btrfs、LVM、NASのスナップショットシステムは大きなデータベースボリュームを迅速にキャプチャできますが、スナップショットはデータベースと連携して行う必要があります。MariaDBやMySQLの場合は短いロックまたはフラッシュのウィンドウが必要かもしれません。PostgreSQLの場合は、データベースがサポートするバックアップまたはチェックポイントプロセスが必要です。アプリケーション管理のデータベースでは、スナップショット前のフックが必要かもしれません。

データベーススナップショットの議論では、データベースがフリーズされていないか、スナップショットが原子操作で取得されない限り、ライブのディスクコピーは内部的に一貫性がない可能性があると説明しています。ロックまたは静止期間は短くするべきで、データベースを準備し、スナップショットを作成し、書き込みを解放し、その後スナップショットをコピーします。

この方法は、データベースが頻繁な論理ダンプに対して大きすぎる場合や、より短いリカバリポイント間隔が必要な場合に有効です。基本的なホームサーバーダンプのワークフローよりも、より慎重なスクリプト作成とリストアテストが必要です。

Dockerイメージやコンテナのエクスポートをデータベースバックアップとして扱わないでください

コンテナイメージにはアプリケーションのランタイムが含まれており、必ずしもライブの永続データが含まれているわけではありません。コンテナのエクスポートやコミットは名前付きボリュームを省略することがあり、データベースに一貫したリカバリポイントの作成を要求しません。PostgreSQLコンテナのバックアップに関するアカウントは、DockerのsaveやcommitはPostgreSQL特有のバックアップ手法の代わりにはならないと結論づけています。

ZimaOSやDockerのホームサーバーでは、デプロイ定義とデータ保護計画を分けて管理しましょう：Composeファイルとイメージタグを保存してサービスを再構築できるようにし、データベースはデータベース整合性のある方法で保存して状態を復元可能にします。

アクティブに書き込み中のデータベースボリュームを単純コピーしてはいけません

NASバックアップソフトは異なる時点で異なるデータベースファイルを読み取ることがあります。その結果のアーカイブには、あるトランザクション状態のデータファイル、別の状態のログ、さらに別のメタデータが混在することがあります。オープンソースSQLバックアップ方法の概要では、重要な状態がまだメモリ内にある不整合な瞬間にデータベースがキャプチャされるリスクがあると警告しています。

クラッシュリカバリーは一部の原子性のあるスナップショットを修復できますが、通常の再帰的ファイルコピーは原子性がありません。アプリがダウンタイムを許容しない場合は、論理ダンプ、サポートされた物理バックアップツール、または連携スナップショットを使いましょう。

SQLiteコンテナは通常のファイルではなくデータベースとして扱う

多くのホームサーバーアプリはSQLiteを使います。これはコンパクトで展開が簡単だからです。リスクは管理者が1つの.dbファイルを見て、アプリが書き込み中でもコピーできると誤解することです。WALモードでは、最近コミットされた変更がまだメインファイルの外にある場合があります。実用的なSQLiteリカバリー記事では、ライブデータベースファイルのコピーではなく、オンラインバックアップ機構かクリーンに閉じたコピーを使うことを推奨しています。

アプリに組み込みのバックアップ機能があればそれを使いましょう。なければSQLiteのオンラインバックアップ機能を使うか、アプリをクリーンに停止してからデータベースディレクトリ全体をコピーしてください。メインのデータベースファイルだけをコピーし、ジャーナルやWAL状態を残すのは避けてください。

ダウンタイム、データベースサイズ、復元の移植性で方法を選択

データベースだけでなく、セルフホストアプリ全体をバックアップする

使えるリカバリパッケージには、データベースバックアップ、Docker Composeファイル、イメージバージョン、環境変数または復元可能なシークレットパッケージ、リバースプロキシ設定、アプリ設定、アップロードファイル、暗号化キーが含まれるべきです。SQLダンプだけをバックアップすると、レコードは復元されても、アプリが写真、ドキュメント、サムネイル、証明書、ストレージパスを見つけられなくなる可能性があります。

ホームサーバーのリカバリ計画には、ZimaSpaceのバインドマウントと名前付きボリュームに関するガイドが役立ちます。これは、可視ストレージパスがリカバリに役立つ理由を説明しますが、アプリケーション整合性のあるデータベースバックアップの代わりにはなりません。

新しいコンテナに復元して方法を証明する

新しいプロジェクト名、異なるホストポート、一時的なデータディレクトリで分離されたテストスタックを作成します。ダンプまたはスナップショットを復元し、データベースを起動し、整合性または一貫性チェックを実行し、テスト用のアプリケーションコピーに接続します。ユーザー、レコード、添付ファイル、最近のトランザクションが存在することを確認してください。

リカバリポイントとリカバリ時間の両方を測定してください。論理ダンプが整合性を保っていても復元に時間がかかる場合は、ポータブルなリカバリ層として保持し、より高速な調整済みスナップショットを追加します。停止したボリュームコピーが迅速に復元できても同じデータベースバージョンにしか戻せない場合は、移行のフォールバックとして論理ダンプを保持してください。

よくある質問

ボリュームをコピーする前にデータベースコンテナをポーズするだけで十分ですか？

一般的にはそうではありません。ポーズはプロセスを停止しますが、データベースがポータブルバックアップに適した正しい状態をフラッシュしたことを証明しません。データベースネイティブのダンプ、クリーンシャットダウン、または文書化された静止状態とスナップショットの手順を使用してください。

PostgreSQLやMariaDBにNASのスナップショットだけで十分ですか？

スナップショットが原子性を持ち、データベースのサポートする整合性プロセスと調整されている場合のみです。調整されていないスナップショットは単なるクラッシュ整合性であり、非原子的なファイルコピーはさらに悪い場合があります。

SQLiteベースのホームサーバーアプリで何をバックアップすべきですか？

可能な場合はアプリのエクスポートまたはSQLiteのオンラインバックアップを使用してください。また、アプリの設定、Composeファイル、シークレット、添付ファイル、データベースを含むディレクトリを保存し、メインファイルだけを前提としないでください。 .db ファイルはアプリケーション全体です。

最終推奨事項

ホームNAS上のほとんどのPostgreSQLおよびMariaDBコンテナには、デフォルトでスケジュールされた論理ダンプを使用します。短時間のダウンタイムが許容される場合は、クリーンに停止したボリュームのコピーを使用し、データベースが大きいかリカバリポイントのウィンドウが厳しい場合は、調整されたスナップショットまたはデータベースネイティブの物理ツールを使用します。どの方法を選んでも、信頼する前に新しいコンテナに復元してください。