---
discourse: 11296
---

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