データベースが稼働中でも、ProxmoxでLXCコンテナをバックアップできますか?

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

はい、ProxmoxではLXCコンテナの稼働中にバックアップを作成できます。ただし、それだけで、取得時点のコンテナ内データベースがアプリケーション整合性を保っていることを意味するわけではありません。

データベースのダンプ、静止化、またはバックアップとの別の連携が行われていない限り、稼働中のコンテナスナップショットはクラッシュ整合性のものとして扱ってください。適切な選択は、データベースエンジン、書き込み速度、許容できるダウンタイム、そしてすべてのデータパスが含まれているかどうかによって異なります。

コンテナの取得とデータベースの整合性を区別する

コンテナのバックアップでは、データベースのページ、ジャーナル、インデックスが変更されている最中にファイルシステムが取得されることがあります。復元後、エンジンが先行書き込みログを正常に再生できる場合でも、それは突然停止した状態からの復旧であり、アプリケーションの正常なチェックポイントが取得された証明ではありません。

バインドマウントと外部データセットには、別途注意が必要です。Proxmoxのアーカイブが有効でも、データベースの実データディレクトリ、オブジェクトストア、アップロードファイルがバックアップ対象のルートファイルシステム外に存在することがあります。

ジャーナリングデータベースを使用する重要度の低いサービスであれば、テスト済みのクラッシュリカバリで許容できる場合があります。失われると取り戻せない記録については、データベースネイティブのダンプ、レプリケーションチェックポイント、または短時間のメンテナンスウィンドウを追加してください。

確認可能な兆候から保護レベルを選ぶ

データベースが正常なチェックポイントを報告しているか、ダンプがエラーなく完了するか、Proxmoxのタスクログに意図したすべてのボリュームが含まれているかを確認してください。バックアップ中の書き込み遅延の増大やWALの急速な増加は、復元後により多くのリカバリ処理が必要になることを示します。

コンテナのバックアップ直前にネイティブダンプをスケジュールし、バックアップに含まれるパス内に保存してください。オンラインバックアップAPIに対応しているエンジンでは、稼働中のデータファイルをコピーする代わりにそれらを使用してください。

以下の表で結果を分類し、その分類をジョブのメモに記録して、将来の担当者がアーカイブで保証できる内容を把握できるようにしてください。

確認された状態 判定 次のアクション
ネイティブダンプとLXCアーカイブ アプリケーション対応の復旧経路 重要なデータベースに推奨
スナップショットのみ、復元テストは成功 クラッシュ整合性 文書化したリスクを受け入れる場合のみ採用
外部データパスが含まれていない 不完全 停止してバックアップ範囲を拡大

連携したバックアップジョブを構築する

バックアップ前のステップを実行して、タイムスタンプ付きのデータベースダンプを作成するか、チェックポイントを要求してください。コマンドの終了ステータスと空き容量を確認し、0バイトのダンプが作成された場合は、安心感を与える緑色のバックアップバッジを表示するのではなく、ジョブを失敗させる必要があります。

整合性の手順後にLXCを取得し、その後のバックアップ後チェックでアーカイブIDとダンプのチェックサムを記録します。1つの不良コンテナアーカイブによって、最後の正常な論理コピーまで消去されないよう、データベースネイティブの保持期間は十分に分けて管理してください。

ZimaSpaceのProxmoxバックアップガイドでは、VMとコンテナの復旧計画について説明しています。

アプリケーション整合性を保ったProxmoxバックアップに関する独立したガイダンスでは、稼働中のスナップショットとアプリケーション対応バックアップが異なる保証を提供する理由を説明しています。

負荷をかけた復元でアーカイブを検証する

本番環境と競合しないよう、隔離したCT IDとネットワーク未接続の状態で復元してください。データベースを起動し、リカバリログを確認し、整合性チェックを実行して、バックアップ取得時間帯の直前に書き込まれた既知のレコードをクエリしてください。

本番環境が通常の書き込み負荷にある状態でもテストを繰り返してください。アイドル状態のラボテストでしか復元できないバックアップでは、問題のきっかけとなったリスクの高い条件を検証できていません。

すべてのストレージが対象範囲に含まれ、エンジンが繰り返し正常に復旧できるか、ネイティブダンプが含まれている場合は、稼働中のLXCバックアップを実行して構いません。整合性チェックに失敗した場合、外部マウントが欠落している場合、またはアプリケーションがクラッシュリカバリに耐えられない場合は、停止して、連携した一時停止またはシャットダウンを使用してください。

サポートとヒント

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.