Dockerボリュームの復元でファイルの内容は再現されるのに、拡張属性が失われるのはなぜですか?

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Dockerボリュームを復元すると、すべてのファイルを1バイト単位で再現できても、バックアップ形式、オプション、権限、または保存先が拡張属性を保持できない場合、拡張属性が失われることがあります。

拡張属性は、通常のファイル内容、所有者、モードビット、タイムスタンプとは別に保存される、メタデータの名前と値のペアです。ACLデータ、SELinuxラベル、Linuxケーパビリティ、アプリケーションマーカー、Sambaメタデータなどを格納できます。tarベースの単純なボリュームバックアップでは、アーカイブが拡張属性を記録していなかったり、復元プロセスが保護された名前空間に書き込めなかったりするため、完全に見えるディレクトリを復元しても、アプリケーションの動作が異なる場合があります。

復元を繰り返す前に、元データの属性を調べる

代表的なファイルを選び、ハッシュ、所有者、モード、ACL、すべての拡張属性の名前と値を記録します。復元後にアプリケーションで問題が発生するファイルも含めてください。

Linuxのxattrモデルでは、user、system、security、trustedの名前空間が分離されており、それぞれアクセス権と必要な権限が異なります。

元データに拡張属性がなければ、復元時に失われたわけではありません。1つの名前空間だけが消えている場合は、アーカイブのファイル内容層ではなく、権限、セキュリティポリシー、保存先の対応状況を確認してください。

Dockerのバックアップコマンドが実際に何をアーカイブしたか確認する

バックアップコンテナで使用した正確なイメージ、コマンド、作業ディレクトリ、アーカイブ形式、ユーザー、マウントした元データ、マウントしたバックアップ先を保存します。

Dockerのボリュームバックアップ例では、ヘルパーコンテナ内でtarを使用しますが、メタデータの保持はtarの実装と選択したオプションにも左右されます。

アーカイブファイルの作成に成功したことは、ディレクトリエントリと内容を読み取れたことを示すだけで、すべての拡張属性の名前空間が含まれていることを意味しません。作成に使用したものと同じツールでアーカイブを調べてください。

アーカイブの作成と展開で拡張属性を有効にする

バックアップと復元で使用したtarオプションを比較します。両方向で拡張属性が有効になっていること、またincludeまたはexcludeパターンによって必要な名前空間が除外されていないことを確認してください。

GNU tarでは、--xattrsで拡張属性を保存および復元できると説明されています。

展開時だけオプションを追加しても、保存されていなかった属性を復元することはできません。既知のテスト用拡張属性を設定した元ファイルから小さな新規アーカイブを作成し、本番バックアップを変更する前に調べてください。

ファイルベースのバックアップでは、Rsyncのメタデータオプションを正しく指定する

ボリュームバックアップでRsyncを使用している場合は、送信側と受信側のアーカイブ、ACL、拡張属性、数値ID、fake-super、権限関連のオプションを確認します。

Rsyncの公式マニュアルでは、拡張属性を保持する-Xオプションが説明されており、特権メタデータを直接適用できない場合のfake-superによる保存についても記載されています。

一般的な-aアーカイブオプションだけでは、すべてのACLと拡張属性の要件が自動的に含まれるわけではありません。実際の元ファイルシステムと保存先ファイルシステム間で、使用する正確なコマンドをテストしてください。

保存先のファイルシステムとマウントの対応状況を確認する

復元したボリューム上に一時的なファイルを直接作成し、ユーザー拡張属性を1つ設定、一覧表示、削除できるか試します。ホスト経由とバックアップコンテナ経由の両方で繰り返してください。

ホストと復元コンテナの両方で属性一覧表示ユーティリティを使用し、バックアップアーカイブとは独立して、保存先が拡張属性を受け付け、返せることを確認します。

拡張属性を直接作成できない場合は、ファイルシステムの種類、マウントオプション、ネットワークプロトコル、ボリュームドライバー、ストレージアプライアンスの対応状況を調べます。保存先が表現できないメタデータを、アーカイブのオプションで復元することはできません。

securityおよびtrusted名前空間の権限を確認する

復元を行うコンテナのユーザー、ケーパビリティ、ユーザー名前空間、rootlessモード、SELinuxポリシー、ボリュームパスがホストからバインドマウントされているかどうかを記録します。

Red Hatでは、ファイルをコピーまたは再作成した後、SELinuxラベルをポリシーに適合する形で復元する必要がある場合があると説明しています。

バックアップコンテナにホスト全体への広範な権限を恒久的に付与しないでください。管理された復元環境を使用するか、まず通常のデータを復元し、対応ツールでポリシー管理対象のラベルを再適用してください。

ACL、ケーパビリティ、アプリケーション固有の拡張属性を分けて確認する

POSIX ACLエントリ、Linuxファイルケーパビリティ、SELinuxラベル、ユーザー拡張属性、SambaまたはmacOSのメタデータを個別に比較します。これらは異なる原因で失敗する可能性があります。

Sambaのxattr_tdbモジュールは、基盤となるファイルシステムとは別に拡張属性を保存できます。

そのため、ファイル単位のボリュームアーカイブでは目に見えるファイルツリーを保持できても、別のSambaメタデータデータベースまでは保持できない場合があります。依存するすべてのメタデータストアを含めるか、アプリケーションがサポートする手順で再構築してください。

テスト用ファイルを1つ復元し、アプリケーションを検証する

内容ハッシュ、ACL、ユーザー拡張属性、必要なアプリケーションメタデータを設定した既知の元ファイルを作成します。それをバックアップし、一時的なボリュームに復元します。

ZimaSpaceの記事NASへの移行に伴う権限とメタデータの変更では、より広い範囲の移行動作を扱っています。この記事ではDockerボリュームのバックアップと復元に焦点を当てています。

2回目の管理されたバックアップと復元の後に、内容ハッシュ、必要な拡張属性の名前と値、ACL、セキュリティラベル、アプリケーションの動作がすべて一致すれば、問題は解決したと判断できます。

よくある質問

拡張属性はACLと同じものですか?

いいえ。ACLは一部のファイルシステムでsystem拡張属性を使って実装される場合がありますが、拡張属性にはセキュリティラベル、ケーパビリティ、ユーザーメタデータ、アプリケーション固有の値も保存されます。

tarはデフォルトで拡張属性を保持しますか?

保持すると仮定しないでください。GNU tarには拡張属性用の明示的なオプションがあり、展開で復元するには、作成時にアーカイブへ属性を保存しておく必要があります。

rootとして実行しても、復元時に拡張属性が失われることはありますか?

はい。アーカイブに属性が含まれていない、保存先が属性に対応していない、セキュリティポリシーによって拒否される、またはメタデータが別のアプリケーションデータベースに保存されている可能性があります。

サポートとヒント

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.