RDS aus einem Snapshot wiederherstellen: Neuer Endpunkt oder Überschreiben?

Ein Kollege öffnet morgens das AWS-Konsole, stellt einen Datenverlust fest und fragt sofort: 'Wenn ich jetzt einen RDS-Snapshot wiederherstelle – überschreibt das meine laufende Instanz oder bekomme ich eine neue?' Die Antwort auf diese Frage entscheidet darüber, ob das Recovery-Verfahren in Produktion funktioniert oder ob der Endpunkt-Wechsel die Anwendung für Stunden lahmlegt.

TL;DR – RDS Snapshot Wiederherstellung auf einen Blick

Frage	Antwort
Überschreibt die Wiederherstellung die bestehende Instanz?	Nein. AWS erstellt immer eine neue DB-Instanz.
Ändert sich der Endpunkt?	Ja. Die neue Instanz erhält einen neuen, anderen DNS-Endpunkt.
Bleibt die alte Instanz erhalten?	Ja, bis sie manuell gelöscht wird.
Werden Parameter Groups übernommen?	Nein. Die neue Instanz verwendet die Standard-Parameter-Group.
Werden Security Groups übernommen?	Nein. Es wird die Standard-VPC-Security-Group zugewiesen.
Sind Multi-AZ und Read Replicas aktiv?	Nein. Diese müssen nach der Wiederherstellung neu konfiguriert werden.

Wie RDS-Snapshot-Wiederherstellung funktioniert

RDS-Snapshots sind keine In-Place-Backups, die auf eine bestehende Instanz zurückgespielt werden. AWS behandelt jeden Snapshot als vollständige Vorlage für eine neue DB-Instanz. Der Wiederherstellungsvorgang provisioniert neues Compute, neuen Storage und weist einen neuen DNS-Endpunkt zu – die Quellinstanz bleibt dabei vollständig unangetastet.

Das ist kein Implementierungsdetail, sondern ein fundamentales Designprinzip: Snapshots sind unveränderliche Punkt-in-Zeit-Abbilder des Storage-Volumes. Eine Wiederherstellung bedeutet, dieses Abbild auf einem frischen Volume zu mounten und eine neue Instanz darüber zu starten.

graph TD A["RDS Snapshot
(Punkt-in-Zeit-Abbild)"] --> B["AWS: Neue DB-Instanz
wird provisioniert"] B --> C["Neuer DNS-Endpunkt
wird zugewiesen"] B --> D["Standard Security Group
wird zugewiesen"] B --> E["Standard Parameter Group
wird zugewiesen"] C --> F["Neue Instanz: available"] D --> F E --> F G["Quellinstanz"] -->|"bleibt unverändert aktiv"| G A -->|"Quelle"| G style G fill:#f0f0f0,stroke:#999 style F fill:#d4edda,stroke:#28a745

Snapshot-Quelle: Der manuelle oder automatische Snapshot enthält das vollständige Storage-Abbild der Quellinstanz zum Zeitpunkt der Erstellung.
Neue Instanz: AWS erstellt eine vollständig neue DB-Instanz mit eigenem Compute, Storage und Konfiguration.
Neuer Endpunkt: Der DNS-Endpunkt der neuen Instanz unterscheidet sich vom Endpunkt der Quellinstanz.
Quellinstanz unverändert: Die ursprüngliche Instanz läuft weiter und bleibt erreichbar, bis sie manuell gelöscht wird.
Standard-Konfiguration: Parameter Groups, Security Groups und Option Groups werden auf Standardwerte zurückgesetzt – nicht von der Quellinstanz übernommen.

Was nach der Wiederherstellung manuell konfiguriert werden muss

Hier liegt die häufigste Falle in der Praxis: Die Instanz läuft, die Daten sind da – aber die Anwendung kann sich nicht verbinden, weil Security Groups und Parameter Groups auf Standardwerte zurückgesetzt wurden. Das ist kein Fehler, sondern dokumentiertes Verhalten.

Folgende Einstellungen werden nicht automatisch von der Quellinstanz übernommen:

Security Groups: Die neue Instanz erhält die Standard-VPC-Security-Group. Produktions-Inbound-Regeln müssen manuell zugewiesen werden.
DB Parameter Group: Eigene Parameter Groups (z.B. mit angepassten max_connections oder innodb_buffer_pool_size) müssen neu zugewiesen werden.
DB Option Group: Optionale Features wie Oracle APEX oder SQL Server Backup müssen neu konfiguriert werden.
Multi-AZ: Ist standardmäßig deaktiviert und muss nach der Wiederherstellung aktiviert werden.
Read Replicas: Werden nicht wiederhergestellt und müssen neu erstellt werden.
Enhanced Monitoring und Performance Insights: Müssen manuell aktiviert werden.

Stell dir den Snapshot wie einen Disk-Image-Export vor: Du bekommst die Daten, aber nicht das Betriebssystem-Setup, die Firewall-Regeln oder die Dienst-Konfiguration des ursprünglichen Servers. Das Storage-Abbild ist vollständig – alles drumherum ist neu.

RDS aus Snapshot wiederherstellen – Schritt-für-Schritt

Schritt 1: Verfügbare Snapshots auflisten

Bevor die Wiederherstellung gestartet wird, sollte der korrekte Snapshot identifiziert werden. Automatische Snapshots haben ein Ablaufdatum, manuelle Snapshots bleiben bis zur expliziten Löschung erhalten. Der Zeitstempel im Snapshot-Identifier ist entscheidend für die Auswahl des richtigen Wiederherstellungspunkts.

aws rds describe-db-snapshots \
  --db-instance-identifier meine-produktions-db \
  --query 'DBSnapshots[*].{ID:DBSnapshotIdentifier,Zeit:SnapshotCreateTime,Status:Status}' \
  --output table \
  --region us-east-1

Schritt 2: Neue Instanz aus Snapshot wiederherstellen

Der Identifier der neuen Instanz muss sich vom Identifier der Quellinstanz unterscheiden – AWS erlaubt keine identischen Identifier im selben Account und derselben Region. Das ist auch der Moment, an dem der neue Endpunkt festgelegt wird: Er basiert auf dem neuen --db-instance-identifier.

aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier meine-db-restored \
  --db-snapshot-identifier rds:meine-produktions-db-2024-01-15-03-00 \
  --db-instance-class db.t3.medium \
  --db-subnet-group-name meine-subnet-group \
  --no-multi-az \
  --region us-east-1

Schritt 3: Wiederherstellungsstatus überwachen

Die neue Instanz durchläuft den Status creating → modifying → available. Erst wenn available erreicht ist, ist die Instanz verbindungsbereit. Den Endpunkt kann man erst nach Erreichen dieses Status auslesen.

aws rds describe-db-instances \
  --db-instance-identifier meine-db-restored \
  --query 'DBInstances[0].{Status:DBInstanceStatus,Endpunkt:Endpoint.Address,Port:Endpoint.Port}' \
  --output table \
  --region us-east-1

Schritt 4: Security Groups zuweisen

Ohne diesen Schritt ist die neue Instanz von der Anwendung nicht erreichbar – die Standard-Security-Group erlaubt in den meisten Produktionsumgebungen keinen eingehenden Datenbankverkehr. Das ist der Schritt, der am häufigsten vergessen wird und zu Verbindungsfehlern nach der Wiederherstellung führt.

aws rds modify-db-instance \
  --db-instance-identifier meine-db-restored \
  --vpc-security-group-ids sg-0123456789abcdef0 \
  --apply-immediately \
  --region us-east-1

Schritt 5: Parameter Group zuweisen

Wenn die Quellinstanz eine eigene Parameter Group verwendet hat, muss diese der neuen Instanz explizit zugewiesen werden. Ohne diesen Schritt laufen Datenbankparameter auf AWS-Standardwerten – was bei angepassten Produktionskonfigurationen zu Performance-Unterschieden oder Verbindungsproblemen führen kann.

aws rds modify-db-instance \
  --db-instance-identifier meine-db-restored \
  --db-parameter-group-name meine-custom-parameter-group \
  --apply-immediately \
  --region us-east-1

Schritt 6: Neuen Endpunkt auslesen und Anwendung umkonfigurieren

Der neue Endpunkt ist der einzige Weg, die Anwendung mit der wiederhergestellten Instanz zu verbinden. Ein direktes Überschreiben des alten Endpunkts ist nicht möglich – der DNS-Name ist an die Instanz gebunden und kann nicht manuell gesetzt werden. In Produktionsumgebungen empfiehlt sich der Einsatz eines Route 53 CNAME oder eines Application-seitigen Konfigurationsmanagements, um den Endpunkt-Wechsel zu abstrahieren.

aws rds describe-db-instances \
  --db-instance-identifier meine-db-restored \
  --query 'DBInstances[0].Endpoint.Address' \
  --output text \
  --region us-east-1

Typische Fehldiagnose aus der Praxis

Ein häufiges Szenario: Die Wiederherstellung ist abgeschlossen, der Status zeigt available, aber die Anwendung meldet Verbindungsfehler. Der erste Verdacht fällt auf den Snapshot selbst – vielleicht sind die Daten beschädigt? Nach 20 Minuten Debugging stellt sich heraus: Die Security Group der neuen Instanz erlaubt keinen eingehenden Traffic auf Port 3306.

Die eigentliche Ursache ist, dass die Wiederherstellung die Standard-VPC-Security-Group zuweist, die in dieser Umgebung nur ausgehenden Traffic erlaubt. Der Snapshot war vollständig korrekt – das Problem lag ausschließlich in der Netzwerkkonfiguration der neuen Instanz.

Korrekte Diagnose: Immer zuerst Security Groups und Endpunkt-Erreichbarkeit prüfen, bevor der Snapshot als Fehlerquelle in Betracht gezogen wird.

aws rds describe-db-instances \
  --db-instance-identifier meine-db-restored \
  --query 'DBInstances[0].VpcSecurityGroups' \
  --output table \
  --region us-east-1

Endpunkt-Wechsel in Produktion handhaben

Der neue Endpunkt ist die größte operative Herausforderung bei RDS-Wiederherstellungen. Anwendungen, die den Datenbankendpunkt direkt in ihrer Konfiguration hartkodiert haben, müssen nach jeder Wiederherstellung manuell aktualisiert werden.

Zwei bewährte Ansätze zur Abstraktion:

Route 53 CNAME: Ein interner DNS-Eintrag zeigt auf den aktuellen RDS-Endpunkt. Bei einer Wiederherstellung wird nur der CNAME-Zielwert aktualisiert – die Anwendungskonfiguration bleibt unverändert.
AWS Secrets Manager: Der Datenbankendpunkt wird als Secret gespeichert. Nach der Wiederherstellung wird nur das Secret aktualisiert, Anwendungen lesen den Endpunkt dynamisch aus.

graph LR APP["Anwendung"] --> CNAME["Route 53 CNAME
db.intern.example.com"] CNAME -->|"Normalbetrieb"| OLD["RDS Instanz (alt)
endpoint-alt.rds.amazonaws.com"] CNAME -->|"Nach Wiederherstellung"| NEW["RDS Instanz (neu)
endpoint-neu.rds.amazonaws.com"] style OLD fill:#f0f0f0,stroke:#999 style NEW fill:#d4edda,stroke:#28a745 style CNAME fill:#cce5ff,stroke:#004085

Anwendung → CNAME: Die Anwendung verbindet sich über einen internen DNS-Namen (z.B. db.intern.example.com), nicht direkt über den RDS-Endpunkt.
CNAME → Alte Instanz: Im Normalbetrieb zeigt der CNAME auf den Endpunkt der produktiven RDS-Instanz.
Nach Wiederherstellung: Der CNAME wird auf den Endpunkt der neuen, wiederhergestellten Instanz umgebogen.
Anwendung unverändert: Die Anwendungskonfiguration muss nicht angepasst werden – nur der DNS-Eintrag ändert sich.

Erforderliche IAM-Berechtigungen

Für die Durchführung einer Snapshot-Wiederherstellung über die CLI oder automatisierte Pipelines sind folgende IAM-Berechtigungen erforderlich. Das Prinzip der minimalen Rechtevergabe sollte dabei strikt eingehalten werden.

🔽 IAM-Policy für RDS Snapshot-Wiederherstellung anzeigen

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RDSSnapshotRestore",
      "Effect": "Allow",
      "Action": [
        "rds:DescribeDBSnapshots",
        "rds:RestoreDBInstanceFromDBSnapshot",
        "rds:DescribeDBInstances",
        "rds:ModifyDBInstance",
        "rds:AddTagsToResource"
      ],
      "Resource": "*"
    }
  ]
}

Hinweis: rds:DescribeDBSnapshots und rds:DescribeDBInstances erfordern "Resource": "*", da diese List/Describe-Aktionen keine ressourcenspezifische Einschränkung unterstützen. Für RestoreDBInstanceFromDBSnapshot und ModifyDBInstance kann die Einschränkung auf spezifische ARNs geprüft werden – dies hängt von der jeweiligen Umgebung ab. Prüfe die aktuelle Unterstützung im AWS Service Authorization Reference.

Zusammenfassung und nächste Schritte zur RDS Snapshot Wiederherstellung

Eine RDS-Wiederherstellung aus einem Snapshot erstellt immer eine neue Instanz mit einem neuen Endpunkt. Die Quellinstanz bleibt unverändert. Security Groups, Parameter Groups und erweiterte Features wie Multi-AZ müssen nach der Wiederherstellung manuell konfiguriert werden.

Für produktive Umgebungen empfiehlt sich eine Route 53 CNAME-Abstraktion, um den Endpunkt-Wechsel von der Anwendungskonfiguration zu entkoppeln. Wer regelmäßige Recovery-Tests durchführt, kennt diese Schritte auswendig – wer sie nicht testet, lernt sie im Ernstfall unter Zeitdruck.

Glossar

Begriff	Bedeutung
DB-Snapshot	Vollständiges, unveränderliches Punkt-in-Zeit-Abbild des RDS-Storage-Volumes. Kann manuell oder automatisch erstellt werden.
DB-Endpunkt	DNS-Hostname, über den Anwendungen eine Verbindung zur RDS-Instanz herstellen. Ist an die Instanz gebunden und ändert sich bei einer Wiederherstellung.
Parameter Group	Sammlung von Datenbank-Engine-Parametern (z.B. Speicher, Verbindungslimits), die einer RDS-Instanz zugewiesen wird.
Multi-AZ	RDS-Hochverfügbarkeitskonfiguration mit synchroner Replikation in eine zweite Availability Zone. Wird bei Wiederherstellungen nicht automatisch aktiviert.
CNAME	DNS-Eintragstyp, der einen Alias-Namen auf einen anderen Hostnamen zeigt. Wird zur Abstraktion des RDS-Endpunkts verwendet.

Dieses Blog durchsuchen

SW BBANG D