Introduction
Charger un brouillon vers la clé du rapport d'une équipe financière remplacerait le contenu approuvé que les lecteurs voient. Vous activerez la gestion des versions, reproduirez cette erreur, restaurerez le contenu approuvé et supprimerez l'historique d'entraînement après avoir vérifié la restauration.
Terminez d'abord Organisez les documents avec des clés et des métadonnées pour les clés d'objet, les propriétés, les téléchargements et le nettoyage. Cette nouvelle VM fournit la connexion CLI et les fichiers approuvé et brouillon ; vous créerez le compartiment. Utilisez Terminal pour les commandes et l'onglet AWS View, à côté, pour comparer les objets actuels à leur historique.
Lien avec les certifications
Ce laboratoire propose une pratique des sujets d’examen suivants.
- Solutions Architect – Associate (SAA-C03) · Tâche 1.3: Historique des versions S3, marqueurs de suppression et récupération des données.
- Developer – Associate (DVA-C02) · Tâche 1.3: Historique des versions S3, marqueurs de suppression et récupération des données.
- CloudOps Engineer – Associate (SOA-C03) · Tâche 2.3: Historique des versions S3, marqueurs de suppression et récupération des données.
- Security – Specialty (SCS-C03) · Tâche 5.2: Pratique des fondamentaux : Historique des versions S3, marqueurs de suppression et récupération des données.
- Data Engineer – Associate (DEA-C01) · Tâche 2.3: Pratique des fondamentaux : Historique des versions S3, marqueurs de suppression et récupération des données.
Activez la gestion des versions avant de publier
Dans cette étape, vous créerez un compartiment vide et activerez la gestion des versions avant tout chargement de rapport.
Rejoignez l'espace de travail avec cd (change directory, changer de répertoire) :
cd /home/labex/project
Créez le compartiment des rapports avec mb (make bucket) :
aws s3 mb s3://labex-report-history
Vous devriez voir make_bucket: labex-report-history. La gestion des versions est un paramètre du compartiment : une fois activée, les écritures suivantes vers une clé créent des identifiants de version au lieu d'abandonner son contenu stocké précédent. Elle permet de restaurer des écrasements accidentels, mais n'empêche pas quelqu'un de supprimer explicitement une version précise.
aws s3api expose les opérations individuelles de l'API S3. put-bucket-versioning met à jour ce paramètre ; --bucket identifie le conteneur et --versioning-configuration Status=Enabled demande son activation :
aws s3api put-bucket-versioning --bucket labex-report-history --versioning-configuration Status=Enabled
La mise à jour réussie n'affiche aucun contenu. Relisez la configuration plutôt que de vous fier uniquement à ce silence :
aws s3api get-bucket-versioning --bucket labex-report-history
{
"Status": "Enabled"
}
AWS View affiche maintenant Versioning: Enabled sur le compartiment. Il est toujours vide : activer la gestion des versions ne charge pas de rapport et ne crée pas de version historique. Activez ce paramètre avant d'écrire les données à protéger.
Créez une version originale et une version écrasée
Dans cette étape, vous publierez un rapport approuvé, puis écraserez son contenu actuel avec un brouillon, en conservant l'original dans l'historique.
Examinez les fichiers préparés avec cat, qui affiche leur contenu :
cat report-approved.txt
Monthly revenue: 42000
cat report-draft.txt
Monthly revenue: 00000
Publiez le fichier approuvé à la clé report.txt. Le nom du fichier source et la clé d'objet peuvent différer :
aws s3 cp report-approved.txt s3://labex-report-history/report.txt
Dans AWS View, ouvrez report.txt et confirmez le chiffre d'affaires approuvé. L'historique contient une version, marquée Current.
Reproduisez maintenant l'erreur : chargez le brouillon vers cette même clé :
aws s3 cp report-draft.txt s3://labex-report-history/report.txt
L'aperçu devient Monthly revenue: 00000. Il existe toujours une seule clé d'objet actuelle, mais son historique contient maintenant deux versions stockées. Les deux fichiers ont la même taille ; la gestion des versions suit les écritures plutôt que de déduire les changements uniquement de leur taille.
list-object-versions récupère les enregistrements historiques ainsi que la version actuelle :
aws s3api list-object-versions --bucket labex-report-history
Le tableau Versions contient deux entrées portant la clé report.txt avec des valeurs VersionId différentes. IsLatest: true identifie le brouillon comme version actuelle ; la version approuvée antérieure a IsLatest: false. Les identifiants et horodatages varient. Une liste ordinaire d'objets montre les clés actuelles ; utilisez donc la liste des versions pour examiner un écrasement.
Dans la Console S3 officielle, Show versions révèle ces entrées historiques dans la liste des objets. Cet exemple montre un autre objet et davantage d'écritures ; utilisez-le pour reconnaître la colonne Version ID. Aucune connexion à la Console n'est nécessaire pour ce laboratoire.
Source : AWS Storage Blog.
Récupérez et publiez la version approuvée
Dans cette étape, vous téléchargerez la version approuvée antérieure, vérifierez ses octets et rendrez à nouveau ce contenu actuel sans supprimer l'historique.
Il existe exactement deux versions de report.txt à ce stade. Dans la liste précédente, trouvez l'entrée avec IsLatest: false : c'est l'original approuvé. Copiez son VersionId.
Stockez cet identifiant dans une variable du shell pour le réutiliser. Remplacez PASTE_APPROVED_VERSION_ID ci-dessous par la valeur copiée, en gardant les guillemets. Une affectation de variable n'a pas d'espaces autour de = :
OLD_VERSION='PASTE_APPROVED_VERSION_ID'
Vérifiez la valeur avant de l'utiliser :
echo "$OLD_VERSION"
Vous devriez voir l'identifiant de la version antérieure plutôt que le texte de remplacement. $OLD_VERSION lit la variable ; les guillemets doubles gardent sa valeur comme un seul argument de commande.
get-object télécharge le contenu d'un objet vers le chemin local final. --version-id sélectionne la copie historique plutôt que le brouillon actuel :
aws s3api get-object --bucket labex-report-history --key report.txt --version-id "$OLD_VERSION" recovered-report.txt
La sortie JSON décrit la copie récupérée. Lisez son contenu :
cat recovered-report.txt
Monthly revenue: 42000
cmp compare les octets des fichiers. && exécute le message suivant uniquement si la comparaison réussit :
cmp report-approved.txt recovered-report.txt && echo 'Approved historical content verified'
Récupérer une ancienne version ne la rend pas actuelle ; les lecteurs de la clé sans identifiant de version reçoivent toujours le brouillon. Publiez les octets restaurés vers cette clé :
aws s3 cp recovered-report.txt s3://labex-report-history/report.txt
Cela crée une troisième version contenant le rapport approuvé. L'ancienne version approuvée et le brouillon restent tous deux disponibles pour l'examen. AWS View affiche le contenu approuvé comme actuel et trois enregistrements de version. Listez l'historique pour confirmer :
aws s3api list-object-versions --bucket labex-report-history
La nouvelle entrée a IsLatest: true. Vous avez restauré les données en écrivant une nouvelle version actuelle, plutôt qu'en effaçant les preuves de l'erreur.
Cet exemple montre le rapport restauré comme actuel et trois entrées historiques distinctes. Les identifiants de version affichés sont des exemples de cette session :
Rétablissez l'accès après un marqueur de suppression
Dans cette étape, vous observerez comment un marqueur de suppression masque un objet versionné, puis retirerez ce marqueur pour révéler la version actuelle précédente.
Schéma : la suppression ajoute un marqueur actuel tandis que les trois versions stockées du rapport restent présentes. Les libellés v1–v3 indiquent l'ordre des écritures, pas les véritables identifiants de version.
Dans un compartiment où la gestion des versions est activée, une demande de suppression sans identifiant de version crée un marqueur de suppression. C'est une entrée actuelle de l'historique indiquant que la clé est supprimée ; elle ne contient pas d'octets de fichier et n'efface pas les anciennes versions. Supprimez la clé actuelle avec la commande habituelle sur les fichiers :
aws s3 rm s3://labex-report-history/report.txt
Une liste ordinaire n'affiche maintenant aucun objet actuel :
aws s3 ls s3://labex-report-history/
Dans AWS View, l'objet actuel disparaît, tandis que trois lignes Version et un Delete marker actuel restent dans l'historique.
Essayez de télécharger la clé sans choisir de version :
aws s3 cp s3://labex-report-history/report.txt unavailable-report.txt
Cette commande doit échouer avec une erreur indiquant que l'objet est introuvable. Le marqueur de suppression actuel fait qu'une lecture ordinaire se comporte comme si l'objet était absent. Cela ne prouve pas que les octets historiques ont été effacés.
Lisez l'historique complet :
aws s3api list-object-versions --bucket labex-report-history
La réponse contient maintenant DeleteMarkers ainsi que Versions. Trouvez l'unique entrée de DeleteMarkers et copiez son VersionId. Cet identifiant désigne le marqueur, pas un rapport stocké.
Remplacez le texte de remplacement ci-dessous par cet identifiant de marqueur :
MARKER_VERSION='PASTE_DELETE_MARKER_ID'
Retirez ce marqueur précis avec delete-object. Fournir --version-id supprime l'entrée historique sélectionnée plutôt que de créer un autre marqueur :
aws s3api delete-object --bucket labex-report-history --key report.txt --version-id "$MARKER_VERSION"
La réponse identifie le marqueur supprimé. La version approuvée précédente redevient actuelle ; cette opération ne charge pas une autre version du rapport. Confirmez l'accès ordinaire en téléchargeant la clé :
aws s3 cp s3://labex-report-history/report.txt accessible-report.txt
cmp report-approved.txt accessible-report.txt && echo 'Current report accessible again'
La comparaison réussit. AWS View affiche à nouveau report.txt avec le contenu approuvé et trois versions. Retirer un marqueur rétablit l'accès ; supprimer définitivement une version de données effacerait au contraire cette copie précise.
Supprimez les versions historiques et le compartiment
Dans cette étape, vous supprimerez toutes les versions de données du laboratoire avant de supprimer le compartiment vide.
L'historique des versions consomme du stockage même lorsqu'une liste ordinaire d'objets est vide. Un simple aws s3 rm créerait un autre marqueur de suppression ; il ne suffit donc pas pour vider un compartiment versionné. Le marqueur de l'étape précédente a déjà été retiré ; les trois versions de données restent.
Listez l'historique avant le nettoyage définitif :
aws s3api list-object-versions --bucket labex-report-history
Vous devriez voir trois entrées dans Versions et aucun DeleteMarkers. Toutes les entrées appartiennent à cet exercice de rapport jetable.
Les trois entrées appartiennent à report.txt. Vous avez déjà utilisé delete-object --version-id pour retirer un marqueur ; la même opération peut supprimer définitivement une version de données.
Copiez un VersionId de la liste et remplacez le texte de remplacement ci-dessous. Exécutez cette commande une fois pour chacun des trois identifiants distincts. Une suppression définitive ne peut pas être annulée ; vérifiez donc le compartiment, la clé et l'identifiant à chaque fois :
aws s3api delete-object --bucket labex-report-history --key report.txt --version-id 'PASTE_VERSION_ID'
Une réponse réussie identifie la version supprimée. Un identifiant de version sélectionne une copie historique ; il ne supprime pas toutes les versions de la clé. Après avoir retiré les trois, confirmez qu'il ne reste ni versions ni marqueurs :
aws s3api list-object-versions --bucket labex-report-history
La réponse réussie ne contient aucune entrée Versions ou DeleteMarkers. Supprimez maintenant le compartiment vide avec rb :
aws s3 rb s3://labex-report-history
La sortie est remove_bucket: labex-report-history. Confirmez que le stockage répond toujours :
aws s3 ls
Aucun compartiment ne reste, et AWS View affiche No buckets. Les fichiers de rapports locaux restent disponibles ; seules les ressources S3 du laboratoire et leur historique ont été supprimés.
Résumé
Vous avez activé la gestion des versions du compartiment avant de publier, distingué une clé actuelle de ses identifiants de version historiques et restauré un rapport écrasé en récupérant une ancienne version puis en publiant ses octets vérifiés. Vous avez ensuite créé et retiré un marqueur de suppression pour rétablir l'accès ordinaire sans charger une autre version.
La gestion des versions conserve l'historique ; elle ne rend pas réversible une suppression explicite de version. Vous avez terminé en examinant et en supprimant définitivement toutes les versions du laboratoire, en confirmant l'absence de marqueurs et en supprimant le compartiment vide.
