Gestion des versions des objets

Accéder aux exemples

Pour permettre la récupération des objets supprimés ou remplacé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.

Présentation

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

  • Cloud Storage conserve une version d'objet archivée chaque fois que vous remplacez ou supprimez une version d'objet active, tant que vous ne spécifiez pas le numéro de génération de la version active.

    • 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 à les inclure.

  • 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.

Si vous désactivez la gestion des versions d'objets :

  • Le bucket n'accumule plus de nouvelles versions archivées des objets.

  • Les versions d'objet qui existent déjà dans le bucket ne sont pas affectées.

Remarques

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

  • Il n'y a pas de limite par défaut au nombre de versions d'objet que vous pouvez posséder. Chaque version obsolète d'un objet est facturée au même tarif que sa version active.

    • Des frais de suppression anticipée ne s'appliquent que lorsqu'une version d'objet est supprimée du bucket, et non lorsque la version devient obsolète. La durée de stockage d'une version supprimée d'un bucket est basée sur l'heure à laquelle elle a été ajoutée, et non sur l'heure à laquelle elle est devenue obsolète.

    • Si vous activez la gestion des versions, pensez à utiliser la fonctionnalité de gestion du cycle de vie des objets, qui supprime les anciennes versions d'un objet après un certain temps ou lorsque des versions plus récentes sont archivées. Pour connaître une configuration possible, consultez l'exemple de configuration du cycle de vie pour la suppression d'objets.

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 remplacez, 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 créer une copie de l'une des versions archivées existantes, ce qui permet de restaurer la version. 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 restauration.

Tableau de référence de la gestion des versions d'objets

Ce tableau de référence indique ce qui se produit lorsque vous effectuez certaines actions de gestion des versions d'objets.

État de la gestion des versions d'objets Action Résultat
Désactivé
Remplacez dog.png par une nouvelle version. La nouvelle version remplace la version active et reçoit un nouveau numéro de génération. L'ancienne version active est définitivement supprimée.
Remplacer une version archivée dog.png par une version active1 Une copie de la version archivée remplace la version active et reçoit un nouveau numéro de génération. L'ancienne version active est définitivement supprimée.
Supprimer dog.png dog.png est définitivement supprimé.
Supprimer une version archivée de dog.png en spécifiant son numéro de génération1 La version archivée est définitivement supprimée.
Activé
Remplacez dog.png par une nouvelle version. La nouvelle version remplace la version active et reçoit un nouveau numéro de génération. L'ancienne version active est archivée et conserve le même numéro de génération.
Remplacer une version archivée de dog.png par une version active Une copie de la version archivée remplace la version active et reçoit un nouveau numéro de génération. L'ancienne version active est archivée et conserve le même numéro de génération.
Supprimer la version active de dog.png sans spécifier son numéro de génération La version active est archivée et conserve le même numéro de génération.
Supprimer la version active de dog.png en spécifiant son numéro de génération La version active est définitivement supprimée.
Supprimer une version archivée de dog.png en spécifiant son numéro de génération La version archivée est définitivement supprimée.

1 Une version archivée peut exister si la gestion des versions d'objets a été activée pour ce bucket.

Astuces

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, consultez l'onglet "gsutil" de la page Utiliser des objets avec des versions gérées.

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 restaurer une version d'objet archivée dans la version active actuelle. Pour obtenir des instructions détaillées à ce sujet, consultez la section Restaurer des versions d'objet archivées.

    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 la remplace, mais la conserve également en tant que nouvelle version archivée. Dans ce cas, votre bucket contient 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), toutes ces versions entraînant des frais de stockage. Pour éviter des frais inutiles, [supprimez la version archivée]12] utilisée pour créer la copie active actuelle, ou configurez la gestion du cycle de vie des objets pour supprimer les objets archivés lorsqu'ils remplissent les conditions que vous avez spécifiées.

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 remplacent pas accidentellement.

  • Si vous définissez une condition préalable de correspondance de génération sur 0 lors de l'importation 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.

Étape suivante