
ホーム サーバーを最初から再設定しようとしていますが、LXD コンテナーをバックアップするための最善の戦略は何だろうと考えています。一方で、Ubuntu 20.04 LTS を実行しており、いくつかのサービスを LXD/LXC コンテナーとして実行するように構成しています。たとえば、次のようになります。
- コンテナ「cloudserv」がseafileを実行中
- nginx と MariaDB を実行するコンテナ「webservice」
これら 2 つのコンテナは、btrfs ファイルシステムの SSD 上に配置されています。データ ストレージにはディスク アレイ (これも BTRFS) を使用しており、そこに別の LXC ストレージ プールを作成し、ストレージ ボリュームを seafile コンテナに接続してすべてのデータを保持しています。レイアウトは次のようになります。
ソリッドステートドライブ
- BTRFSファイルシステム
- ストレージプール「デフォルト」
- コンテナ「cloudserv」
- コンテナ「Webサービス」
- 画像
- ストレージプール「デフォルト」
HDD
- BTRFS ファイルシステム
- ストレージプール「DataPool1」
- カスタム ストレージ ボリューム "seafile-data" --> コンテナー "cloudserv" に接続
- ストレージプール「DataPool1」
BTRFSを使用することで、BTRFSスナップショットと送受信ツールを利用して、コンテナとストレージボリュームをサブボリュームとして簡単に転送できることを期待していました。たとえば、BTRFSボリュームが接続されたRasPiに転送できます。しかし、例えばLXD マニュアルまたはLXDコンテナのバックアップと復元方法インスタンスをバックアップして転送するには、常に tarball を作成する必要があるという印象があります。これは、サブボリューム/スナップショットの送受信や LXC インスタンスとデータの増分バックアップの実行など、BTRFS の魅力的な機能の一部が実際に失われることを意味します。
何か見落としていることはありませんか? BTRFS を使用した LXD/LXC の適切なバックアップ ワークフローについてヒントを教えていただけますか?
答え1
リモートサーバーにLXDをインストールし、両方のサーバーがBtrfsを使用している場合は、最適化されたインスタンス転送このような:
lxc remote add mybtrfsremotebackupserver XXX
lxc snapshot mycontainer snap1
lxc copy mycontainer mybtrfsremotebackupserver: --verbose
btrf-send
そして、コンテナとそのすべてのスナップショットの初期転送に使用されます。
すると、コンテナとそのスナップショットをメンテナンスする非常に便利な方法ができ、オプションを使用して増分変更のみを送信できます。--refresh
(LXD3.7)
lxc copy --refresh mycontainer mybtrfsremotebackupserver: --verbose
しかし残念ながら、rsync
少なくとも LXD 4.0 では を使用しているため、btrfs-send
最適化は失われます。
詳細については、この問題を確認してください:機能リクエスト: コピー用の --snapshots-only フラグ
また、「カスタム ボリューム コピーのサポートを更新」しかし、最適化されたパスを使用しているか、それが目的に役立つかどうかはわかりません。lxcエクスポートで--optimized-storageを確認することもできます。
よろしく