Einführung
Eine Berichtsdatei wurde gelöscht und dein Team muss sie aus einem getesteten Backup wiederherstellen. Du bereitest synthetische Berichtsdaten vor, erstellst einen EBS-Snapshot, löschst absichtlich die Übungsdatei und stellst ihren früheren Inhalt auf einem neuen Volume wieder her. Vor der Bereinigung prüfst du die wiederhergestellte Antwort der Anwendung.
Du solltest bereits wissen, wie du ein EBS-Datenvolume erstellst, verbindest, formatierst und mountest. Diese unabhängige Umgebung stellt ihr eigenes Image, Netzwerk und Schlüsselpaar bereit und verwendet keine Ressourcen aus einem früheren Lab.
Bezug zur Zertifizierung
Backup und Wiederherstellung mit Snapshots unterstützen die Speicherkonzepte in Aufgabe 3.6 der Lernziele von Domain 3 für AWS Certified Cloud Practitioner CLF-C02.
Starte den Wiederherstellungsserver
In diesem Schritt startest du die Anwendungsinstance und ermittelst ihre Availability Zone.
Beginne in deinem Arbeitsverzeichnis und lade die bereitgestellten Ressourcen-IDs:
cd /home/labex/project
source launch.env
Starte eine Instance namens recovery-server. Das Image enthält bereits eine Berichtsanwendung; du stellst ihr das Datenvolume bereit:
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}]'
Ermittle die Instance-ID anhand ihres Namens-Tags:
INSTANCE_ID=$(aws ec2 \
describe-instances \
--filters Name=tag:Name,Values=recovery-server \
--query 'Reservations[0].Instances[0].InstanceId' \
--output text)
Warte, bis die Instance läuft:
aws ec2 \
wait instance-running \
--instance-ids "$INSTANCE_ID"
Eine Availability Zone ist ein isolierter Standort innerhalb einer Region. Ein EBS-Volume wird mit einer Instance in derselben Availability Zone verbunden. Frage die Zone der Instance ab, statt sie zu erraten:
AVAILABILITY_ZONE=$(aws ec2 \
describe-instances \
--instance-ids "$INSTANCE_ID" \
--query 'Reservations[0].Instances[0].Placement.AvailabilityZone' \
--output text)
Prüfe den Zustand und die Zone:
aws ec2 \
describe-instances \
--instance-ids "$INSTANCE_ID" \
--query 'Reservations[].Instances[].{Instance:InstanceId,State:State.Name,Zone:Placement.AvailabilityZone}'
Bestätige running. Öffne AWS View, klicke auf Refresh resources, wähle recovery-server und klicke auf Check application. Bestätige HTTP 200, bevor du Speicher hinzufügst.
Bereite den ursprünglichen Bericht vor
In diesem Schritt erstellst du ein ursprüngliches Datenvolume und schreibst den synthetischen Bericht, den du sichern wirst.
Amazon EBS bietet Blockspeicher für EC2. Ein Volume ist eine festplattenähnliche Ressource; ein Dateisystem organisiert die Dateien auf diesem Datenträger. Das Verbinden eines Volumes stellt sein Blockgerät bereit, erstellt aber kein Dateisystem. Der Leitfaden zu EBS-Volumes beschreibt die Verbindung und Persistenz von Volumes.
Erstelle ein kleines, leeres SSD-Volume für allgemeine Zwecke. gp3 wählt den Volumetyp, --size 1 fordert ein GiB an und die Zonenvariable legt es in derselben Zone wie deine Instance an. Speichere seine ID für spätere Aktionen:
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)
Warte, bis das neue Volume verfügbar ist:
aws ec2 \
wait volume-available \
--volume-ids "$VOLUME_ID"
Verbinde es mit dem API-Gerätenamen /dev/sdf:
aws ec2 \
attach-volume \
--volume-id "$VOLUME_ID" \
--instance-id "$INSTANCE_ID" \
--device /dev/sdf
Warte auf die Verbindung:
aws ec2 \
wait volume-in-use \
--volume-ids "$VOLUME_ID"
Prüfe das Volume und seine Verbindung:
aws ec2 \
describe-volumes \
--volume-ids "$VOLUME_ID" \
--query 'Volumes[].{Volume:VolumeId,State:State,Zone:AvailabilityZone,Size:Size,Type:VolumeType,Attachments:Attachments}'
Bestätige in-use, Größe 1, Typ gp3 und eine Verbindung mit deiner Instance. Aktualisiere AWS View und prüfe die Volume-Zeile. Das Root-Volume ist vom neuen Datenvolume getrennt.
Rufe die aktuelle öffentliche Adresse der Instance ab:
PUBLIC_IP=$(aws ec2 \
describe-instances \
--instance-ids "$INSTANCE_ID" \
--query 'Reservations[0].Instances[0].PublicIpAddress' \
--output text)
Verbinde dich mit der bereitgestellten SSH-Konfiguration:
ssh -F ssh_config ubuntu@"$PUBLIC_IP"
Prüfe innerhalb der Instance das neu verbundene Gerät. Sein Linux-Name ist in diesem Lab /dev/xvdf; Gerätenamen können vom API-Verbindungsnamen abweichen. Andere EC2-Images können NVMe-Namen verwenden. Identifiziere deshalb einen Datenträger, bevor du ihn bearbeitest. Der offizielle Leitfaden zur Vorbereitung von Linux-Volumes erklärt diesen Unterschied.
lsblk -f /dev/xvdf
Bestätige, dass das Gerät keinen Dateisystemtyp hat. Erstelle nur auf diesem neu erstellten, leeren Datenvolume ein ext4-Dateisystem. Das Formatieren eines Volumes mit vorhandenen Daten würde diese löschen:
sudo mkfs.ext4 /dev/xvdf
Ein Mountpunkt ist das Verzeichnis, über das du auf ein Dateisystem zugreifst. Mounte das neue Dateisystem im vorbereiteten Verzeichnis der Berichtsanwendung:
sudo mount /dev/xvdf /srv/reports
Bestätige das Quellgerät, Dateisystem und den Mountpunkt:
findmnt /srv/reports
Suche nach /dev/xvdf, ext4 und /srv/reports. Erstelle einen CSV-Bericht mit synthetischen Daten. sudo tee schreibt in das Dateisystem, das dem Administrator gehört; das Here-Dokument mit einem zitierten Begrenzungswort bewahrt die zwei Zeilen:
sudo tee /srv/reports/report.csv <<'CSV'
period,total
Q1,320
CSV
Lies die Datei erneut:
cat /srv/reports/report.csv
Kehre zum LabEx-Terminal zurück:
exit
Wähle in AWS View recovery-server und klicke auf Read volume report. Bestätige HTTP 200 und den CSV-Text period,total und Q1,320. Diese Antwort zeigt, dass die Anwendung die Datei vom gemounteten Volume lesen kann.
Der Mount in diesem Lab erfolgt manuell. Ein Neustart stellt einen manuellen Mount nicht automatisch wieder her. In Produktionsumgebungen wird üblicherweise die Dateisystem-UUID in /etc/fstab konfiguriert, nachdem der Eintrag getestet wurde.
Erstelle einen konsistenten Snapshot
In diesem Schritt unterbrichst du den Dateisystemzugriff und sicherst das Quellvolume.
Ein EBS-Snapshot ist ein Backup eines Volumes zu einem bestimmten Zeitpunkt. Ein Backup muss die benötigten Daten enthalten; ein erfolgreicher Ressourcenstatus allein genügt nicht. AWS empfiehlt, Schreibvorgänge zu pausieren oder das Volume auszuhängen, um Konsistenz zu gewährleisten. Dies beschreibt der Leitfaden zur Snapshot-Erstellung. In diesem Lab wird das Datendateisystem vor dem Backup ausgehängt.
Verbinde dich mit der Instance:
ssh -F ssh_config ubuntu@"$PUBLIC_IP"
Hänge das Quelldateisystem aus, um Schreibvorgänge abzuschließen und den Dateisystemzugriff zu stoppen:
sudo umount /srv/reports
Kehre zum LabEx-Terminal zurück:
exit
Erstelle einen Snapshot deines Quellvolumes. Speichere seine ID und kennzeichne ihn als 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)
Die Snapshot-Erstellung ist asynchron. Warte, bis sie abgeschlossen ist:
aws ec2 \
wait snapshot-completed \
--snapshot-ids "$SNAPSHOT_ID"
Prüfe seinen Zustand und das Quellvolume:
aws ec2 \
describe-snapshots \
--snapshot-ids "$SNAPSHOT_ID" \
--query 'Snapshots[].{Snapshot:SnapshotId,State:State,SourceVolume:VolumeId}'
Bestätige completed und das erwartete Quellvolume. Aktualisiere AWS View, um den Snapshot zu prüfen. Du testest seinen Inhalt durch eine Wiederherstellung nach dem absichtlichen Löschen einer Datei.
Beobachte das versehentliche Löschen einer Datei
In diesem Schritt entfernst du den synthetischen Bericht vom Quellvolume und beobachtest den fehlenden Bericht in der Anwendung.
Verbinde dich erneut und mounte das ursprüngliche Volume wieder:
ssh -F ssh_config ubuntu@"$PUBLIC_IP"
sudo mount /dev/xvdf /srv/reports
Lösche nur die synthetische Datei, die du für diese Übung erstellt hast:
sudo rm /srv/reports/report.csv
Kehre zum LabEx-Terminal zurück:
exit
Wähle in AWS View recovery-server und klicke auf Read volume report. Die Anfrage sollte weiterhin HTTP 200 liefern, aber report ist jetzt null. Die Anwendung läuft; die benötigte Datei fehlt. So unterscheidest du ein Problem mit dem Speicherinhalt von einem gestoppten Server.
Dein Snapshot wurde vor dieser Löschung erstellt. Er kann ein neues Volume mit dem früheren Bericht bereitstellen, ohne das ursprüngliche Volume zu ändern.
Stelle ein neues Volume aus dem Snapshot wieder her
In diesem Schritt stellst du das Backup auf einem separaten Volume wieder her und wechselst die Anwendung auf das wiederhergestellte Dateisystem.
Die Wiederherstellung erstellt ein neues Volume; sie macht Änderungen im bestehenden Volume nicht rückgängig. Erstelle den Ersatz mit deinem abgeschlossenen Snapshot in der Availability Zone der Instance. Der offizielle Leitfaden zur Wiederherstellung beschreibt diesen Austausch:
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)
Warte, bis es bereit ist:
aws ec2 \
wait volume-available \
--volume-ids "$RESTORED_VOLUME_ID"
Verbinde es als zweites Datengerät:
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"
Prüfe die Snapshot-Zuordnung des Ersatzvolumes:
aws ec2 \
describe-volumes \
--volume-ids "$RESTORED_VOLUME_ID" \
--query 'Volumes[].{Volume:VolumeId,State:State,Snapshot:SnapshotId}'
Bestätige in-use und die gespeicherte Snapshot-ID. Verbinde dich, um den Mount der Anwendung zu wechseln:
ssh -F ssh_config ubuntu@"$PUBLIC_IP"
Hänge das ursprüngliche Dateisystem aus:
sudo umount /srv/reports
Prüfe das wiederhergestellte Gerät, das in diesem Lab als /dev/xvdg bereitgestellt wird:
sudo lsblk -f /dev/xvdg
Es enthält bereits ein aus dem Backup kopiertes ext4-Dateisystem. Formatiere dieses Gerät nicht: Das würde die wiederhergestellten Daten überschreiben. Mounte sein bestehendes Dateisystem im Berichtsverzeichnis der Anwendung:
sudo mount /dev/xvdg /srv/reports
Bestätige die aktive Quelle:
findmnt /srv/reports
Suche nach /dev/xvdg. Lies den wiederhergestellten Bericht:
cat /srv/reports/report.csv
Erwarte die beiden ursprünglichen Zeilen period,total und Q1,320. Kehre zum LabEx-Terminal zurück:
exit
Klicke in AWS View auf Refresh resources, wähle recovery-server und klicke auf Read volume report. Bestätige HTTP 200 und den ursprünglichen CSV-Text. Ein erfolgreicher Wiederherstellungstest beweist, dass dieses Backup nutzbare Anwendungsdaten enthält.
Entferne die Wiederherstellungsressourcen
In diesem Schritt bereinigst du beide Datenvolumes, den Snapshot und die Instance.
Verbinde dich und hänge das wiederhergestellte Dateisystem aus:
ssh -F ssh_config ubuntu@"$PUBLIC_IP"
sudo umount /srv/reports
exit
Trenne das wiederhergestellte Volume:
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"
Das Quelldateisystem wurde während der Wiederherstellung ausgehängt. Trenne auch sein 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"
Lösche die beiden getrennten Übungsvolumes:
aws ec2 \
delete-volume \
--volume-id "$RESTORED_VOLUME_ID"
aws ec2 \
delete-volume \
--volume-id "$VOLUME_ID"
Lösche das Übungsbackup nach seinem Wiederherstellungstest:
aws ec2 \
delete-snapshot \
--snapshot-id "$SNAPSHOT_ID"
Beende deinen Server und warte auf seinen abschließenden Zustand:
aws ec2 \
terminate-instances \
--instance-ids "$INSTANCE_ID"
aws ec2 \
wait instance-terminated \
--instance-ids "$INSTANCE_ID"
Bestätige, dass die Instance beendet ist:
aws ec2 \
describe-instances \
--instance-ids "$INSTANCE_ID" \
--query 'Reservations[].Instances[].{Instance:InstanceId,State:State.Name}'
Liste deine benannten Übungsvolumes und das Backup auf:
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'
Beide Listen sollten [] sein. Aktualisiere AWS View und bestätige, dass die Übungsvolumes und der Snapshot entfernt sind und der Server kein laufendes Ziel mehr ist. Behalte das vorbereitete Netzwerk und Schlüsselpaar bei.
Zusammenfassung
Du hast ein Berichtsvolume mit einem EBS-Snapshot gesichert, die Wirkung einer Dateilöschung beobachtet und ein separates Volume aus dem Backup wiederhergestellt. Du hast das bestehende wiederhergestellte Dateisystem ohne Formatierung gemountet und die ursprünglichen Anwendungsdaten geprüft. Zum Schluss hast du beide Datenvolumes, den Snapshot und die Instance entfernt.
