LXD サーバをバックアップする

何をバックアップするか

LXD サーバのバックアップを計画する際は、 LXD に保管/管理されている 全ての異なるオブジェクトについて考慮してください。

  • インスタンス (データベースのレコードとファイルシステム)
  • イメージ (データベースのレコード、イメージファイル、そしてファイルシステム)
  • ネットワーク (データベースのレコードと状態ファイル)
  • プロファイル (データベースのレコード)
  • ストレージボリューム (データベースのレコードとファイルシステム)

データベースだけをバックアップあるいはインスタンスだけを バックアップしても完全に機能するバックアップにはなりません。

ディザスターリカバリのシナリオによっては、上記のようなバックアップも 妥当かもしれませんが、素早くオンラインに復帰することが目標なら、 使用している LXD の全ての異なるピースを考慮してください。

フルバックアップ

フルバックアップは /var/lib/lxd あるいは snap ユーザーの場合は /var/snap/lxd/common/lxd の全体を含みます。

LXD が外部ストレージを使用している場合はそれらも適切にバックアップする 必要があります。これは LVM ボリュームグループや ZFS プールなど LXD に 直接含まれていないあらゆる外部のリソースです。

リストアにはリストア先のサーバ上の LXD の停止、 LXD ディレクトリの削除、 そしてバックアップと必要な外部リソースのリストアを含みます。

snap パッケージを使っておらず、かつシステムに /etc/subuid と /etc/subgid ファイルがある場合、 lxdroot ユーザーの両方についてこれらのファイル あるいは少なくともこれらのファイル内のエントリーを復元することも良い考えです (コンテナーのファイルシステムの不要なシフトを防ぎます)。

その後再び LXD を起動し、全てが正常に動作するか確認してください。

LXD サーバのセカンダリバックアップ

LXD は 2 つのホスト間でインスタンスとストレージボリュームのコピーと移動を サポートしています。

ですので予備のサーバがあれば、インスタンスとストレージボリュームを時々 そのセカンダリサーバにコピーしておき、オフラインの予備あるいは単なる ストレージサーバとして稼働させることが可能です。そして必要ならばそこから インスタンスをコピーして戻すことができます。

インスタンスのバックアップ

lxc export コマンドがインスタンスをバックアップの tarball にエクスポートする のに使えます。これらの tarball はデフォルトで全てのスナップショットを含みますが、 同じストレージプールバックエンドを使っている LXD サーバにリストアすることが わかっていれば「最適化」された tarball を取得することもできます。

サーバー上にインストールされたどんな圧縮ツールでも --compression を指定することで利用可能です。 LXD 側でのバリデーションはなく、 LXD から実行可能で -c オプションで標準出力への出力をサポートしているコマンドであれば動作します。

これらの tarball はあなたが望むどんなファイルシステム上にどのようにでも 保存することができ、 lxc import コマンドを使って LXD にインポートして 戻すことができます。

ディザスタリカバリ

LXD は lxd recover コマンドを提供しています(通常の lxc コマンドではなく lxd コマンドであることに注意)。 これはインタラクティブな CLI ツールでデータベース内に存在する全てのストレージプールをスキャンしリカバリー可能な焼失したボリュームを探します。 また(ディスク上には存在するがデータベース内には存在しない)任意の未知のストレージプールの詳細をユーザーが指定してそれらに対してもスキャンを試みることもできます。

指定されたインスタンスを復元するのに必要な全ての(インスタンス設定、アタッチしたデバイス、ストレージボリューム、プール設定も含めた)情報を含む各インスタンスのストレージボリューム内の backup.yaml ファイルを LXD は保管しているため、それをインスタンス、ストレージボリューム、ストレージプールのデータベースレコードをリビルドするのに使用できます。

lxd recover ツールはストレージプールを(まだマウントされていなければ)マウントし、 LXD に関係すると思われる未知のボリュームをスキャンしようと試みます。 各インスタンスボリュームについては LXD はマウントして backup.yaml ファイルにアクセスしようと試みます。 その後 backup.yaml ファイルの内容と(対応するスナップショットなど)ディスク上に実際に存在するものとを比較してある程度の整合性チェックを行い、問題なければデータベースのレコードを再生成します。

ストレージプールのデータベースレコードも作成が必要な場合、ディスカバリーフェーズにユーザーが入力した情報よりも、インスタンスの backup.yaml ファイルを設定のベースとして優先して使用します。 ただし、それが無い場合はユーザーが入力した情報をもとにプールのデータベースレコードを復元するようにフォールバックします。