Introduction
Un fichier de rapport a été supprimé et votre équipe doit le récupérer depuis une sauvegarde testée. Vous préparerez des données fictives, prendrez un instantané EBS, supprimerez volontairement le fichier de l'exercice et restaurerez son contenu antérieur sur un nouveau volume. Vous vérifierez la réponse récupérée de l'application avant le nettoyage.
Vous devez déjà savoir créer, attacher, formater et monter un volume de données EBS. Cet environnement indépendant fournit sa propre image, son réseau et sa paire de clés ; il ne réutilise aucune ressource d'un laboratoire précédent.
Lien avec la certification
La sauvegarde et la restauration par instantanés soutiennent les notions de stockage de la tâche 3.6 des objectifs du domaine 3 AWS Certified Cloud Practitioner CLF-C02.
Lancez le serveur de récupération
Dans cette étape, vous lancerez l'instance d'application et identifierez sa zone de disponibilité.
Commencez dans votre espace de travail et chargez les identifiants de ressources fournis :
cd /home/labex/project
source launch.env
Lancez une instance nommée recovery-server. L'image contient déjà une application de rapports ; vous lui fournirez son volume de données :
aws ec2 \
run-instances \
--image-id "$AMI_ID" \
--instance-type t3.micro \
--subnet-id "$SUBNET_ID" \
--security-group-ids "$SECURITY_GROUP_ID" \
--key-name report-key \
--count 1 \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=recovery-server}]'
Récupérez l'identifiant de l'instance à partir de son étiquette de nom :
INSTANCE_ID=$(aws ec2 \
describe-instances \
--filters Name=tag:Name,Values=recovery-server \
--query 'Reservations[0].Instances[0].InstanceId' \
--output text)
Attendez que l'instance soit en cours d'exécution :
aws ec2 \
wait instance-running \
--instance-ids "$INSTANCE_ID"
Une zone de disponibilité est un emplacement isolé dans une région. Un volume EBS s'attache à une instance située dans la même zone de disponibilité. Consultez la zone de l'instance au lieu de la deviner :
AVAILABILITY_ZONE=$(aws ec2 \
describe-instances \
--instance-ids "$INSTANCE_ID" \
--query 'Reservations[0].Instances[0].Placement.AvailabilityZone' \
--output text)
Inspectez l'état et la zone :
aws ec2 \
describe-instances \
--instance-ids "$INSTANCE_ID" \
--query 'Reservations[].Instances[].{Instance:InstanceId,State:State.Name,Zone:Placement.AvailabilityZone}'
Confirmez running. Ouvrez AWS View, cliquez sur Refresh resources, sélectionnez recovery-server et cliquez sur Check application. Confirmez HTTP 200 avant d'ajouter le stockage.
Préparez le rapport source
Dans cette étape, vous créerez un volume de données original et écrirez le rapport fictif à sauvegarder.
Amazon EBS fournit le stockage par blocs pour EC2. Un volume est une ressource semblable à un disque, tandis qu'un système de fichiers organise les fichiers sur ce disque. Attacher un volume rend son périphérique de blocs disponible ; cela ne crée pas de système de fichiers. Le guide des volumes EBS décrit leur attachement et leur persistance.
Créez un petit volume SSD à usage général vide. gp3 sélectionne le type de volume, --size 1 demande un GiB et la variable de zone le place dans la même zone que l'instance. Conservez son identifiant pour les opérations suivantes :
VOLUME_ID=$(aws ec2 \
create-volume \
--availability-zone "$AVAILABILITY_ZONE" \
--size 1 \
--volume-type gp3 \
--tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=source-report}]' \
--query 'VolumeId' \
--output text)
Attendez que le nouveau volume soit disponible :
aws ec2 \
wait volume-available \
--volume-ids "$VOLUME_ID"
Attachez-le avec le nom de périphérique de l'API /dev/sdf :
aws ec2 \
attach-volume \
--volume-id "$VOLUME_ID" \
--instance-id "$INSTANCE_ID" \
--device /dev/sdf
Attendez la fin de l'attachement :
aws ec2 \
wait volume-in-use \
--volume-ids "$VOLUME_ID"
Inspectez le volume et son attachement :
aws ec2 \
describe-volumes \
--volume-ids "$VOLUME_ID" \
--query 'Volumes[].{Volume:VolumeId,State:State,Zone:AvailabilityZone,Size:Size,Type:VolumeType,Attachments:Attachments}'
Confirmez in-use, la taille 1, le type gp3 et un attachement à votre instance. Actualisez AWS View et inspectez la ligne du volume. Le volume racine est distinct du nouveau volume de données.
Récupérez l'adresse publique actuelle de l'instance :
PUBLIC_IP=$(aws ec2 \
describe-instances \
--instance-ids "$INSTANCE_ID" \
--query 'Reservations[0].Instances[0].PublicIpAddress' \
--output text)
Connectez-vous avec la configuration SSH fournie :
ssh -F ssh_config ubuntu@"$PUBLIC_IP"
Dans l'instance, inspectez le périphérique nouvellement attaché. Son nom Linux dans ce laboratoire est /dev/xvdf ; les noms de périphériques peuvent différer du nom d'attachement de l'API. D'autres images EC2 peuvent présenter des noms NVMe : identifiez donc le disque avant toute opération. Le guide officiel de préparation des volumes Linux explique cette distinction.
lsblk -f /dev/xvdf
Confirmez que le périphérique n'a pas de type de système de fichiers. Créez un système de fichiers ext4 uniquement sur ce volume de données neuf et vide. Formater un volume contenant des données les effacerait :
sudo mkfs.ext4 /dev/xvdf
Un point de montage est le répertoire par lequel vous accédez à un système de fichiers. Montez le nouveau système de fichiers dans le répertoire préparé pour l'application de rapports :
sudo mount /dev/xvdf /srv/reports
Confirmez le périphérique source, le système de fichiers et le point de montage :
findmnt /srv/reports
Recherchez /dev/xvdf, ext4 et /srv/reports. Créez un rapport CSV contenant des données fictives. sudo tee écrit dans le système de fichiers appartenant à l'administrateur ; le here-document dont le délimiteur est entre guillemets conserve les deux lignes :
sudo tee /srv/reports/report.csv <<'CSV'
period,total
Q1,320
CSV
Relisez le fichier :
cat /srv/reports/report.csv
Revenez au terminal LabEx :
exit
Dans AWS View, sélectionnez recovery-server et cliquez sur Read volume report. Confirmez HTTP 200 et le texte CSV period,total et Q1,320. Cette réponse démontre que l'application peut lire le fichier sur le volume monté.
Le montage de ce laboratoire est manuel. Un redémarrage ne rétablit pas automatiquement un montage manuel ; en production, on configure généralement l'UUID du système de fichiers dans /etc/fstab après avoir testé l'entrée.
Prenez un instantané cohérent
Dans cette étape, vous suspendrez l'accès au système de fichiers et sauvegarderez le volume source.
Un instantané EBS est une sauvegarde d'un volume à un instant donné. Une sauvegarde doit contenir les données nécessaires, pas seulement afficher un état de ressource réussi. AWS recommande de suspendre les écritures ou de démonter le volume pour assurer la cohérence, comme l'indique le guide de création d'instantanés. Ce laboratoire démonte le système de fichiers de données avant sa sauvegarde.
Connectez-vous à l'instance :
ssh -F ssh_config ubuntu@"$PUBLIC_IP"
Démontez le système de fichiers source pour vider les écritures en attente et arrêter l'accès au système de fichiers :
sudo umount /srv/reports
Revenez au terminal LabEx :
exit
Créez un instantané de votre volume source. Conservez son identifiant et donnez-lui l'étiquette report-backup :
SNAPSHOT_ID=$(aws ec2 \
create-snapshot \
--volume-id "$VOLUME_ID" \
--description 'Report before accidental deletion' \
--tag-specifications 'ResourceType=snapshot,Tags=[{Key=Name,Value=report-backup}]' \
--query 'SnapshotId' \
--output text)
La création d'instantanés est asynchrone. Attendez qu'elle soit terminée :
aws ec2 \
wait snapshot-completed \
--snapshot-ids "$SNAPSHOT_ID"
Inspectez son état et son volume source :
aws ec2 \
describe-snapshots \
--snapshot-ids "$SNAPSHOT_ID" \
--query 'Snapshots[].{Snapshot:SnapshotId,State:State,SourceVolume:VolumeId}'
Confirmez completed et le volume source attendu. Actualisez AWS View pour inspecter l'instantané. Vous testerez son contenu en le restaurant après une suppression volontaire de fichier.
Observez une suppression accidentelle de fichier
Dans cette étape, vous supprimerez le rapport fictif du volume source et observerez l'absence du rapport dans l'application.
Reconnectez-vous et remontez le volume original :
ssh -F ssh_config ubuntu@"$PUBLIC_IP"
sudo mount /dev/xvdf /srv/reports
Supprimez uniquement le fichier fictif créé pour cet exercice :
sudo rm /srv/reports/report.csv
Revenez au terminal LabEx :
exit
Dans AWS View, sélectionnez recovery-server et cliquez sur Read volume report. La requête doit toujours renvoyer HTTP 200, mais report vaut maintenant null. L'application fonctionne ; le fichier nécessaire est absent. Cela distingue un problème de contenu du stockage d'un serveur arrêté.
Votre instantané a été créé avant cette suppression. Il peut fournir un nouveau volume contenant le rapport antérieur sans modifier le volume original.
Restaurez un nouveau volume depuis l'instantané
Dans cette étape, vous restaurerez la sauvegarde sur un volume distinct et basculerez l'application vers le système de fichiers récupéré.
La restauration crée un nouveau volume ; elle n'annule pas les modifications du volume existant. Créez le remplacement dans la zone de disponibilité de l'instance à partir de votre instantané terminé. Le guide officiel de restauration décrit ce processus de remplacement :
RESTORED_VOLUME_ID=$(aws ec2 \
create-volume \
--availability-zone "$AVAILABILITY_ZONE" \
--snapshot-id "$SNAPSHOT_ID" \
--volume-type gp3 \
--tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=recovered-report}]' \
--query 'VolumeId' \
--output text)
Attendez qu'il soit prêt :
aws ec2 \
wait volume-available \
--volume-ids "$RESTORED_VOLUME_ID"
Attachez-le comme deuxième périphérique de données :
aws ec2 \
attach-volume \
--volume-id "$RESTORED_VOLUME_ID" \
--instance-id "$INSTANCE_ID" \
--device /dev/sdg
aws ec2 \
wait volume-in-use \
--volume-ids "$RESTORED_VOLUME_ID"
Inspectez la relation du volume de remplacement avec l'instantané :
aws ec2 \
describe-volumes \
--volume-ids "$RESTORED_VOLUME_ID" \
--query 'Volumes[].{Volume:VolumeId,State:State,Snapshot:SnapshotId}'
Confirmez in-use et l'identifiant d'instantané enregistré. Connectez-vous pour changer le montage de l'application :
ssh -F ssh_config ubuntu@"$PUBLIC_IP"
Démontez le système de fichiers original :
sudo umount /srv/reports
Inspectez le périphérique récupéré, présenté comme /dev/xvdg dans ce laboratoire :
sudo lsblk -f /dev/xvdg
Il contient déjà un système de fichiers ext4 copié depuis la sauvegarde. Ne formatez pas ce périphérique : le formatage écraserait les données restaurées. Montez son système de fichiers existant dans le répertoire de rapports de l'application :
sudo mount /dev/xvdg /srv/reports
Confirmez la source active :
findmnt /srv/reports
Recherchez /dev/xvdg. Lisez le rapport récupéré :
cat /srv/reports/report.csv
Les deux lignes originales attendues sont period,total et Q1,320. Revenez au terminal LabEx :
exit
Dans AWS View, cliquez sur Refresh resources, sélectionnez recovery-server et cliquez sur Read volume report. Confirmez HTTP 200 et le texte CSV original. Un test de restauration réussi prouve que cette sauvegarde contient des données utilisables par l'application.
Supprimez les ressources de récupération
Dans cette étape, vous nettoierez les deux volumes de données, l'instantané et l'instance.
Connectez-vous et démontez le système de fichiers récupéré :
ssh -F ssh_config ubuntu@"$PUBLIC_IP"
sudo umount /srv/reports
exit
Détachez le volume récupéré :
aws ec2 \
detach-volume \
--volume-id "$RESTORED_VOLUME_ID" \
--instance-id "$INSTANCE_ID" \
--device /dev/sdg
aws ec2 \
wait volume-available \
--volume-ids "$RESTORED_VOLUME_ID"
Le système de fichiers source a été démonté lors de la restauration. Détachez aussi son volume :
aws ec2 \
detach-volume \
--volume-id "$VOLUME_ID" \
--instance-id "$INSTANCE_ID" \
--device /dev/sdf
aws ec2 \
wait volume-available \
--volume-ids "$VOLUME_ID"
Supprimez les deux volumes détachés de l'exercice :
aws ec2 \
delete-volume \
--volume-id "$RESTORED_VOLUME_ID"
aws ec2 \
delete-volume \
--volume-id "$VOLUME_ID"
Supprimez la sauvegarde de l'exercice après son test de restauration :
aws ec2 \
delete-snapshot \
--snapshot-id "$SNAPSHOT_ID"
Terminez votre serveur et attendez son état final :
aws ec2 \
terminate-instances \
--instance-ids "$INSTANCE_ID"
aws ec2 \
wait instance-terminated \
--instance-ids "$INSTANCE_ID"
Confirmez que l'instance est terminée :
aws ec2 \
describe-instances \
--instance-ids "$INSTANCE_ID" \
--query 'Reservations[].Instances[].{Instance:InstanceId,State:State.Name}'
Listez les volumes et la sauvegarde de l'exercice par leurs noms :
aws ec2 \
describe-volumes \
--filters Name=tag:Name,Values=source-report,recovered-report \
--query 'Volumes[].VolumeId'
aws ec2 \
describe-snapshots \
--filters Name=tag:Name,Values=report-backup \
--query 'Snapshots[].SnapshotId'
Les deux listes doivent être []. Actualisez AWS View et confirmez que les volumes et l'instantané de l'exercice ont disparu et que le serveur n'est plus une cible en cours d'exécution. Conservez le réseau et la paire de clés préparés.
Résumé
Vous avez sauvegardé un volume de rapports avec un instantané EBS, observé l'effet de la suppression d'un fichier et restauré un volume distinct depuis la sauvegarde. Vous avez monté le système de fichiers récupéré existant sans le formater et vérifié les données originales de l'application. Enfin, vous avez supprimé les deux volumes de données, l'instantané et l'instance.
