Cette page a été traduite par l'API Cloud Translation.

Conservation des métadonnées

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, la classe de stockage de l'objet dans le 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 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 manifest.

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.

Amazon S3 ou stockage compatible avec 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, `timeCreated`, correspond à l'heure de création d'un objet dans Cloud Storage. De même, `updated` indique le moment de modification des métadonnées d'un objet dans Cloud Storage.
Classe de stockage	Il existe plusieurs options pour définir la classe de stockage lors d'un transfert. Définissez la classe de stockage de chaque objet sur celle du bucket de destination. Il s'agit du comportement par défaut. Définissez une classe de stockage spécifique sur tous les objets en cours de 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, `timeCreated`, correspond à l'heure de création d'un objet dans Cloud Storage. De même, `updated` indique le moment de modification des métadonnées d'un objet dans Cloud Storage.
Classe de stockage	Il existe plusieurs options pour définir la classe de stockage lors d'un transfert. Définissez la classe de stockage de chaque objet sur celle du bucket de destination. Il s'agit du comportement par défaut. Définissez une classe de stockage spécifique sur tous les objets en cours de 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 `Cache-Control`, `Content-Disposition` et `Content-Type` Pour en savoir plus, consultez l'article Métadonnées des objets.	Conservation en tant que métadonnées à clé fixe
Métadonnées définies par l'utilisateur Cloud Storage, 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 `temporaryHold` de l'objet metadataOptions sur `TEMPORARY_HOLD_SKIP`.
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. Définissez la classe de stockage de chaque objet sur celle du bucket de destination. Il s'agit du comportement par défaut. Conservez la classe de stockage de l'objet source. Définissez une classe de stockage spécifique sur tous les objets en cours de 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: Le bucket de destination doit se trouver au même emplacement que la clé CMEK. Si le bucket de destination se trouve dans un autre projet, vous devez ajouter le compte de service Cloud Storage du projet de destination à la clé. 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 `timeCreated`. La valeur préservée est stockée dans le champ `customTime` de l'objet transféré dans Cloud Storage. Pour plus d'informations, consultez la documentation de référence de metadataOptions. Les métadonnées `updated` ne sont pas conservé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 `MD5`, nous ne conservons aucune valeur. Ce comportement de conservation est spécifique à `Content-Length` et `MD5`. Toute autre métadonnée non modifiable non répertoriée n'est pas conservée.
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, `timeCreated`, correspond à l'heure de création d'un objet dans Cloud Storage. De même, `updated` indique le moment de modification des métadonnées d'un objet dans Cloud Storage.
Classe de stockage	Il existe plusieurs options pour définir la classe de stockage lors d'un transfert. Définissez la classe de stockage de chaque objet sur celle du bucket de destination. Il s'agit du comportement par défaut. Définissez une classe de stockage spécifique sur tous les objets en cours de 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 `mtime` est conservé en tant que métadonnées personnalisées avec la clé `goog-reserved-file-mtime`.
Taille du fichier	Conservation La taille du fichier est conservée au format `size`.
UID numérique GID numérique MODE numérique Liens symboliques	Facultatif. Le comportement de conservation est spécifié avec l'objet `metadataOptions`. Pour plus d'informations, consultez la section Conserver les métadonnées POSIX facultatives. 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 de fichiers. 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. `mtime` n'est pas conservé pour les dossiers. `mtime` est défini sur l'heure de création du dossier sur le système de fichiers de destination. Les métadonnées des dossiers ne sont pas conservées pour les transferts de fichiers manifestes.
Classe de stockage	Il existe plusieurs options pour définir la classe de stockage lors d'un transfert. Définissez la classe de stockage de chaque objet sur celle du bucket de destination. Il s'agit du comportement par défaut. Définissez une classe de stockage spécifique sur tous les objets en cours de 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 les fichiers et les 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 bucket intermédiaire peut être supérieur au nombre de fichiers transférés.