Metadaten beibehalten

In diesem Dokument werden Metadaten beschrieben, die beibehalten werden, wenn Sie mit dem Storage Transfer Service Daten zwischen verschiedenen Quellen und Zielen übertragen.

Übersicht

Storage Transfer Service speichert die folgenden Metadaten während einer Übertragung zu Cloud Storage:

• Von Nutzern erstellte benutzerdefinierte Metadaten für Übertragungen, die von Cloud Storage, Amazon Simple Storage Service (Amazon S3) oder Microsoft Azure Blob Storage (Microsoft Azure Storage) stammen.

• Übertragungen zwischen Cloud Storage-Buckets können optional Objekt-ACLs, vom Kunden verwaltete Verschlüsselungsschlüssel, Speicherklasse, Objekterstellungszeit (als Wert eines customTime-Felds) und temporäre Holds beibehalten. Die Speicherklasse des Objekts im Ziel-Bucket kann als Teil der Übertragung auf eine beliebige unterstützte Klasse festgelegt werden.

• Dateigröße und letzte Änderungszeit (mtime) für Übertragungen aus POSIX-Dateisystemen.

• Optional können Symlinks, numerische UID, numerische GID und numerischer MODE für Übertragungen von und zu POSIX-Dateisystemen beibehalten werden.

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 wie Metadaten aus dem Storage Transfer Service beibehalten werden. Eine vollständige Liste der Metadaten finden Sie in der Dokumentation des Quellspeichersystems.

Amazon S3 für 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.

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.

Ü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.
Objekt-Holds ^(Vorschau)	Ereignisbasierte Holds werden nicht beibehalten. Wenn für den Ziel-Bucket das standardmäßige ereignisbasierte Hold-Attribut aktiviert ist, wird ein ereignisbasierter Hold auf alle übertragenen Objekte angewendet. Temporäre Holds werden standardmäßig beibehalten. Um temporäre Holds während der Übertragung zu verwerfen, setzen Sie das Feld temporaryHold des Objekts metadataOptions auf TEMPORARY_HOLD_SKIP.
Access Control Lists (ACLs) ^(Vorschau) Weitere Informationen finden Sie in der Cloud Storage-Dokumentation zu Access Control Lists.	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.
Speicherklasse ^( Vorschau)	Es gibt mehrere Möglichkeiten, eine Speicherklasse während einer Übertragung festzulegen. Legen Sie für die Speicherklasse jedes Objekts die des Ziel-Buckets fest. Das ist das Standardverhalten. Behalten Sie die Speicherklasse des Quellobjekts bei. Legen Sie für alle übertragenen Objekte eine bestimmte Speicherklasse fest. Weitere Informationen finden Sie in der Referenzdokumentation zu metadataOptions.
Vom Kunden verwalteter Verschlüsselungsschlüssel ^( Vorschau)	Wenn ein vom Kunden verwalteter Verschlüsselungsschlüssel (CMEK) für ein Objekt verwendet wird, kann das Objekt optional denselben Schlüssel verwenden, wenn er in den Ziel-Bucket geschrieben wird. Standardmäßig wird das Objekt mithilfe der Verschlüsselungsmethode des Buckets in den Ziel-Bucket geschrieben. Beachten Sie beim Beibehalten des ursprünglichen CMEK folgende Einschränkungen: Der Ziel-Bucket muss sich am selben Standort wie der CMEK befinden. Wenn sich der Ziel-Bucket in einem anderen Projekt befindet, müssen Sie das Cloud Storage-Dienstkonto des Zielprojekts zum Schlüssel hinzufügen. Weitere Informationen finden Sie in der Referenzdokumentation zu metadataOptions.
Zeitstempelmetadaten ^(Vorschau)	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 Cloud Storage-Metadaten wie generation, 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.

POSIX-Dateisystemübertragungen

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

Beispiel für Metadaten	Aufbewahrungsverhalten
Geänderte Zeit (mtime) und Dateigröße.	Beibehalten. mtime wird als benutzerdefinierte Metadaten mit dem Schlüssel goog-reserved-file-mtime beibehalten. Die Dateigröße wird als size beibehalten.
Ordnerberechtigungen und harte Links	Nicht beibehalten. Storage Transfer Service erstellt keine Ordnerplatzhalterobjekte in Cloud Storage, um Ordner darzustellen.
Numerische UID, numerische GID, numerischer MODE und symbolische Links.	Das Aufbewahrungsverhalten wird mit dem Objekt metadataOptions angegeben. Weitere Informationen finden Sie unter Optionale POSIX-Metadaten beibehalten. Das Standardverhalten besteht darin, keine Metadaten beizubehalten.

Optionale POSIX-Metadaten beibehalten

Vorschau –Metadata preservation

Diese Funktion unterliegt den Nutzungsbedingungen des Pre-GA-Angebots der Google Cloud-Nutzungsbedingungen. Pre-GA-Funktionen werden möglicherweise nur eingeschränkt unterstützt. Änderungen an Pre-GA-Funktionen sind möglicherweise nicht mit anderen Pre-GA-Versionen kompatibel. Weitere Informationen finden Sie unter Beschreibungen der Startphase.

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 POSIX-zu-Cloud Storage-Übertragungen als auch für Cloud Storage-zu-POSIX-Übertragungen. Bei letzterem müssen die Metadaten bei der ersten Übertragung von Dateien an 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

Die beibehaltenen 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 Storage Transfer Service den Ziellink als Objekt in Cloud Storage mit den folgenden Eigenschaften bei:

• Der Objektschlüssel besteht aus dem Zielpräfix plus dem Pfad zum Symlink relativ zum root_directory.
• Objektmetadaten:
  • Alle Symlink-Metadaten werden als Cloud Storage-Objektmetadaten beibehalten.
  • Ein benutzerdefinierter Metadateneintrag wird erstellt: goog-reserved-file-is-symlink:true.
• Der Objektinhalt ist das Ziel des Symlinks. Für einen Symlink sym-> dir1/target lautet der Objektinhalt beispielsweise „dir1/target“.

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

Cloud Storage zu 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 beibehalten wurde, führt Storage Transfer Service die folgenden Aktionen aus:

• Symbolische Links: Der 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.