Gestion des versions des objets

Pour permettre la récupération des objets supprimés ou écrasés, Cloud Storage propose la fonctionnalité de gestion des versions d'objets. Cette page décrit la fonctionnalité ainsi que les options disponibles lors de son utilisation. Consultez la page Utiliser la gestion des versions d'objets pour savoir comment activer et utiliser cette fonctionnalité.

Activez la gestion des versions d'objets pour éviter que vos données Cloud Storage ne soient accidentellement écrasées ou supprimées. L'activation de cette fonctionnalité augmente les coûts de stockage. Ceux-ci peuvent cependant être partiellement atténués en configurant la gestion du cycle de vie des objets qui supprime les anciennes versions de ces objets.

Présentation

Activez la gestion des versions d'objets pour un bucket. Une fois la fonctionnalité activée :

  • Cloud Storage crée une version archivée d'un objet à chaque fois que vous écrasez ou supprimez la version active, à condition de ne pas spécifier son numéro de génération.

    • Les versions archivées conservent le nom de l'objet, mais elles sont identifiées de manière unique par un numéro de génération.

    • Les versions archivées ne s'affichent que dans les requêtes qui appellent explicitement à inclure les versions d'objets.

  • Vous supprimez définitivement les versions des objets en incluant le numéro de génération dans la requête de suppression ou en configurant la gestion du cycle de vie des objets.

  • Les versions archivées des objets existent indépendamment des versions actives.

Vous pouvez activer ou désactiver à tout moment la gestion des versions pour un bucket. Si vous la désactivez, les versions existantes des objets sont conservées et le bucket cesse d'accumuler de nouvelles versions d'objets archivées.

Détails relatifs à la gestion des versions d'objets

Cloud Storage utilise deux propriétés pour identifier la version d'un objet. L'une d'elles identifie la version des données de l'objet, l'autre identifie la version des métadonnées de l'objet. Ces propriétés sont toujours présentes avec chaque version de l'objet, même si la fonctionnalité de gestion des versions d'objets n'est pas activée. Elles peuvent être utilisées comme conditions préalables pour les mises à jour conditionnelles afin de faire respecter le classement des mises à jour.

Cloud Storage marque chaque objet à l'aide des propriétés suivantes :

Propriété Description
generation Identifie la génération de contenu (données) et se met à jour lorsque le contenu d'un objet est écrasé. Il n'y a pas de lien entre les numéros de génération d'objets non liés, même si ceux-ci se trouvent dans le même bucket.
metageneration Identifie la génération de métadonnées et augmente chaque fois que les métadonnées d'une génération de contenu donnée sont mises à jour. La propriété metageneration est réinitialisée à 1 pour chaque nouvelle génération (generation) d'objet. La propriété metageneration n'a aucun sens sans la propriété generation. Elles doivent toujours être utilisées ensemble. En d'autres termes, il est sans intérêt de comparer la génération de métadonnées de deux versions si leurs générations de données sont différentes.

La gestion des versions d'objets ne peut pas être activée sur un bucket qui possède actuellement une règle de conservation.

Métadonnées d'objet archivé

Les versions d'objets archivées ont leurs propres métadonnées, qui peuvent différer de celles des versions actives. Plus important encore, une version archivée conserve ses LCA et ne dispose pas nécessairement des mêmes autorisations que la version active.

Chaque version, qu'il s'agisse de l'objet actif ou archivé, possède un ensemble de métadonnées. Seul le dernier numéro de métagénération fait référence à des métadonnées. Les numéros plus anciens ne peuvent pas être utilisés pour accéder à des métadonnées qui ont été modifiées depuis.

Vous pouvez mettre à jour les métadonnées d'un objet archivé en spécifiant sa propriété generation dans votre requête. Pour garantir une sémantique sécurisée de lecture-modification-écriture, vous pouvez utiliser une condition préalable de correspondance de métagénération. L'utilisation de cette condition préalable entraîne l'échec de la mise à jour si les métadonnées que vous tentez de mettre à jour ont été modifiées entre le moment où vous les avez lues et l'envoi de la mise à jour.

Exemple de gestion des versions d'objets

Cet exemple montre ce qu'il advient du fichier cat.jpg dans un bucket sur lequel la fonctionnalité de gestion des versions d'objets est activée lorsque vous écrasez, mettez à jour et supprimez le fichier.

Téléchargez une nouvelle image

Lorsque vous importez le fichier cat.jpg pour la première fois dans Cloud Storage, il se voit attribuer un numéro de generation et un numéro de metageneration. Dans cet exemple, le numéro de génération est 1360887697105000. Comme l'objet est nouveau, le numéro de metageneration est 1.

Le fichier cat.jpg reçoit les numéros de generation et de metageneration même si la gestion des versions d'objets n'est pas activée. Vous pouvez afficher ces numéros à l'aide de la commande stat dans gsutil. Pour savoir comment procéder, consultez la section Afficher des métadonnées d'objets.

Activez la gestion des versions d'objets

À ce stade, vous décidez d'activer la gestion des versions d'objets pour votre bucket. Cela n'a pas d'incidence sur les numéros de generation ou de metageneration du fichier cat.jpg.

Modifiez les métadonnées de l'image

Mettez à jour les métadonnées du fichier cat.jpg en ajoutant des métadonnées personnalisées : color:black. La mise à jour des métadonnées provoque une augmentation de la valeur metageneration du fichier cat.jpg. Dans le cas présent, cette valeur passe de 1 à 2. Cependant, l'objet lui-même demeure inchangé. Cloud Storage continue donc à ne stocker qu'une seule version du fichier cat.jpg, et le numéro de generation de la version reste défini sur 1360887697105000.

Transférez une nouvelle version de l'image

Importez une nouvelle version du fichier cat.jpg dans votre bucket Cloud Storage. La gestion des versions d'objets va ainsi faire passer l'objet cat.jpg existant à un état archivé. La version archivée conserve la même classe de stockage et les mêmes métadonnées qu'auparavant. La version archivée ne s'affiche que si vous demandez une liste avec versions gérées. Elle n'apparaît pas dans les commandes de listes normales. La version archivée est désormais référencée comme suit : cat.jpg#1360887697105000.

Dans le même temps, le fichier cat.jpg que vous venez d'importer devient la version active de l'objet. Ce nouveau fichier cat.jpg obtient son propre numéro de generation, dans le présent exemple : 1360887759327000. Il obtient également ses propres métadonnées et un numéro de metageneration d'une valeur de 1, ce qui signifie qu'il ne contient pas la métadonnée color:black, sauf si vous la lui spécifiez. Il s'agit de la version utilisée lorsque vous accédez au fichier cat.jpg,, ou lorsque vous le modifiez. Vous pouvez également faire référence à cette version de cat.jpg à l'aide de son numéro de generation. Par exemple, si vous utilisez l'outil gsutil, vous ferez référence au fichier avec le numéro cat.jpg#1360887759327000.

Supprimez la version active de l'image

Vous souhaitez à présent supprimer le fichier cat.jpg. La version portant le numéro de génération 1360887759327000 est alors archivée. Votre bucket contient maintenant deux versions archivées du fichier cat.jpg et aucune version active. Vous pouvez toujours faire référence à l'une des versions archivées en utilisant son numéro de generation, mais si vous essayez d'accéder au fichier cat.jpg sans numéro de generation, votre requête échoue.

De même, une liste d'objets normale du bucket ne présentera pas le fichier cat.jpg comme l'un des objets du bucket. Pour découvrir comment répertorier les versions d'objets archivées, consultez la section Répertorier les versions d'objets archivées.

Désactivez la gestion des versions d'objets

La désactivation de la gestion des versions d'objets a pour but d'empêcher l'archivage des objets. Les versions archivées existantes des objets sont conservées dans Cloud Storage. Même si la gestion des versions d'objets est désactivée, les versions cat.jpg#1360887697105000 et cat.jpg#1360887759327000 restent stockées dans votre bucket jusqu'à ce que vous les supprimiez, soit manuellement, soit via la gestion du cycle de vie des objets.

Vous pouvez restaurer l'une des versions archivées.

Même si la gestion des versions d'objets est désactivée, vous pouvez restaurer l'une des versions archivées existantes en effectuant une copie de celle-ci. Pour ce faire, il vous suffit de nommer la copie cat.jpg. Une fois cette opération effectuée, votre bucket dispose de trois versions de cat.jpg : les deux versions archivées et la version active issue de la copie.

Conseils

Cette section présente des astuces pour vous aider à utiliser plus efficacement la fonctionnalité de gestion des versions d'objets.

Utiliser gsutil

  • L'outil gsutil offre une compatibilité complète avec les versions d'objets, ce qui facilite les tâches impliquant la fonctionnalité de gestion des versions d'objets. Par exemple, vous pouvez utiliser des versions archivées d'objets en ajoutant # ainsi que le numéro de generation au nom de l'objet. Pour plus d'informations sur l'utilisation de gsutil avec cette fonctionnalité, consultez la page Gestion des versions des objets et contrôle de simultanéité.

Eviter les ETag

  • Pensez à utiliser les numéros de generation et demetageneration pour les mises à jour conditionnelles plutôt que des ETag. La paire que constituent les numéros de generation et de metageneration permet de garder une trace de toutes les mises à jour d'objets, y compris les modifications de métadonnées, fournissant ainsi une garantie plus solide que celle des ETag.

Comprendre le comportement de restauration de fichiers

  • Vous pouvez copier une version d'objet archivée dans la version active actuelle. Reportez-vous à la section Copier des versions d'objets archivées pour obtenir des instructions détaillées sur cette fonctionnalité.

    Lorsque vous effectuez cette opération avec la gestion des versions d'objets activée, s'il existe déjà une version active de l'objet dans votre bucket, Cloud Storage l'écrase mais crée également une nouvelle version archivée correspondant à l'objet écrasé. Dans ce cas, votre bucket contient alors l'objet remplacé (à présent archivé) et deux copies de l'objet précédemment archivé (une copie active et une copie déjà archivée), qui entraînent toutes des frais de stockage. Pour éviter des frais inutiles, supprimez la version archivée que vous venez d'utiliser pour créer la copie active.

Utiliser les conditions préalables de correspondance de génération lors de la mutation de versions actives d'objets

  • Lorsque vous utilisez des numéros de génération, une demande aboutit tant qu'un objet portant ce nom et ce numéro de génération existe, qu'il soit actif ou archivé. Si aucun objet de ce type n'existe, Cloud Storage affiche l'erreur 404 Not Found.

  • Lorsque vous utilisez des conditions préalables de correspondance de génération, une demande aboutit uniquement si la version active de l'objet demandé possède le numéro de génération spécifié. Si aucun objet de ce type n'existe, ou s'il est archivé, Cloud Storage affiche l'erreur 412 Precondition Failed.

  • Vous devez éviter d'utiliser une condition préalable de correspondance de génération en même temps qu'un numéro de génération dans le nom de l'objet. Si vous utilisez les deux et que les numéros correspondent, l'utilisation de la condition préalable est redondante. Si les numéros ne correspondent pas, la requête va forcément échouer.

  • Si vous effectuez plusieurs requêtes de mutation simultanées avec une condition préalable de correspondance de génération, la cohérence forte de Cloud Storage ne permet la réussite que d'une seule requête. Cette fonctionnalité est utile si vos objets sont mis à jour à partir de plusieurs sources et que vous devez vous assurer que les utilisateurs ne les écrasent pas accidentellement.

  • Si vous définissez une condition préalable de correspondance de génération sur 0 lors du transfert d'un objet, Cloud Storage n'exécute la requête spécifiée que s'il n'existe pas de version active de l'objet. Par exemple, si vous exécutez une requête PUT avec l'API XML pour créer un objet comportant l'en-tête x-goog-if-generation-match:0, la requête aboutit si l'objet n'existe pas ou s'il n'existe que des versions archivées de cet objet. S'il existe une version active de l'objet, Cloud Storage annule la mise à jour en affichant le code d'état 412 Precondition Failed.