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