Einführung
Eine versehentliche Datenänderung kann eine laufende Bestellanwendung mit fehlenden Geschäftsdaten zurücklassen. Du erstellst einen manuellen RDS-Snapshot, führst eine kontrollierte Löschung durch und holst die Bestellung durch eine neue Instanz und einen geänderten Anwendungs-Endpoint zurück.
Schließe zuerst die vorherigen Datenbank- und SQL-Labs ab. Diese unabhängige Umgebung enthält eine primäre Datenbank mit drei Beispielbestellungen und eine verbundene Anwendung. Nach dem Wiederherstellungsnachweis entfernst du beide Übungsinstanzen und den Snapshot.
Bezug zu Zertifizierungen
Dieses Lab bietet einführende praktische Übungen zu folgenden Prüfungsthemen.
- Cloud Practitioner (CLF-C02) · Aufgabe 3.4: Verwaltete relationale Datenbanken und ihre Wiederherstellungsoptionen verstehen.
- Solutions Architect – Associate (SAA-C03) · Aufgabe 2.2: Sicherung und Wiederherstellung einer Anwendungsdatenbank üben.
Einen manuellen Datenbank-Snapshot erstellen
In diesem Schritt sicherst du die aktuellen Daten vor einer Änderung.
Ein DB-Snapshot ist eine Wiederherstellungskopie einer RDS-Datenbankinstanz. Ein manueller Snapshot wird ausdrücklich erstellt und bleibt bis zu seiner Löschung eine separate Ressource. Dieses Lab nutzt einen manuellen Snapshot und konfiguriert weder automatische Aufbewahrung noch zeitpunktbezogene Wiederherstellung.
Lade die vorbereiteten Verbindungseinstellungen und prüfe die Anwendungsdaten:
cd /home/labex/project
source database.env
curl \
--silent \
--show-error \
--fail \
http://127.0.0.1:8080/application/orders | jq
Du solltest die Bestellungen 101, 102 und 103 sehen. Bestellung 101 gehört Maya und hat den Betrag 49.90.
Erstelle die Datenbankkopie:
aws rds \
create-db-snapshot \
--db-instance-identifier orders-db \
--db-snapshot-identifier orders-before-delete \
--query 'DBSnapshot.{Snapshot:DBSnapshotIdentifier,Source:DBInstanceIdentifier,Status:Status}'
aws rds \
wait db-snapshot-available \
--db-snapshot-identifier orders-before-delete
aws rds \
describe-db-snapshots \
--db-snapshot-identifier orders-before-delete \
--query 'DBSnapshots[].{Snapshot:DBSnapshotIdentifier,Type:SnapshotType,Source:DBInstanceIdentifier,Status:Status}'
Du solltest einen manuellen Snapshot von orders-db mit Status available erhalten. AWS View sollte ihn neben der primären Datenbank anzeigen. Warte vor der nächsten Änderung auf seine Fertigstellung.
Einen kontrollierten Datenverlust beobachten
In diesem Schritt entfernst du genau eine Beispielbestellung und beobachtest die resultierenden Anwendungsdaten.
Die folgende Löschung ist in dieser Übung beabsichtigt. WHERE begrenzt sie auf Bestellung 101:
psql \
"service=orders-db" \
--set=ON_ERROR_STOP=1 \
--command 'DELETE FROM orders WHERE order_id = 101;'
Lies die verbleibenden Zeilen:
psql \
"service=orders-db" \
--command 'SELECT order_id, customer, total FROM orders ORDER BY order_id;'
Du solltest nur 102 und 103 erhalten. Fordere die Anwendungsliste an:
curl \
--silent \
--show-error \
--fail \
http://127.0.0.1:8080/application/orders | jq
Die Anwendung verbindet sich weiterhin und antwortet, aber Mayas Bestellung fehlt. Eine funktionierende Verbindung beweist keine vollständigen Geschäftsdaten. Der Snapshot vor der Löschung enthält die benötigte Wiederherstellungskopie.
Eine neue Instanz wiederherstellen und die Anwendung umstellen
In diesem Schritt stellst du den Snapshot in einer neuen Instanz wieder her und belegst, dass die Anwendung deren Daten liest.

Konzeptdiagramm: Wiederherstellen erzeugt einen neuen Endpunkt; die gestrichelte Linie vergleicht die nicht zurückgesetzte Quelle.
Eine Snapshot-Wiederherstellung erstellt eine neue RDS-Instanz. Sie setzt die bestehende Instanz nicht an Ort und Stelle zurück. Verwende eine andere Kennung und wähle die vorbereitete Subnetz- und Sicherheitsgruppe ausdrücklich aus:
aws rds \
restore-db-instance-from-db-snapshot \
--db-instance-identifier orders-restored \
--db-snapshot-identifier orders-before-delete \
--db-instance-class db.t3.micro \
--db-subnet-group-name orders-subnets \
--vpc-security-group-ids "$DB_SECURITY_GROUP_ID" \
--no-publicly-accessible \
--query 'DBInstance.{Identifier:DBInstanceIdentifier,Status:DBInstanceStatus,Endpoint:Endpoint}'
aws rds \
wait db-instance-available \
--db-instance-identifier orders-restored
Frage die neue Engine über ihren vorbereiteten Verbindungseintrag ab:
psql \
"service=orders-restored" \
--command 'SELECT order_id, customer, total FROM orders ORDER BY order_id;'
Du solltest alle drei ursprünglichen Bestellungen erhalten. Prüfe die Quelle unabhängig:
psql \
"service=orders-db" \
--command 'SELECT order_id, customer, total FROM orders ORDER BY order_id;'
Sie sollte weiterhin nur 102 und 103 enthalten. Du hast jetzt zwei unabhängige Instanzen: die geänderte Quelle und eine wiederhergestellte Datenbank.
Erfasse den wiederhergestellten Endpoint und ändere beide Host-Felder der Anwendung:
RESTORED_ENDPOINT=$(aws rds \
describe-db-instances \
--db-instance-identifier orders-restored \
--query 'DBInstances[0].Endpoint.Address' \
--output text)
jq \
--arg host "$RESTORED_ENDPOINT" \
'.read_host = $host | .write_host = $host' \
app-config.json > app-config.new
mv app-config.new app-config.json
Teste die Anwendung:
curl \
--silent \
--show-error \
--fail \
http://127.0.0.1:8080/application/orders | jq
Du solltest erneut 101, 102 und 103 erhalten. AWS View sollte beide Instanzen auflisten und die wiederhergestellten Bestellungen anzeigen. Die Wiederherstellung ist abgeschlossen, wenn die Anwendung den neuen Endpoint nutzt und die erwarteten Daten verfügbar sind, nicht bereits mit dem Erstellen der Instanz.
Der Snapshot enthält die vor der Löschung erfassten Daten. Änderungen nach dieser Sicherung sind nicht automatisch in der wiederhergestellten Instanz enthalten. Sicherungszeitpunkt und Entscheidungen zur Anwendungsumstellung sind für die Planung wichtig.

Beide Instanzen und den manuellen Snapshot entfernen
In diesem Schritt entfernst du jede verwendete Wiederherstellungsressource.
Lösche die wiederhergestellte und die ursprüngliche Übungsinstanz:
aws rds \
delete-db-instance \
--db-instance-identifier orders-restored \
--skip-final-snapshot \
--query 'DBInstance.DBInstanceIdentifier'
aws rds \
delete-db-instance \
--db-instance-identifier orders-db \
--skip-final-snapshot \
--query 'DBInstance.DBInstanceIdentifier'
aws rds \
wait db-instance-deleted \
--db-instance-identifier orders-restored
aws rds \
wait db-instance-deleted \
--db-instance-identifier orders-db
Der manuelle Snapshot ist von den Instanzen getrennt und muss ebenfalls gelöscht werden:
aws rds \
delete-db-snapshot \
--db-snapshot-identifier orders-before-delete \
--query 'DBSnapshot.DBSnapshotIdentifier'
Prüfe beide Bestandslisten:
aws rds \
describe-db-instances \
--query 'DBInstances[].DBInstanceIdentifier'
aws rds \
describe-db-snapshots \
--snapshot-type manual \
--query 'DBSnapshots[].DBSnapshotIdentifier'
Du solltest jeweils [] erhalten. AWS View sollte weder Datenbank noch manuellen Snapshot zeigen. Behalte die vorbereitete Anwendung und das Netzwerk.
Zusammenfassung
Du hast einen manuellen Snapshot erstellt, eine kontrollierte Löschung beobachtet und die gesicherten Daten in einer neuen Instanz wiederhergestellt. Die Endpoint-Umstellung brachte die fehlende Bestellung zurück, während die Quelle unverändert blieb. Anschließend hast du beide Instanzen und den separaten Snapshot gelöscht.
Das nächste Lab trennt Lese- und Schreibanfragen der Anwendung mithilfe einer PostgreSQL-Lesereplik.



