Ce document décrit les métadonnées conservées lorsque vous utilisez le service de transfert de stockage pour transférer des données entre différentes sources et destinations.
Présentation
Le service de transfert de stockage conserve les métadonnées suivantes:
Les métadonnées personnalisées créées par l'utilisateur pour les transferts provenant de Cloud Storage, Amazon S3 ou Microsoft Azure Blob Storage sont conservées.
Les transferts entre des buckets Cloud Storage peuvent éventuellement conserver les LCA d'objets, les clés de chiffrement gérées par le client, la classe de stockage, l'heure de création des objets (valeur de champ
customTime
) et les préservations temporaires.Pour les transferts depuis n'importe quelle source vers un bucket Cloud Storage, du bucket de destination peut être définie sur n'importe quelle classe compatible, lors du transfert.
La taille du fichier et l'heure de la dernière modification (
mtime
) sont conservées pour les transferts provenant de systèmes de fichiers POSIX.mtime
n'est pas conservé pour les dossiers.Si vous le souhaitez, vous pouvez conserver les liens symboliques, l'UID numérique, le GID numérique et le MODE numérique pour les transferts depuis et vers les systèmes de fichiers POSIX.
Pour les transferts entre systèmes de fichiers uniquement, si les UID, GID ou MODE sont conservés, ces métadonnées sont également conservées pour les dossiers. Cloud Storage recrée les dossiers sur le système de fichiers de destination et restaure les UID, GID et/ou MODE. Cela inclut les dossiers vides.
mtime
n'est pas conservé.Les métadonnées au niveau du dossier ne sont pas conservées si le transfert est effectué par fichier manifeste.
Les champs de métadonnées qui ne sont pas explicitement mentionnés dans ce document ne sont pas conservés.
Comportement de conservation des métadonnées
Les sections suivantes répertorient des exemples de métadonnées provenant de différents systèmes de stockage sources et la manière dont le service de transfert de stockage conserve les métadonnées de chacun d'eux. Pour consulter la liste exhaustive des métadonnées, reportez-vous à la documentation du système de stockage source.
Espace de stockage compatible Amazon S3 ou S3 vers Cloud Storage
Exemple de métadonnées | Comportement de conservation |
---|---|
Champs de métadonnées à clé fixe Amazon S3, tels que : Cache-Control , Content-Disposition et Content-Type
|
Conservation en tant que métadonnées à clé fixe |
Métadonnées définies par l'utilisateur Amazon S3, sous forme de paires clé/valeur. Pour en savoir plus, consultez la section Métadonnées d'objet définies par l'utilisateur de la page Clés et métadonnées d'objets. |
Conservation en tant que champ de métadonnées personnalisé dans les objets Cloud Storage de destination, que vous pouvez modifier ultérieurement ou supprimer. |
ETag |
Conservation en tant que champ de métadonnées personnalisé avec la clé x-goog-source-etag , que vous pouvez modifier ultérieurement ou supprimer.
|
Taille de l'objet |
Conservation en tant que size
|
Listes de contrôle d'accès Amazon S3 Pour obtenir la liste complète, consultez la section Clés de condition de la Présentation des listes de contrôle d'accès (LCA). | Aucune conservation |
Tags d'objet Amazon S3, que vous définissez en tant que paires clé-valeur. Pour en savoir plus, consultez la page Tags d'objet. | Aucune conservation |
Métadonnées définies par le système Amazon S3, à l'exception de ETag et de la taille de l'objet Pour obtenir la liste complète, consultez la section Métadonnées d'objet définies par le système de la page Clé et métadonnées d'objet. |
Aucune conservation
Les métadonnées d'horodatage de la source ne sont pas conservées. L'heure de création, |
Classe de stockage |
Il existe plusieurs options pour définir la classe de stockage lors d'un transfert.
Pour plus d'informations, consultez la documentation de référence de metadataOptions. |
Microsoft Azure Storage vers Cloud Storage
Exemple de métadonnées | Comportement de conservation |
---|---|
Champs de métadonnées à clé fixe Microsoft Azure Storage, tels que Cache-Control , Content-Disposition et Content-Type
|
Conservation en tant que métadonnées à clé fixe |
Métadonnées définies par l'utilisateur Microsoft Azure Storage, sous forme de paires clé/valeur. Pour plus d'informations, consultez l'article Définition et récupération des propriétés et des métadonnées pour les ressources du service BLOB. |
Conservation en tant que champ de métadonnées personnalisé dans les objets Cloud Storage de destination, que vous pouvez modifier ultérieurement ou supprimer. |
ETag
|
Conservation en tant que champ de métadonnées personnalisé avec la clé x-goog-source-etag , que vous pouvez modifier ultérieurement ou supprimer.
|
Taille de l'objet |
Conservation en tant que size
|
Autorisations du système de fichiers POSIX compatibles avec Azure Data Lake Storage (ADLS) 2e génération. | Aucune conservation |
Contrôle des accès Microsoft Azure Storage, en particulier x-ms-blob-public-access Pour en savoir plus, consultez la section En-têtes de réponse de la page Get Container ACL.
|
Aucune conservation |
Tags d'index Microsoft Azure Storage Pour en savoir plus, consultez la page Gérer et rechercher des données Azure Blob à l'aide de balises d'index de blob (préversion). | Aucune conservation |
Métadonnées d'horodatage Microsoft Azure Storage, telles que : Last-Modified , x-ms-creation-time , x-ms-version , x-ms-request-server-encrypted et x-ms-encryption-scope
Pour en savoir plus, consultez l'article Set Blob Metadata.
|
Aucune conservation
Les métadonnées d'horodatage de la source ne sont pas conservées. L'heure de création, |
Classe de stockage |
Il existe plusieurs options pour définir la classe de stockage lors d'un transfert.
Pour plus d'informations, consultez la documentation de référence de metadataOptions. |
Transferts entre des buckets Cloud Storage
Exemple de métadonnées | Comportement de conservation |
---|---|
Champs de métadonnées à clé fixe Cloud Storage, tels que Pour en savoir plus, consultez l'article Métadonnées des objets. |
Conservation en tant que métadonnées à clé fixe |
Métadonnées Cloud Storage définies par l'utilisateur, sous forme de paires clé/valeur. Pour en savoir plus, consultez la section Métadonnées personnalisées. |
Conservation en tant que champ de métadonnées personnalisé dans les objets Cloud Storage de destination, que vous pouvez modifier ultérieurement ou supprimer. |
Taille de l'objet |
Conservation en tant que size
|
Génération d'objets |
Conservation en tant que champ de métadonnées personnalisé avec la clé x-goog-reserved-source-generation , que vous pouvez modifier ultérieurement ou supprimer.
|
Obligations de conservation d'objets |
Les préservations basées sur des événements ne sont pas conservées. Si la propriété par défaut de préservation basée sur des événements est activée sur le bucket de destination, une préservation basée sur des événements est appliquée aux objets transférés. Les préservations temporaires sont conservées par défaut. Pour supprimer les préservations temporaires pendant le transfert, définissez le champ |
Listes de contrôle d'accès (LCA) |
Vous pouvez éventuellement conserver les LCA. Pour plus d'informations, consultez la documentation de référence de metadataOptions. Lorsque vous conservez les LCA, veillez à éviter de créer des objets inaccessibles. Pour plus d'informations, consultez la documentation sur les listes de contrôle d'accès Cloud Storage. |
Classe de stockage |
Il existe plusieurs options pour définir la classe de stockage lors d'un transfert.
Pour plus d'informations, consultez la documentation de référence de metadataOptions. |
Clé de chiffrement gérée par le client |
Si une clé de chiffrement gérée par le client (CMEK) est utilisée sur un objet, cet objet peut éventuellement utiliser la même clé lorsqu'elle est écrite dans le bucket de destination. Le comportement par défaut consiste à écrire l'objet dans le bucket de destination à l'aide de sa méthode de chiffrement. Lorsque vous conservez la clé CMEK d'origine, tenez compte des limites suivantes:
Pour plus d'informations, consultez la documentation de référence de metadataOptions. |
Métadonnées de code temporel |
Vous pouvez éventuellement conserver le paramètre
Les métadonnées |
Autres métadonnées Cloud Storage non modifiables, telles que etag et componentCount .
|
Aucune conservation |
Pour obtenir la liste des métadonnées dans Cloud Storage, consultez la page Objets.
Transfert de listes d'URL vers Cloud Storage
Pour en savoir plus sur les listes d'URL, consultez la page Créer une liste d'URL.
Exemple de métadonnées | Comportement de conservation |
---|---|
Champs de métadonnées à clé fixe, tels que : Cache-Control , Content-Disposition et Content-Type
|
Conservation en tant que métadonnées modifiables |
Content-Length et MD5 |
Conservation en tant que métadonnées non modifiables
Si la source ne spécifie pas de valeur de hachage
Ce comportement de conservation est spécifique à |
Métadonnées d'horodatage, telles que l'heure de création, l'heure de modification et d'autres métadonnées spécifiques à la source. |
Aucune conservation
Les métadonnées d'horodatage de la source ne sont pas conservées. L'heure de création, |
Classe de stockage |
Il existe plusieurs options pour définir la classe de stockage lors d'un transfert.
Pour plus d'informations, consultez la documentation de référence de metadataOptions. |
Transferts à partir de systèmes de fichiers POSIX
Lors du transfert de fichiers à partir de systèmes de fichiers POSIX, le service de transfert de stockage peut éventuellement conserver certains attributs en tant que métadonnées personnalisées. Si ces fichiers sont réécrits ultérieurement sur un système de fichiers, le service de transfert de stockage peut reconvertir les métadonnées conservées en attributs POSIX.
Exemple de métadonnées | Comportement de conservation |
---|---|
Heure de modification (mtime )
|
Conservation
|
Taille du fichier |
Conservation La taille du fichier est conservée au format |
UID numérique GID numérique MODE numérique Liens symboliques |
Facultatif. Le comportement de conservation est spécifié avec l'objet Le comportement par défaut consiste à ne conserver aucune métadonnée. |
Métadonnées de dossier | Les métadonnées au niveau du dossier ne sont conservées que pour les transferts entre
systèmes. Les paramètres de conservation de l'UID, du GID et du MODE du transfert s'appliquent aux fichiers et aux dossiers pour ces transferts.
Les métadonnées de dossier ne sont pas conservées pour transferts de fichiers manifestes. |
Classe de stockage |
Il existe plusieurs options pour définir la classe de stockage lors d'un transfert.
Pour plus d'informations, consultez la documentation de référence de metadataOptions. |
Conserver les métadonnées POSIX facultatives
Pour conserver un ou plusieurs UID numériques, GID numériques, MODE numériques et liens symboliques, spécifiez l'objet metadataOptions
dans le corps de la tâche de transfert.
Ces options s'appliquent aux transferts POSIX vers Cloud Storage et aux transferts Cloud Storage vers POSIX. Dans ce dernier cas, les métadonnées doivent avoir été conservées lors du transfert initial des fichiers vers 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 vers Cloud Storage
Les métadonnées conservées sont stockées dans Cloud Storage sous forme de paires clé/valeur de métadonnées personnalisées.
- Le GID numérique est stocké sous la forme
goog-reserved-posix-gid
. - L'UID numérique est stocké sous la forme
goog-reserved-posix-uid
. - Le MODE numérique est stocké sous la forme
goog-reserved-posix-mode
.
Pour les liens symboliques, le service de transfert de stockage conserve le lien cible en tant qu'objet dans Cloud Storage avec les qualités suivantes:
- La clé d'objet est composée du préfixe de destination et du chemin d'accès au lien symbolique (associé à
root_directory
). - Métadonnées d'objets :
- Toutes les métadonnées du lien symbolique sont conservées en tant que métadonnées d'objets Cloud Storage.
- Une entrée de métadonnées personnalisées est créée :
goog-reserved-file-is-symlink:true
.
- Le contenu de l'objet est la cible du lien symbolique. Par exemple, pour un lien symbolique
sym-> dir1/target
, le contenu de l'objet est "dir1/target".
Le service de transfert de stockage ne valide pas le lien et ne copie pas le fichier cible.
Cloud Storage vers POSIX
Si les métadonnées sont conservées lorsque des fichiers sont transférés vers Cloud Storage, elles peuvent être réécrites dans les fichiers lorsqu'elles sont retransférées vers un système de fichiers POSIX.
Si une option de métadonnées est définie sur la conservation, le service de transfert de stockage effectue les actions suivantes:
- Liens symboliques: le service de transfert de stockage crée un fichier de lien symbolique pointant vers le lien cible. Si le fichier cible n'existe pas, le lien symbolique sera cassé.
- GID, UID et MODE : les valeurs stockées dans les métadonnées Cloud Storage sont réécrites dans le fichier.
POSIX vers POSIX
Les transferts entre systèmes de fichiers peuvent éventuellement conserver le GID, l'UID et le MODE pour des fichiers et des dossiers.
L'heure de la dernière modification est enregistrée pour les fichiers, mais pas pour les dossiers. mtime
est défini sur l'heure de création du dossier sur le système de fichiers de destination.
Le service de transfert de stockage enregistre les métadonnées de dossier en créant des objets de dossier de 0 octet dans le bucket intermédiaire, puis en les copiant à nouveau dans le dossier du système de fichiers de destination. C'est pourquoi le nombre d'objets créés dans le le bucket intermédiaire peut être supérieur au nombre de fichiers transférées.