In diesem Dokument werden Metadaten beschrieben, die beibehalten werden, wenn Sie mit dem Storage Transfer Service Daten zwischen verschiedenen Quellen und Zielen übertragen.
Überblick
Storage Transfer Service behält die folgenden Metadaten bei:
Vom Nutzer erstellte benutzerdefinierte Metadaten für Übertragungen aus Cloud Storage, Amazon S3 oder Microsoft Azure Blob Storage werden beibehalten.
Bei Übertragungen zwischen Cloud Storage-Buckets können optional Objekt-ACLs, vom Kunden verwaltete Verschlüsselungsschlüssel, die Speicherklasse, der Zeitpunkt der Objekterstellung (als Wert eines
customTime
-Felds) und temporäre Holds beibehalten werden.Bei Übertragungen von einer beliebigen Quelle in einen Cloud Storage-Bucket kann die Speicherklasse des Objekts im Ziel-Bucket auf eine beliebige unterstützte Klasse im Rahmen der Übertragung festgelegt werden.
Die Dateigröße und der Zeitpunkt der letzten Änderung (
mtime
) werden für Übertragungen aus POSIX-Dateisystemen beibehalten.mtime
wird für Ordner nicht beibehalten.Optional können Symlinks, numerische UID, numerische GID und numerischer MOD für Übertragungen zu und von POSIX-Dateisystemen beibehalten werden.
Nur bei Übertragungen zwischen Dateisystemen: Wenn UID, GID oder MODE beibehalten werden, werden die Metadaten auch für Ordner beibehalten. Cloud Storage erstellt Ordner im Zieldateisystem neu und stellt die UID, die GID und/oder den 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 erklärt, wie Storage Transfer Service Metadaten aus den einzelnen Systemen speichert. 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 |
Speicherklasse |
Es gibt mehrere Möglichkeiten, die Speicherklasse während einer Übertragung festzulegen.
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 |
Speicherklasse |
Es gibt mehrere Möglichkeiten, die Speicherklasse während einer Übertragung festzulegen.
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. 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 |
Terminbasierte Holds werden nicht beibehalten. Wenn im Ziel-Bucket das standardmäßige ereignisbasierte Hold-Attribut aktiviert ist, wird ein ereignisbasierter Hold auf übertragene Objekte angewendet. Temporäre Holds werden standardmäßig beibehalten. Wenn Sie temporäre Holds während der Übertragung verwerfen möchten, setzen Sie das Feld |
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.
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. Das Objekt wird standardmäßig mit der Verschlüsselungsmethode des Buckets in den Ziel-Bucket geschrieben. Beachten Sie die folgenden Einschränkungen, wenn Sie den ursprünglichen CMEK beibehalten:
Weitere Informationen finden Sie in der Referenzdokumentation zu metadataOptions. |
Zeitstempelmetadaten |
|
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
Dieses Aufbewahrungsverhalten gilt nur für |
Zeitstempelmetadaten, z. B. Erstellungszeitpunkt, Änderungszeit und andere quellenspezifische Metadaten. |
Nicht beibehalten.
Zeitstempelmetadaten aus der Quelle werden nicht beibehalten. Die Erstellungszeit |
Speicherklasse |
Es gibt mehrere Möglichkeiten, die Speicherklasse während einer Übertragung festzulegen.
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 |
---|---|
Zeitpunkt der Änderung (mtime )
|
Beibehalten.
|
Dateigröße |
Beibehalten. Die Dateigröße wird als |
Numerische UID Numerische GID Numerischer MODUS Symbolische Links |
Optional. Das Beibehaltungsverhalten wird mit dem Objekt Standardmäßig werden Metadaten nicht beibehalten. |
Ordnermetadaten | Metadaten auf Ordnerebene werden nur für Übertragungen zwischen Dateisystemen beibehalten. Die UID-, GID- und MODE-Beibehaltungseinstellungen der Übertragung gelten für Dateien und Ordner bei diesen Übertragungen.
Die Ordnermetadaten werden für Manifestübertragungen nicht beibehalten. |
Speicherklasse |
Es gibt mehrere Möglichkeiten, die Speicherklasse während einer Übertragung festzulegen.
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 POSIX-zu-Cloud Storage-Übertragungen als auch für Cloud Storage-zu-POSIX-Übertragungen. Bei Letzterem müssen die Metadaten bei der anfä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
Die beibehaltenen Metadaten werden in Cloud Storage als benutzerdefinierte Schlüssel/Wert-Paare von Metadaten 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 in Cloud Storage als Objekt mit den folgenden Eigenschaften bei:
- Der Objektschlüssel besteht aus dem Zielpräfix und 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. Bei einem Symlink
sym-> dir1/target
lautet der Objektinhalt beispielsweise „dir1/target“.
Storage Transfer Service validiert den Link nicht und kopiert nicht 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 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 gespeichert, nicht aber für Ordner. mtime
ist auf die Erstellungszeit des Ordners im Zieldateisystem festgelegt.
Storage Transfer Service speichert Ordnermetadaten, indem 0-Byte-Ordnerobjekte im Zwischen-Bucket erstellt werden. Anschließend werden diese Metadaten zurück in den Ordner im Zieldateisystem kopiert. Aus diesem Grund ist die Anzahl der im Zwischen-Bucket erstellten Objekte möglicherweise größer als die Anzahl der Dateien, die übertragen werden.