メタデータの保持

このドキュメントでは、Storage Transfer Service を使用してさまざまなソースと宛先間でデータを転送するときに保持されるメタデータについて説明します。

概要

Storage Transfer Service は次のメタデータを保持します。

Cloud Storage、Amazon S3、Microsoft Azure Blob Storage からの転送用にユーザーが作成したカスタムメタデータは保持されます。
Cloud Storage バケット間の転送では、オプションでオブジェクト ACL、顧客管理の暗号鍵、ストレージクラス、オブジェクト作成時間（customTime フィールドの値として）、一時保留を保持できます。
任意の送信元から Cloud Storage バケットへの転送の場合、転送中に、転送先バケット内のオブジェクトのストレージクラスをサポート対象の任意のクラスに設定できます。
POSIX ファイルシステムからの転送では、ファイルサイズと最終更新日時（mtime）が保持されます。フォルダの mtime は保持されません。
シンボリックリンク、数値 UID、数値 GID、数値 MODE は、POSIX ファイルシステムとの間での転送用に任意に保持できます。
ファイルシステム間の転送の場合のみ、UID、GID、MODE が保持されていると、そのメタデータはフォルダに対しても保持されます。Cloud Storage は、宛先ファイルシステムにフォルダを再作成して、UID、GID、MODE を復元します。これには空のフォルダも含まれます。mtime は保持されません。

転送がマニフェストによって行われる場合、フォルダレベルのメタデータは保持されません。

このドキュメントで明記されていないメタデータフィールドは保持されません。

メタデータの保持動作

以降のセクションでは、さまざまなソースストレージシステムのメタデータの例と、Storage Transfer Service でメタデータが保持される仕組みを説明します。メタデータの完全なリストについては、ソースストレージシステムのドキュメントをご覧ください。

Amazon S3 または S3 互換ストレージから Cloud Storage

メタデータの例	保持動作
Amazon S3 の固定キーメタデータフィールド（`Cache-Control`、`Content-Disposition`、`Content-Type` など）。	固定キーメタデータとして保持されます。
Amazon S3 ユーザー定義メタデータ（Key-Value ペアの形式）。詳細については、オブジェクトキーとメタデータのユーザー定義のオブジェクトメタデータセクションをご覧ください。	転送先 Cloud Storage オブジェクトのカスタムメタデータフィールドとして保持され、後で編集や削除ができます。
`ETag`	キー `x-goog-source-etag` を持つカスタムメタデータフィールドとして保持され、後で編集や削除ができます。
オブジェクトサイズ。	`size` として保持されます。
Amazon S3 アクセス制御リスト（ACL）。完全なリストについては、アクセス制御リスト（ACL）の概要の条件キーをご覧ください。	保持されません。
Key-Value ペアとして定義した Amazon S3 オブジェクトタグ。詳しくは、オブジェクトタグをご覧ください。	保持されません。
Amazon S3 システム定義メタデータ（`ETag` とオブジェクトサイズを除く）。完全なリストについては、オブジェクトキーとメタデータのシステム定義のオブジェクトメタデータをご覧ください。	保持されません。ソースのタイムスタンプメタデータは保持されません。作成時間 `timeCreated` は、Cloud Storage でオブジェクトが作成された時間を表します。同様に、`updated` は、Cloud Storage でオブジェクトのメタデータが変更される時刻を表します。
ストレージクラス	転送中にストレージクラスを設定するには、複数の方法があります。各オブジェクトのストレージクラスを、転送先バケットのストレージクラスに設定します。これはデフォルトの動作です。転送するすべてのオブジェクトに特定のストレージクラスを設定します。詳しくは、 metadataOptions のリファレンスドキュメントをご覧ください。

Microsoft Azure Storage から Cloud Storage

メタデータの例	保持動作
Microsoft Azure Storage の固定キーメタデータフィールド（`Cache-Control`、`Content-Disposition`、`Content-Type` など）。	固定キーメタデータとして保持されます。
Microsoft Azure Storage ユーザー定義のメタデータ（Key-Value ペアの形式）。詳細については、Blob サービスリソースのプロパティとメタデータの設定と取得をご覧ください。	転送先 Cloud Storage オブジェクトのカスタムメタデータフィールドとして保持され、後で編集や削除ができます。
`ETag`	キー `x-goog-source-etag` を持つカスタムメタデータフィールドとして保持され、後で編集や削除ができます。
オブジェクトサイズ。	`size` として保持されます。
Azure Data Lake Storage（ADLS）Gen 2 でサポートされる POSIX ファイルシステム権限。	保持されません。
Microsoft Azure Storage のアクセス制御（具体的には `x-ms-blob-public-access`）。詳細については、Container ACL の取得のレスポンスヘッダーをご覧ください。	保持されません。
Microsoft Azure Storage のインデックスタグ。詳細については、blob インデックスタグを使用して Azure Blob データを管理、検索するをご覧ください。	保持されません。
`Last-Modified`、`x-ms-creation-time`、`x-ms-version`、`x-ms-request-server-encrypted`、`x-ms-encryption-scope` などの Microsoft Azure Storage タイムスタンプメタデータ。詳細については、Blob メタデータの設定をご覧ください。	保持されません。ソースのタイムスタンプメタデータは保持されません。作成時間 `timeCreated` は、Cloud Storage でオブジェクトが作成された時間を表します。同様に、`updated` は、Cloud Storage でオブジェクトのメタデータが変更される時刻を表します。
ストレージクラス	転送中にストレージクラスを設定するには、複数の方法があります。各オブジェクトのストレージクラスを、転送先バケットのストレージクラスに設定します。これはデフォルトの動作です。転送するすべてのオブジェクトに特定のストレージクラスを設定します。詳しくは、 metadataOptions のリファレンスドキュメントをご覧ください。

Cloud Storage バケット間の転送

メタデータの例	保持動作
Cloud Storage の固定キーメタデータフィールド（`Cache-Control`、`Content-Disposition`、`Content-Type` など）。詳細については、オブジェクトのメタデータをご覧ください。	固定キーメタデータとして保持されます。
Cloud Storage のユーザー定義メタデータ（Key-Value ペアの形式）。詳細については、カスタムメタデータをご覧ください。	転送先 Cloud Storage オブジェクトのカスタムメタデータフィールドとして保持され、後で編集や削除ができます。
オブジェクトサイズ	`size` として保持されます。
オブジェクトの生成	キー `x-goog-reserved-source-generation` を持つカスタムメタデータフィールドとして保持され、後で編集や削除ができます。
オブジェクト保留	イベントベースの保留は保持されません。転送先バケットでデフォルトのイベントベースの保留プロパティが有効になっている場合、転送されたオブジェクトにイベントベースの保留が適用されます。一時保留はデフォルトで保持されます。転送中に一時保留を破棄するには、 metadataOptions オブジェクトの `temporaryHold` フィールドを `TEMPORARY_HOLD_SKIP` に設定します。
アクセス制御リスト（ACL）	必要に応じて、ACL を保持できます。詳しくは、 metadataOptions のリファレンスドキュメントをご覧ください。 ACL を保持するときは、アクセスできないオブジェクトが作成されることがないように注意してください。詳細については、Cloud Storage のアクセス制御リストのドキュメントをご覧ください。
ストレージクラス	転送中にストレージクラスを設定するには、複数の方法があります。各オブジェクトのストレージクラスを、転送先バケットのストレージクラスに設定します。これはデフォルトの動作です。ソースオブジェクトのストレージクラスを保持します。転送するすべてのオブジェクトに特定のストレージクラスを設定します。詳しくは、 metadataOptions のリファレンスドキュメントをご覧ください。
顧客管理の暗号鍵	オブジェクトに顧客管理の暗号鍵（CMEK）が使用されている場合、オブジェクトが転送先バケットに書き込まれるときに同じ鍵を使用することもできます。デフォルトの動作では、バケットの暗号化方式を使用して、オブジェクトを転送先バケットに書き込みます。元の CMEK を保持する場合は、次の制限事項に注意してください。転送先バケットは CMEK と同じロケーションに存在する必要があります。転送先バケットが別のプロジェクトにある場合、転送先プロジェクトの Cloud Storage サービスアカウントを鍵に追加する必要があります。詳しくは、 metadataOptions のリファレンスドキュメントをご覧ください。
タイムスタンプメタデータ	必要に応じて、`timeCreated` を保持できます。保持された値は、Cloud Storage の転送されたオブジェクトの `customTime` フィールドに格納されます。詳しくは、 metadataOptions のリファレンスドキュメントをご覧ください。 `updated` メタデータは保持されません。
その他の Cloud Storage の編集不可メタデータ（`etag`、`componentCount` など）。	保持されません。

Cloud Storage のメタデータのリストについては、オブジェクトをご覧ください。

Cloud Storage への URL リスト転送

URL リストの詳細については、URL リストの作成をご覧ください。

メタデータの例	保持動作
固定キーメタデータフィールド（`Cache-Control`、`Content-Disposition`、`Content-Type` など）。	編集可能メタデータとして保持されます。
`Content-Length` と `MD5`	編集不可メタデータとして保持されます。ソースで `MD5` ハッシュ値が指定されていない場合、値は保持されません。この保持動作は、`Content-Length` と `MD5` に固有のものです。上記以外の編集不可メタデータは保持されません。
タイムスタンプメタデータ（作成日時、変更日時、その他のソース固有のメタデータなど）。	保持されません。ソースのタイムスタンプメタデータは保持されません。作成時間 `timeCreated` は、Cloud Storage でオブジェクトが作成された時間を表します。同様に、`updated` は、Cloud Storage でオブジェクトのメタデータが変更される時刻を表します。
ストレージクラス	転送中にストレージクラスを設定するには、複数の方法があります。各オブジェクトのストレージクラスを、転送先バケットのストレージクラスに設定します。これはデフォルトの動作です。転送するすべてのオブジェクトに特定のストレージクラスを設定します。詳しくは、 metadataOptions のリファレンスドキュメントをご覧ください。

POSIX ファイルシステム転送

POSIX ファイルシステムからファイルを転送する際に、Storage Transfer Service は特定の属性をカスタムメタデータとして保持できます。これらのファイルが後でファイルシステムに書き戻された場合、Storage Transfer Service は保存されたメタデータを POSIX 属性に変換できます。

メタデータの例	保持動作
変更時刻（`mtime`）	保持されます。 `mtime` は、キー `goog-reserved-file-mtime` を持つカスタムメタデータとして保持されます。
ファイルサイズ	保持されます。ファイルサイズは `size` として保持されます。
数値 UID 数値 GID 数値 MODE シンボリックリンク	省略可。保持動作は `metadataOptions` オブジェクトで指定します。詳細については、オプションの POSIX メタデータの保持をご覧ください。デフォルトの動作では、メタデータは保持されません。
フォルダのメタデータ	フォルダレベルのメタデータは、ファイルシステム間の転送でのみ保持されます。転送の UID、GID、MODE 保持の設定は、これらの転送のファイルとフォルダに適用されます。フォルダの `mtime` は保持されません。`mtime` は、宛先ファイルシステム上にフォルダが作成された時刻に設定されます。マニフェストの転送では、フォルダのメタデータは保持されません。
ストレージクラス	転送中にストレージクラスを設定するには、複数の方法があります。各オブジェクトのストレージクラスを、転送先バケットのストレージクラスに設定します。これはデフォルトの動作です。転送するすべてのオブジェクトに特定のストレージクラスを設定します。詳しくは、 metadataOptions のリファレンスドキュメントをご覧ください。

オプションの POSIX メタデータの保持

1 つ以上の数値 UID、数値 GID、数値 MODE、シンボリックリンクを保持するには、転送ジョブの本文で metadataOptions オブジェクトを指定します。

これらのオプションは、POSIX から Cloud Storage への転送と Cloud Storage から POSIX への転送の両方に適用されます。後者の場合、ファイルが最初に Cloud Storage に転送された時点でメタデータを保持しておく必要があります。

{
  "description": "metadata-example",
  "projectId": "example-project-id"
  "transferSpec": {
    ...
    "transferOptions": {
      "metadataOptions": {
        "gid":     "GID_NUMBER",       # Default is "GID_SKIP"
        "uid":     "UID_NUMBER",       # Default is "UID_SKIP"
        "mode":    "MODE_PRESERVE",    # Default is "MODE_SKIP"
        "symlink": "SYMLINK_PRESERVE"  # Default is "SYMLINK_SKIP"
      }
    }
  }
}

POSIX から Cloud Storage

保持されたメタデータは、カスタムメタデータの Key-Value ペアとして Cloud Storage に保存されます。

数値 GID は goog-reserved-posix-gid として保存されます。
数値 UID は goog-reserved-posix-uid として保存されます。
数値 MODE は goog-reserved-posix-mode として保存されます。

シンボリックリンクの場合、Storage Transfer Service は、次の品質でターゲットリンクを Cloud Storage のオブジェクトとして保持します。

オブジェクトキーは、転送先の接頭辞とシンボリックリンクへのパス（root_directory への相対パス）で構成されます。
オブジェクトのメタデータ:
- シンボリックリンクメタデータは、Cloud Storage オブジェクトのメタデータとして保持されます。
- カスタムメタデータのエントリが作成されます。goog-reserved-file-is-symlink:true。
オブジェクトのコンテンツはシンボリックリンクのターゲットです。たとえば、シンボリックリンク sym-> dir1/target の場合、オブジェクトのコンテンツは「dir1/target」です。

Storage Transfer Service では、リンクの検証やターゲットファイルのコピーは行われません。

Cloud Storage から POSIX

ファイルを Cloud Storage に転送する際にメタデータを保持すると、ファイルを POSIX ファイルシステムに転送して戻すときに、メタデータをファイルに書き戻すことができます。

メタデータオプションが保持されるように設定されている場合、Storage Transfer Service は次の処理を行います。

シンボリックリンク: Storage Transfer Service は、ターゲットリンクを指すシンボリックリンクファイルを作成します。ターゲットファイルが存在しない場合は、シンボリックリンクが壊れます。
GID、UID、MODE: Cloud Storage メタデータに保存されている値がファイルに書き戻されます。

POSIX 間

ファイルシステム間の転送では、必要に応じてファイルとフォルダの GID、UID、MODE を保持できます。

最終更新日時はファイルに保存されますが、フォルダの場合は保存されません。mtime は、宛先ファイルシステム上のフォルダの作成時間に設定されます。

Storage Transfer Service は、中間バケットに 0 バイトのフォルダオブジェクトを作成し、そのメタデータを宛先ファイルシステムのフォルダにコピーすることで、フォルダのメタデータを保存します。このため、中間バケットで作成されたオブジェクトの数が、転送されるファイルの数より多くなる場合があります。