Diese Seite wurde von der Cloud Translation API übersetzt.

Metadaten beibehalten

In diesem Dokument werden Metadaten beschrieben, die beibehalten werden, wenn Sie den Storage Transfer Service verwenden, um Daten zwischen verschiedenen Quellen und Zielen zu übertragen.

Übersicht

Der Storage Transfer Service behält die folgenden Metadaten bei:

Von Nutzern erstellte benutzerdefinierte Metadaten für Übertragungen, die von Cloud Storage, Amazon S3 oder Microsoft Azure Blob Storage stammen, werden beibehalten.
Bei Übertragungen zwischen Cloud Storage-Buckets können optional Objekt-ACLs, vom Kunden verwaltete Verschlüsselungsschlüssel, Speicherklasse, Erstellungszeit des Objekts (als Wert eines customTime-Felds) und temporäre Vorhalte beibehalten werden.
Bei Übertragungen von einer beliebigen Quelle zu einem Cloud Storage-Bucket kann die Speicherklasse des Objekts im Ziel-Bucket im Rahmen der Übertragung auf eine beliebige unterstützte Klasse festgelegt werden.
Dateigröße und letzte Änderungszeit (mtime) werden für Übertragungen aus POSIX-Dateisystemen beibehalten. mtime wird für Ordner nicht beibehalten.
Optional können Symlinks, die numerische UID, die numerische GID und der numerische MODE für Übertragungen von und zu POSIX-Dateisystemen beibehalten werden.
Bei Übertragungen zwischen Dateisystemen werden UID, GID oder MODE nur beibehalten, wenn diese Metadaten auch für Ordner beibehalten werden. Cloud Storage erstellt Ordner im Zieldateisystem neu und stellt UID, GID und/oder MODE wieder her. Dazu gehören auch leere Ordner. mtime wird nicht beibehalten.

Metadaten auf Ordnerebene werden nicht beibehalten, wenn die Übertragung per Manifest erfolgt.

Metadatenfelder, die in diesem Dokument nicht explizit erwähnt werden, werden nicht beibehalten.

Verhalten bei der Metadatenaufbewahrung

In den folgenden Abschnitten werden Metadatenbeispiele aus verschiedenen Quellspeichersystemen aufgeführt und es wird beschrieben, wie Storage Transfer Service Metadaten von ihnen aufbewahrt. Eine vollständige Liste der Metadaten finden Sie in der Dokumentation des Quellspeichersystems.

Amazon S3 oder S3-kompatibler Speicher zu Cloud Storage

Beispiel für Metadaten	Aufbewahrungsverhalten
Metadatenschlüsselfelder von Amazon S3 mit einem Schlüssel, wie `Cache-Control`, `Content-Disposition` und `Content-Type`.	Wird als Metadaten mit festem Schlüssel beibehalten.
Benutzerdefinierte Amazon S3-Metadaten, formatiert als Schlüssel/Wert-Paare. Weitere Informationen finden Sie im Abschnitt Benutzerdefinierte Objektmetadaten von Objektschlüssel und Metadaten.	Wird als benutzerdefiniertes Metadatenfeld in Cloud Storage-Zielobjekten beibehalten, das Sie später bearbeiten oder entfernen können.
`ETag`	Wird als benutzerdefiniertes Metadatenfeld mit dem Schlüssel `x-goog-source-etag` beibehalten, das Sie später bearbeiten oder entfernen können.
Objektgröße.	Beibehalten als `size`.
Zugriffssteuerungslisten (ACLs) für Amazon S3. Eine vollständige Liste finden Sie im Abschnitt für Bedingungsschlüssel unter Access Control List (ACL) – Übersicht.	Nicht beibehalten.
Amazon S3-Objekt-Tags, die Sie als Schlüssel/Wert-Paare definieren. Weitere Informationen finden Sie unter Objekt-Tags.	Nicht beibehalten.
Vom System definierte Amazon S3-Metadaten, mit Ausnahme von `ETag` und Objektgröße. Eine vollständige Liste finden Sie im Abschnitt Systemdefinierte Objektmetadaten von Objektschlüssel und Metadaten.	Nicht beibehalten. Zeitstempelmetadaten aus der Quelle werden nicht beibehalten. Die Erstellungszeit `timeCreated` gibt die Zeit an, zu der ein Objekt in Cloud Storage erstellt wurde. Entsprechend gibt `updated` die Zeit an, zu der Metadaten für ein Objekt in Cloud Storage geändert wurden.
Speicherklasse	Es gibt mehrere Möglichkeiten, die Speicherklasse während einer Übertragung festzulegen. Legen Sie für jedes Objekt die Speicherklasse des Ziel-Buckets fest. Das ist das Standardverhalten. Legen Sie für alle zu übertragenden Objekte eine bestimmte Speicherklasse fest. Weitere Informationen finden Sie in der Referenzdokumentation zu metadataOptions.

Microsoft Azure Storage zu Cloud Storage

Beispiel für Metadaten	Aufbewahrungsverhalten
Feste Metadatenfelder von Microsoft Azure Storage, z. B. `Cache-Control`, `Content-Disposition` und `Content-Type`.	Wird als Metadaten mit festem Schlüssel beibehalten.
Benutzerdefinierte Microsoft Azure Storage-Metadaten, formatiert als Schlüssel/Wert-Paare. Weitere Informationen finden Sie unter Einstellungen und Abrufen von Attributen und Metadaten für Blob-Dienstressourcen.	Wird als benutzerdefiniertes Metadatenfeld in Cloud Storage-Zielobjekten beibehalten, das Sie später bearbeiten oder entfernen können.
`ETag`	Wird als benutzerdefiniertes Metadatenfeld mit dem Schlüssel `x-goog-source-etag` beibehalten, das Sie später bearbeiten oder entfernen können.
Objektgröße.	Beibehalten als `size`.
POSIX-Dateisystemberechtigungen, die von Azure Data Lake Storage (ADLS) Gen 2 unterstützt werden.	Nicht beibehalten.
Microsoft Azure Storage-Zugriffssteuerung, insbesondere `x-ms-blob-public-access`. Weitere Informationen finden Sie im Abschnitt Antwortheader von Container-ACL abrufen.	Nicht beibehalten.
Microsoft Azure Storage-Index-Tags. Weitere Informationen finden Sie unter Azure-Blob-Daten mit Blob-Index-Tags verwalten und finden.	Nicht beibehalten.
Microsoft Azure Storage-Zeitstempelmetadaten wie `Last-Modified`, `x-ms-creation-time`, `x-ms-version`, `x-ms-request-server-encrypted` und `x-ms-encryption-scope`. Weitere Informationen finden Sie unter Blob-Metadaten festlegen.	Nicht beibehalten. Zeitstempelmetadaten aus der Quelle werden nicht beibehalten. Die Erstellungszeit `timeCreated` gibt die Zeit an, zu der ein Objekt in Cloud Storage erstellt wurde. Entsprechend gibt `updated` die Zeit an, zu der Metadaten für ein Objekt in Cloud Storage geändert wurden.
Speicherklasse	Es gibt mehrere Möglichkeiten, die Speicherklasse während einer Übertragung festzulegen. Legen Sie für jedes Objekt die Speicherklasse des Ziel-Buckets fest. Das ist das Standardverhalten. Legen Sie für alle zu übertragenden Objekte eine bestimmte Speicherklasse fest. Weitere Informationen finden Sie in der Referenzdokumentation zu metadataOptions.

Übertragungen zwischen Cloud Storage-Buckets

Beispiel für Metadaten	Aufbewahrungsverhalten
Cloud Storage-Metadatenfelder mit festem Schlüssel, z. B. `Cache-Control`, `Content-Disposition` und `Content-Type`. Weitere Informationen finden Sie unter Objektmetadaten.	Wird als Metadaten mit festem Schlüssel beibehalten.
Benutzerdefinierte Cloud Storage-Metadaten, die als Schlüssel/Wert-Paare formatiert sind. Weitere Informationen finden Sie unter Benutzerdefinierte Metadaten.	Wird als benutzerdefiniertes Metadatenfeld in Cloud Storage-Zielobjekten beibehalten, das Sie später bearbeiten oder entfernen können.
Objektgröße	Beibehalten als `size`.
Objektgenerierung	Wird als benutzerdefiniertes Metadatenfeld mit dem Schlüssel `x-goog-reserved-source-generation` beibehalten, das Sie später bearbeiten oder entfernen können.
Objekt-Holds	Ereignisbasierte Holds werden nicht beibehalten. Wenn für den Ziel-Bucket das standardmäßige ereignisbasierte Hold-Attribut aktiviert ist, wird auf die übertragenen Objekte ein ereignisbasierter Hold angewendet. Vorautorisierungen werden standardmäßig beibehalten. Wenn Sie temporäre Holds während der Übertragung verwerfen möchten, legen Sie für das Feld `temporaryHold` des Objekts metadataOptions den Wert `TEMPORARY_HOLD_SKIP` fest.
Zugriffssteuerungslisten (ACLs)	ACLs können optional beibehalten werden. Weitere Informationen finden Sie in der Referenzdokumentation zu metadataOptions. Achten Sie beim Beibehalten von ACLs darauf, zu vermeiden, nicht zugängliche Objekte zu erstellen. Weitere Informationen finden Sie in der Cloud Storage-Dokumentation zu Zugriffssteuerungslisten.
Speicherklasse	Es gibt mehrere Möglichkeiten, die Speicherklasse während einer Übertragung festzulegen. Legen Sie für jedes Objekt die Speicherklasse des Ziel-Buckets fest. Das ist das Standardverhalten. Speicherklasse des Quellobjekts beibehalten Legen Sie für alle zu übertragenden Objekte eine bestimmte Speicherklasse fest. Weitere Informationen finden Sie in der Referenzdokumentation zu metadataOptions.
Vom Kunden verwalteter Verschlüsselungsschlüssel	Wenn ein vom Kunden verwalteter Verschlüsselungsschlüssel (CMEK) für ein Objekt verwendet wird, kann das Objekt optional denselben Schlüssel verwenden, wenn es in den Ziel-Bucket geschrieben wird. Standardmäßig wird das Objekt mit der Verschlüsselungsmethode des Ziel-Buckets in den Ziel-Bucket geschrieben. Beachten Sie beim Beibehalten des ursprünglichen CMEK die folgenden Einschränkungen: Der Ziel-Bucket muss sich am selben Speicherort wie der CMEK-Schlüssel befinden. Wenn sich der Ziel-Bucket in einem anderen Projekt befindet, müssen Sie dem Schlüssel das Cloud Storage-Dienstkonto des Zielprojekts hinzufügen. Weitere Informationen finden Sie in der Referenzdokumentation zu metadataOptions.
Metadaten für Zeitstempel	`timeCreated` kann optional beibehalten werden. Der beibehaltene Wert wird im Feld `customTime` des übertragenen Objekts in Cloud Storage gespeichert. Weitere Informationen finden Sie in der Referenzdokumentation zu metadataOptions. `updated`-Metadaten werden nicht beibehalten.
Andere nicht bearbeitbare Metadaten in Cloud Storage, z. B. `etag` und `componentCount`.	Nicht beibehalten.

Eine Liste der Metadaten in Cloud Storage finden Sie unter Objekte.

URL-Listenübertragung an Cloud Storage

Weitere Informationen zu URL-Listen finden Sie unter URL-Liste erstellen.

Beispiel für Metadaten	Aufbewahrungsverhalten
Felder für Metadaten mit festem Schlüssel wie `Cache-Control`, `Content-Disposition` und `Content-Type`.	Als bearbeitbare Metadaten beibehalten.
`Content-Length` und `MD5`	Als nicht bearbeitbare Metadaten beibehalten. Wenn die Quelle keinen `MD5`-Hashwert bereitstellt, behalten wir einen Wert nicht bei. Dieses Aufbewahrungsverhalten gilt nur für `Content-Length` und `MD5`. Alle anderen nicht bearbeitbaren Metadaten, die nicht aufgeführt sind, bleiben nicht erhalten.
Zeitstempelmetadaten, z. B. Erstellungszeitpunkt, Änderungszeit und andere quellenspezifische Metadaten.	Nicht beibehalten. Zeitstempelmetadaten aus der Quelle werden nicht beibehalten. Die Erstellungszeit `timeCreated` gibt die Zeit an, zu der ein Objekt in Cloud Storage erstellt wurde. Entsprechend gibt `updated` die Zeit an, zu der Metadaten für ein Objekt in Cloud Storage geändert wurden.
Speicherklasse	Es gibt mehrere Möglichkeiten, die Speicherklasse während einer Übertragung festzulegen. Legen Sie für jedes Objekt die Speicherklasse des Ziel-Buckets fest. Das ist das Standardverhalten. Legen Sie für alle zu übertragenden Objekte eine bestimmte Speicherklasse fest. Weitere Informationen finden Sie in der Referenzdokumentation zu metadataOptions.

POSIX-Dateisystemübertragungen

Wenn Sie Dateien aus POSIX-Dateisystemen übertragen, kann Storage Transfer Service optional bestimmte Attribute als benutzerdefinierte Metadaten beibehalten. Wenn diese Dateien später in ein Dateisystem zurückgeschrieben werden, kann Storage Transfer Service die beibehaltenen Metadaten zurück in POSIX-Attribute umwandeln.

Beispiel für Metadaten	Aufbewahrungsverhalten
Änderungszeitpunkt (`mtime`)	Beibehalten. `mtime` wird als benutzerdefinierte Metadaten mit dem Schlüssel `goog-reserved-file-mtime` beibehalten.
Dateigröße	Beibehalten. Die Dateigröße wird als `size` beibehalten.
Numerische UID Numerische GID Numerischer MODE Symbolische Links	Optional. Das Aufbewahrungsverhalten wird mit dem Objekt `metadataOptions` angegeben. Weitere Informationen finden Sie unter Optionale POSIX-Metadaten beibehalten. Standardmäßig werden keine Metadaten beibehalten.
Ordnermetadaten	Metadaten auf Ordnerebene bleiben nur bei Übertragungen zwischen Dateisystemen erhalten. Die Einstellungen für die Beibehaltung von UID, GID und MODE der Übertragung gelten für Dateien und Ordner bei diesen Übertragungen. `mtime` wird für Ordner nicht beibehalten. `mtime` wird auf die Erstellungszeit des Ordners im Zieldateisystem festgelegt. Ordnermetadaten werden bei Manifestübertragungen nicht beibehalten.
Speicherklasse	Es gibt mehrere Möglichkeiten, die Speicherklasse während einer Übertragung festzulegen. Legen Sie für jedes Objekt die Speicherklasse des Ziel-Buckets fest. Das ist das Standardverhalten. Legen Sie für alle zu übertragenden Objekte eine bestimmte Speicherklasse fest. Weitere Informationen finden Sie in der Referenzdokumentation zu metadataOptions.

Optionale POSIX-Metadaten beibehalten

Wenn Sie eine oder mehrere numerische UID, numerische GID, numerischen MODE und symbolische Links beibehalten möchten, geben Sie ein metadataOptions-Objekt im Text Ihres Übertragungsjobs an.

Diese Optionen gelten sowohl für Übertragungen von POSIX nach Cloud Storage als auch für Übertragungen von Cloud Storage nach POSIX. In letzterem Fall müssen die Metadaten bei der ursprünglichen Übertragung der Dateien in Cloud Storage beibehalten worden sein.

{
  "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 zu Cloud Storage

Beibehaltene Metadaten werden in Cloud Storage als benutzerdefinierte Metadaten-Schlüssel/Wert-Paare gespeichert.

Numerische GID wird als goog-reserved-posix-gid gespeichert.
Numerische UID wird als goog-reserved-posix-uid gespeichert.
Numerischer MODE wird als goog-reserved-posix-mode gespeichert.

Bei symbolischen Links behält der Storage Transfer Service den Ziellink als Objekt in Cloud Storage bei, und zwar mit den folgenden Eigenschaften:

Der Objektschlüssel besteht aus dem Zielpräfix und dem Pfad zum Symlink, relativ zum root_directory.
Objektmetadaten:
- Alle Metadaten von Symbollinks werden als Cloud Storage-Objektmetadaten beibehalten.
- Es wird ein benutzerdefinierter Metadateneintrag erstellt: goog-reserved-file-is-symlink:true.
Der Objektinhalt ist das Ziel des Symlinks. Bei einem Symlink sym-> dir1/target ist der Inhalt des Objekts beispielsweise „dir1/target“.

Storage Transfer Service validiert den Link nicht und kopiert nicht die Zieldatei.

Cloud Storage nach POSIX

Wenn Metadaten bei der Übertragung von Dateien in Cloud Storage beibehalten werden, können diese Metadaten bei der Übertragung zurück in ein POSIX-Dateisystem zurück in die Dateien geschrieben werden.

Wenn eine Metadatenoption zum Beibehalten eingestellt wurde, führt Storage Transfer Service die folgenden Aktionen aus:

Symbolische Links: Storage Transfer Service erstellt eine Symlink-Datei, die auf den Ziellink verweist. Wenn die Zieldatei nicht vorhanden ist, ist der Symlink fehlerhaft.
GID, UID und MODE: die in Cloud Storage-Metadaten gespeicherten Werte werden in die Datei zurückgeschrieben.

POSIX nach POSIX

Bei Übertragungen zwischen Dateisystemen können GID, UID und MODE für Dateien und Ordner optional beibehalten werden.

Der Zeitpunkt der letzten Änderung wird für Dateien, aber nicht für Ordner gespeichert. mtime wird auf die Erstellungszeit des Ordners im Zieldateisystem festgelegt.

Der Storage Transfer Service speichert Ordnermetadaten, indem er Ordnerobjekte mit 0 Byte im Zwischen-Bucket erstellt und diese Metadaten dann zurück in den Ordner im Zieldateisystem kopiert. Aus diesem Grund kann die Anzahl der im Zwischen-Bucket erstellten Objekte höher sein als die Anzahl der übertragenen Dateien.