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 la version active de l'objet est écrasée ou supprimée. La version archivée conserve le nom de l'objet, mais elle est identifiée de manière unique par un numéro de génération. Bien que tous les objets portent des numéros de génération, seuls les objets archivés en ont besoin pour être identifiés.

Lorsque la gestion des versions d'objets est activée, vous pouvez répertorier les versions archivées d'un objet, restaurer la version active de l'objet à un état antérieur ou supprimer définitivement une version archivée, si nécessaire. 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.

Attention : Il est impossible de récupérer des versions archivées d'objets à partir de buckets supprimés.

Important : Si vous modifiez la configuration de la gestion des versions pour un bucket, sa propagation peut prendre un certain temps. Il est alors possible que les suppressions ou écrasements d'objets dans le bucket continuent à se comporter selon le paramètre précédent pendant un court laps de temps. Pour vous assurer que les suppressions et les écrasements d'objets se comportent conformément à votre modification, attendez au moins 30 secondes entre la modification de la configuration et la suppression ou l'écrasement d'objets.

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 :

Property (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.

Attention : Il n'y a pas de limite par défaut au nombre de versions d'objets que vous pouvez créer. Chaque version archivée d'un objet est facturée au même taux que la version active de l'objet. Si vous activez la gestion des versions, pensez à utiliser la fonctionnalité de gestion du cycle de vie des objets, qui supprime les versions les plus anciennes d'un objet lorsque les plus récentes sont archivées.

Métadonnées d'objet archivé

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

Chaque objet, qu'il s'agisse de l'objet actif ou d'une version gérée, 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 savoir comment répertorier les versions archivées des objets, consultez la section Répertorier les versions d'objet 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 ultérieur 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.

Restaurez une version archivée

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 suppression et de restauration de fichier

• 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 la remplace mais crée également une nouvelle version archivée correspondant à l'objet remplacé. 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.

• Si vous envoyez une demande de suppression sans spécifier de génération, Cloud Storage archive l'objet actif actuel. Celui-ci est alors considéré comme manquant lors de requêtes ultérieures sans version.

• Si vous envoyez une demande de suppression avec un numéro de generation correspondant à l'objet actuellement actif, Cloud Storage supprime l'objet sans créer de copie archivée.

• Lorsque vous supprimez un objet archivé, Cloud Storage supprime définitivement cette version de l'objet.

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