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

何をバックアップするか

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

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

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

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

フルバックアップ

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

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

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

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

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

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

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

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

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

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

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

ディザスタリカバリ

さらに、 LXD は各インスタンスのストレージボリューム内に backup.yaml ファイルを 保管しています。このファイルはインスタンスの設定やアタッチされたデバイスや ストレージなど、インスタンスを復元するのに必要な全ての情報を含んでいます。

このファイルは lxd import コマンドで処理できます。 lxc import コマンドと 間違えないようにしてください。

ディザスタリカバリ機構を使うためには、インスタンスのストレージを期待される場所、 通常は storage-pools/NAME-OF-POOL/containers/インスタンス名 にマウントしておく 必要があります。

ストレージバックエンドによっては、リストアしたい全てのスナップショットに ついても同様にマウントが必要です (dirbtrfs で必要です)。

backup.yaml に宣言されているリソースに対応するデータベースエントリーがインポート 中に見つかったら、コマンドはインスタンスをリストアすることを拒絶します。これは --force を渡すことでオーバーライドできます。

注意: マウントと snap を扱う際は、 snap stopsnap start で snap のフルリスタートを実行するか nsenter --mount=/run/snapd/ns/lxd.mnt を使って snap 環境内からマウントを実行するかのいずれかを行う必要があります。