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

何をバックアップするか#

LXD サーバーのバックアップを計画する際は、 LXD に保管／管理されている全ての異なるエンティティについて考慮してください。

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

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

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

フルバックアップ#

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

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

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

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

その後再び 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 ファイルを設定のベースとして優先して使用します。ただし、それが無い場合はユーザーが入力した情報をもとにプールのデータベースレコードを復元するようにフォールバックします。