View a markdown version of this page

Kontinuierliche Backups und Point-in-Time-Recovery (PITR) - AWS Backup
Überlegungen zu kontinuierlichem Backup und PITRUnterstützte Services

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Kontinuierliche Backups und Point-in-Time-Recovery (PITR)

AWS Backup Unterstützt für einige Ressourcen zusätzlich zu Snapshot-Backups auch kontinuierliche Backups und Point-in-Time Recovery (PITR).

Bei kontinuierlichen Backups können Sie Ihre AWS Backup unterstützte Ressource wiederherstellen, indem Sie sie auf eine von Ihnen gewählte Zeit mit einer Genauigkeit von 1 Sekunde (maximal 35 Tage zurückgehen) zurückspulen. Bei kontinuierlichen Backups wird zunächst ein vollständiges Backup Ihrer Ressource erstellt und anschließend die Transaktionsprotokolle Ihrer Ressource kontinuierlich gesichert. PITR greift auf Ihr vollständiges Backup zu und spielt das Transaktionslog zu dem Zeitpunkt ab, den Sie für die Wiederherstellung angegeben haben. AWS Backup

Alternativ können stündlich Snapshot-Backups erstellt werden. Snapshot-Backups können bis zu einem Maximum von 100 Jahren gespeichert werden. Snapshots können für vollständige oder inkrementelle Backups kopiert werden.

Da kontinuierliche Backups und Snapshot-Backups unterschiedliche Vorteile bieten, empfehlen wir Ihnen, Ihre Ressourcen sowohl mit Regeln für kontinuierliche Backups als auch mit Snapshot-Backups zu schützen.

Ein On-Demand-Backup beginnt sofort mit der Sicherung Ihrer Ressource. Sie können ein On-Demand-Backup wählen, wenn Sie ein Backup zu einem anderen als dem im Backup-Plan festgelegten Zeitpunkt erstellen möchten. Ein On-Demand-Backup kann beispielsweise verwendet werden, um das Backup und die Funktionalität jederzeit zu testen.

Sie können mit PITR keine On-Demand-Backups verwenden, da bei einem On-Demand-Backup Ressourcen in dem Zustand erhalten bleiben, in dem sie sich zum Zeitpunkt der Erstellung des Backups befinden, während PITR kontinuierliche Backups verwendet, bei denen Änderungen über einen bestimmten Zeitraum aufgezeichnet werden.

Sie können sich für kontinuierliche Backups für unterstützte Ressourcen entscheiden, wenn Sie AWS Backup mithilfe der AWS Backup Konsole oder der API einen Backup-Plan erstellen. Der Plan für kontinuierliche Backups erstellt einen kontinuierlichen Wiederherstellungspunkt und aktualisiert diesen bei jeder Ausführung des Jobs.

Inhalt

Point-in-time Überlegungen zur Wiederherstellung

Beachten Sie die folgenden Überlegungen zu zeitpunktbezogenen Wiederherstellungen (PITR):

  • Automatischer Fallback auf Snapshots – Wenn AWS Backup kein kontinuierliches Backup durchführen kann, versucht es stattdessen, ein Snapshot-Backup durchzuführen.

  • Kontinuierliche Backups auf Abruf werden AWS Backup nicht unterstützt — kontinuierliche Backups auf Abruf werden nicht unterstützt, da On-Demand-Backups einen bestimmten Zeitpunkt aufzeichnen, während sich kontinuierliche Backup-Aufzeichnungen über einen bestimmten Zeitraum ändern.

  • Keine Unterstützung für den Übergang zu Cold Storage – Kontinuierliche Backups unterstützen den Übergang zu Cold Storage nicht, da für den Übergang zu Cold Storage eine Übergangszeit von mindestens 90 Tagen erforderlich ist, wohingegen kontinuierliche Backups eine maximale Aufbewahrungsdauer von 35 Tagen haben.

  • Wiederherstellung der letzten Aktivitäten — Amazon RDS-Aktivitäten ermöglichen Wiederherstellungen bis zu den letzten 5 Minuten der Aktivität; Aurora erlaubt Wiederherstellungen bis zur letzten Aktivität, wie durch angegeben LatestRestorableTime (in der Regel weniger als 5 Minuten); Amazon S3 ermöglicht Wiederherstellungen bis zu den letzten 15 Minuten der Aktivität.

Wichtig

Eine einzelne Ressource kann nur ein kontinuierliches Backup haben. Im Folgenden finden Sie weitere Informationen und bewährte Methoden.

Jede Ressource (z. B. ein Amazon S3-Bucket oder eine Amazon RDS-Datenbank) kann nur ein kontinuierliches Backup (Recovery-Punkt) haben; zusätzliche kontinuierliche Backups sind überflüssig. Wenn mehrere Backup-Richtlinien, -Pläne oder -regeln vorschreiben, mehrere kontinuierliche Backups für dieselbe Ressource AWS Backup zu erstellen, gilt das folgende Verfahren:

  • Wenn mehrere Regeln angeben, dass mehr als ein kontinuierliches Backup in einem einzigen Tresor gespeichert werden soll, AWS Backup folgt der Regel mit der längsten Aufbewahrungsdauer (Lebenszyklus) und ignoriert zusätzliche Regeln.

  • Wenn mehrere Regeln angeben, dass mehr als ein kontinuierliches Backup in mehr als einem Tresor gespeichert werden soll, AWS Backup wird ein kontinuierliches Backup gemäß der ersten verarbeiteten Regel erstellt. Jede nachfolgende Regel, die ein kontinuierliches Backup für eine Ressource festlegt, für die bereits ein kontinuierliches Backup vorhanden ist, führt stattdessen zu einem Snapshot-Backup (in regelmäßigen Abständen).

Wenn doppelte Pläne für kontinuierliche Backups auftreten, können die Snapshot-Backups, die nach dem kontinuierlichen Wiederherstellungspunkt erstellt wurden, den Status aufweisenCompleted with issues. In den detaillierten Informationen dieses Wiederherstellungspunkts wird ein Fehler ähnlich dem folgenden angezeigt“Enabling continuous backup failed, because of the following error: PITR already configured in backup plan: [ARN]”. Dieser Fehler weist darauf hin, dass bereits mindestens ein kontinuierliches Backup konfiguriert ist (für einen anderen Wiederherstellungspunkt als den, bei dem der Fehler aufgetreten ist). Dieses erste kontinuierliche Backup (Recovery Point) kann für die Point-in-Time-Wiederherstellung (PITR) verwendet werden, solange es den Status hat. COMPLETED

Um zu verhindern, dass unbeabsichtigte Snapshots mit Problemen (und Fehlermeldungen) erstellt werden, sollten Sie die Backup-Strategie Ihres Unternehmens überprüfen. Passen Sie bei Bedarf die Backup-Pläne und -Richtlinien an, die mehrere fortlaufende Backups derselben Ressource erstellen.

Nachdem Sie Anpassungen vorgenommen haben, die nur zu einem kontinuierlichen Backup für eine Ressource führen, werden die Snapshot-Backups gemäß dem angegebenen Lebenszyklus des Plans, in dem sie erstellt wurden, aufbewahrt. Anschließend werden sie in den Plan überführt EXPIRED und gelöscht. Das kontinuierliche Backup und seine Fähigkeit zur Wiederherstellung zu einem bestimmten Zeitpunkt werden gemäß der Regel beibehalten, mit der es erstellt wurde.

Unterstützte Dienste für kontinuierliches Backup und PITR

AWS Backup unterstützt kontinuierliche Backups und Point-in-Time-Recovery für die folgenden Dienste und Anwendungen:

Amazon S3

Um PITR für S3-Backups zu aktivieren, müssen kontinuierliche Backups Teil des Backup-Plans sein.

Bei diesem ursprünglichen Backup des Quell-Buckets kann PITR zwar aktiv sein, aber für regionsübergreifende oder kontoübergreifende Zielkopien wird kein PITR verwendet, und bei der Wiederherstellung aus diesen Kopien wird der Zeitpunkt wiederhergestellt, zu dem sie erstellt wurden (die Kopien sind Snapshot-Kopien), anstatt sie zu einem festgelegten Zeitpunkt wiederherzustellen.

AWS Backup für S3 ist der Empfang von S3-Ereignissen über Amazon erforderlich. EventBridge Wenn diese Einstellung in den S3-Bucket-Benachrichtigungseinstellungen deaktiviert ist, werden fortlaufende Backups für diese Buckets gestoppt, bei denen die Einstellung deaktiviert ist. Weitere Informationen finden Sie unter EventBridge Abhängigkeit von Amazon für kontinuierliche S3-Backups.

Wenn Sie AWS Backup die EventBridge Amazon-Regel deaktivieren, wird auch Ihr kontinuierliches Backup gestoppt. Wenn Sie einen aktiven Backup-Plan mit einer Regel für kontinuierliche Backups haben, wird die Amazon-Regel neu erstellt, wenn diese EventBridge Regel erneut ausgelöst AWS Backup wird, und es wird ein neues kontinuierliches Backup erstellt.

RDS

AWS Backup unterstützt kontinuierliche Backups und Point-in-Time-Recovery für alle Amazon RDS-Instances und Aurora, die vom systemeigenen Amazon RDS-Service unterstützt werden. AWS Backup unterstützt keine kontinuierlichen Backups oder Point-in-Time-Recovery für Amazon RDS-Cluster. Multi-AZ

Backup-Zeitpläne: Wenn Sie kontinuierliche Backups für eine Amazon RDS-Instance über aktivieren AWS Backup, AWS Backup übernimmt das automatische Backup-Fenster von Amazon RDS (der native tägliche Snapshot, der die Point-in-Time-Wiederherstellung verankert). AWS Backup positioniert dieses automatische Backup-Fenster in der Nähe des Amazon RDS-Wartungsfensters, um Konflikte zu vermeiden. Sie können das automatische Backup-Fenster nicht direkt konfigurieren, während Sie kontinuierliche Backups AWS Backup verwalten, aber Sie können dessen Platzierung beeinflussen, indem Sie Ihr Amazon RDS-Wartungsfenster anpassen. Das automatische Backup-Fenster positioniert sich beim nächsten Backup-Zyklus neu. RDS erstellt einmal täglich Snapshots, auch wenn ein Backup-Plan eine andere Häufigkeit für Snapshot-Backups als einmal pro Tag vorsieht.

Anmerkung

AWS Backup ändert oder verwaltet das Amazon RDS-Wartungsfenster nicht. Das Wartungsfenster bleibt unter Ihrer Kontrolle und kann über die Amazon RDS-Einstellungen angepasst werden. Backup-Jobs, die durch eine Snapshot-Regel in Ihrem Backup-Plan initiiert wurden, werden nach dem von Ihnen definierten Zeitplan ausgeführt und können trotzdem fehlschlagen, wenn sie sich mit dem Wartungsfenster überschneiden. In diesem Fall erhalten Sie eine Fehlermeldung, die der folgenden ähnelt: „Der Backup-Job konnte nicht gestartet werden, weil er sich entweder innerhalb des in der RDS-Instance konfigurierten wöchentlichen Wartungsfensters befindet oder zu nahe daran liegt.“ Um diesen Fehler zu vermeiden, planen Sie Ihre Snapshot-Backup-Regeln außerhalb Ihres konfigurierten Amazon RDS-Wartungsfensters ein.

Einstellungen: Nachdem Sie eine Regel für AWS Backup kontinuierliche Backups auf eine Amazon RDS-Instance angewendet haben, können Sie in Amazon RDS keine Einstellungen für kontinuierliche Backups erstellen oder ändern. Sie müssen Änderungen über die AWS Backup Konsole oder die AWS Backup CLI vornehmen. Wenn Sie automatische Backups zum ersten Mal aktivieren, tritt ein Ausfall auf, wenn Sie den Aufbewahrungszeitraum für Backups der DB-Instance von 0 auf einen Wert ungleich Null ändern. Planen Sie diese Änderung während eines Wartungsfensters ein, um die Auswirkungen so gering wie möglich zu halten. Weitere Informationen zur Aktivierung automatisierter Backups finden Sie unter Aktivieren automatisierter Backups im Amazon RDS-Benutzerhandbuch.

Stellen Sie die Steuerung des kontinuierlichen Backups für eine Amazon RDS-Instance zurück auf Amazon RDS um:

Console

  1. Öffnen Sie die AWS Backup Konsole unter https://console.aws.amazon.com/backup.

  2. Wählen Sie im Navigationsbereich Backup-Pläne aus.

  3. Löschen Sie alle Amazon-RDS-Backup-Pläne mit kontinuierlichem Backup, um diese Ressource zu schützen.

  4. Wählen Sie Backup vaults (Sicherungstresore) aus. Löschen Sie den Wiederherstellungspunkt des kontinuierlichen Backups aus Ihrem Backup-Tresor. Oder warten Sie, bis die Aufbewahrungsfrist abgelaufen ist, wodurch der AWS Backup Wiederherstellungspunkt automatisch gelöscht wird.

Nachdem Sie diese Schritte abgeschlossen haben, AWS Backup wird die kontinuierliche Sicherung Ihrer Ressource wieder auf Amazon RDS übertragen.

AWS CLI

Rufen Sie den DisassociateRecoveryPoint-API-Vorgang auf.

Weitere Informationen hierzu finden Sie unter DisassociateRecoveryPoint.
Erforderliche IAM-Berechtigungen für kontinuierliche Amazon RDS-Backups

  • Um kontinuierliche Backups für Ihre Amazon RDS-Datenbank AWS Backup zu konfigurieren, stellen Sie sicher, dass die API-Berechtigung in der IAM-Rolle rds:ModifyDBInstance vorhanden ist, die in Ihrer Backup-Plan-Konfiguration definiert ist. Um kontinuierliche Amazon-RDS-Backups wiederherzustellen, müssen Sie die Berechtigung rds:RestoreDBInstanceToPointInTime zu der IAM-Rolle hinzufügen, die Sie für den Wiederherstellungsauftrag eingereicht haben. Sie können die AWS Backup default service role verwenden, um Backups und Wiederherstellungen durchzuführen.

  • Um den Zeitbereich zu beschreiben, der für eine Point-in-Time-Wiederherstellung zur Verfügung steht, rufen Sie an. AWS Backup rds:DescribeDBInstanceAutomatedBackups In der AWS Backup Konsole benötigen Sie die rds:DescribeDBInstanceAutomatedBackups API-Berechtigung in Ihrer AWS Identity and Access Management (IAM) verwalteten Richtlinie. Sie können die von AWSBackupFullAccess oder AWSBackupOperatorAccess verwalteten Richtlinien verwenden. Beide Richtlinien verfügen über alle erforderlichen Berechtigungen. Weitere Informationen finden Sie unter Verwaltete Richtlinien.

Aufbewahrungsfristen: Wenn Sie Ihre PITR-Aufbewahrungsfrist ändern, werden Sie AWS Backup ModifyDBInstance aufgefordert, diese Änderung anzuwenden.

Wenn Sie AWS Backup PITR zum ersten Mal auf einer Amazon RDS-Instance aktivieren (indem Sie die Aufbewahrung von 0 auf einen Wert ungleich Null ändern), wird der Vorgang so geplant, dass er während des nächsten Wartungsfensters Ihrer Datenbank stattfindet, um unerwartete Ausfallzeiten zu vermeiden.

Szenarien:

  • First-time PITR-Aktivierung: Wenn PITR zum ersten Mal auf einer Amazon RDS-Instance aktiviert wird (unabhängig davon, ob sie von der Instance verwaltet AWS Backup oder direkt konfiguriert wird), wird die Änderung für das nächste Wartungsfenster in die Warteschlange gestellt. AWS Backup erstellt automatisch Snapshot-Backups, um die Abdeckung aufrechtzuerhalten, bis PITR aktiv wird.

  • PITR-Aufbewahrungsänderungen: Änderungen Non-zero , die von Null abweichen, gelten sofort und ohne Neustart.

  • PITR-Deaktivierung: Änderungen von einer Aufbewahrung ungleich Null auf Null sind für das nächste Wartungsfenster geplant.

Deckung durch Backups während der Umstellung:

  • Snapshot-Backups bieten Schutz, während Sie auf das Wartungsfenster warten

  • Kontinuierliche Wiederherstellungspunkte werden verfügbar, wenn der Backup-Job nach der Aktivierung von PITR ausgeführt wird

  • Während der Übergangsphase entsteht keine Lücke beim Backup-Schutz

  • Die Granularität der Wiederherstellung kann auf Snapshot-Intervalle beschränkt werden, bis PITR vollständig aktiv ist

Hinweis: Durch das Stoppen der RDS-Instance werden ausstehende Änderungen entfernt. Änderungen an der PITR-Konfiguration werden beim nächsten Backup-Job in die Warteschlange aufgenommen und in einem nachfolgenden Wartungsfenster angewendet.

Kopien der kontinuierlichen Amazon RDS-Backups:

  • Erstellen von Kopien kontinuierlicher Amazon RDS-Backups — Sie können keine Kopien von kontinuierlichen Amazon RDS-Backups erstellen, da AWS Backup Amazon RDS das Kopieren von Transaktionsprotokollen nicht zulässt. AWS Backup Erstellt stattdessen einen Snapshot und kopiert ihn mit der im Backup-Plan angegebenen Häufigkeit.

Wiederherstellungen: Sie können eine Point-in-Time-Wiederherstellung AWS Backup entweder mit Amazon RDS durchführen. Anweisungen für die AWS Backup Konsole finden Sie unter Wiederherstellen einer Amazon RDS-Datenbank. Anweisungen zu Amazon RDS finden Sie unter Wiederherstellen einer DB-Instance zu einer bestimmten Zeit im Amazon-RDS-Benutzerhandbuch.

Tipp

Bei einer Multi-AZ-Datenbank-Instance (Availability Zone), die auf eingestellt ist, Always On sollte die Backup-Aufbewahrung nicht auf Null gesetzt sein. Wenn Fehler auftreten, verwenden Sie AWS CLI den Befehl disassociate-recovery-point anstelle von delete-recovery-point und ändern Sie dann die Aufbewahrungseinstellung in Ihren Amazon RDS-Einstellungen auf 1.

Weitere Informationen zum Arbeiten mit Amazon RDS finden Sie im Amazon-RDS-Benutzerhandbuch.

CLI-Beispiele für die Wiederherstellung von RDS und Aurora PITR

Die folgenden Beispiele zeigen, wie RDS- und Aurora-Datenbanken mithilfe der AWS Backup CLI mit Metadatenparametern auf einen bestimmten Zeitpunkt wiederhergestellt werden.

Beispiel: Stellen Sie die RDS-Datenbank auf einen bestimmten Zeitpunkt mit Metadaten wieder her

aws backup start-restore-job \
    --recovery-point-arn arn:aws:backup:us-east-1:123456789012:recovery-point:1EB3B5E7-9EB0-435A-A80B-108B488B0D45 \
    --metadata '{"DBInstanceIdentifier":"restored-db-instance","Engine":"mysql","UseLatestRestorableTime":"false","RestoreTime":"2024-01-15T10:30:00Z"}' \
    --iam-role-arn arn:aws:iam::123456789012:role/service-role/AWSBackupDefaultServiceRole \
    --resource-type RDS \
    --copy-source-tags-to-restored-resource
Beispiel: Stellen Sie den Aurora-Cluster auf einen bestimmten Zeitpunkt wieder her

aws backup start-restore-job \
    --recovery-point-arn arn:aws:backup:us-east-1:123456789012:recovery-point:2FC4C6F8-0FC1-546B-B91C-209C599C1D56 \
    --metadata '{"DBClusterIdentifier":"restored-aurora-cluster","Engine":"aurora-mysql","UseLatestRestorableTime":"true"}' \
    --iam-role-arn arn:aws:iam::123456789012:role/service-role/AWSBackupDefaultServiceRole \
    --resource-type Aurora \
    --copy-source-tags-to-restored-resource
Metadaten-Parameter für die RDS-PITR-Wiederherstellung

Die folgenden Metadatenparameter werden für RDS- und Aurora-PITR-Wiederherstellungen unterstützt:

  • DBInstanceIdentifier(RDS) oder DBClusterIdentifier (Aurora) — Erforderlich. Der Name für die wiederhergestellte Datenbank.

  • Engine — Erforderlich. Die Datenbank-Engine (z. B. mysql, postgres, aurora-mysql, aurora-postgresql).

  • UseLatestRestorableTime- Fakultativ. Auf „true“ setzen, um den letzten wiederherstellbaren Zeitpunkt wiederherzustellen, oder auf „false“, um einen RestoreTime anzugeben.

  • RestoreTime- Fakultativ. Datum und Uhrzeit der Wiederherstellung (ISO 8601-Format). Erforderlich, wenn „falsch“ UseLatestRestorableTime ist.

Kopiert die Tags in die wiederhergestellte Ressource

Verwenden Sie das --copy-source-tags-to-restored-resource Flag, um Tags aus der Quelldatenbank in die wiederhergestellte Datenbank zu kopieren. Dadurch wird sichergestellt, dass die Tag-basierten Zugriffskontrollen und die Tags für die Kostenzuweisung beibehalten werden.

Vollständige Informationen zu den RDS PITR-Wiederherstellungsparametern finden Sie unter:

Aurora

Um ein kontinuierliches Backup Ihrer Aurora-Ressourcen zu aktivieren, folgen Sie den Schritten im ersten Abschnitt dieser Seite.

Das Verfahren zur Wiederherstellung eines Aurora-Clusters auf einen bestimmten Zeitpunkt ist eine Variante der Schritte zur Wiederherstellung eines Snapshots eines Aurora-Clusters.

Wenn Sie eine zeitpunktbezogene Wiederherstellung durchführen, zeigt die Konsole einen Abschnitt mit der Wiederherstellungszeit an. Weitere Informationen finden Sie unter Wiederherstellen eines kontinuierlichen Backups weiter unten auf dieser Seite unter Arbeiten mit kontinuierlichen Backups.

Wichtig

Kontinuierliche Aurora-Backups werden in durch AWS Backup Vault Lock geschützten Tresoren unterstützt, und die minimalen und maximalen Aufbewahrungseinstellungen des Tresors werden am Recovery-Punkt durchgesetzt. Kontinuierliche Aurora-Backups unterstützen jedoch nicht die Funktion „Logically Air-Gapped Vault“. Um einen Logically Airgapped Tresor mit Aurora zu verwenden, verwenden Sie stattdessen regelmäßige Snapshot-Backups.

Das Recovery Point Objective (RPO) für kontinuierliche Aurora-Backups beträgt in der Regel weniger als 5 Minuten, da Aurora Daten kontinuierlich im Hintergrund auf Amazon S3 kopiert. Verwenden Sie den LatestRestorableTime Wert, um den letzten Punkt zu ermitteln, an dem Sie die Wiederherstellung durchführen können.

Aufbewahrungsfristen und Backup-Fenster: Wenn Sie die Einstellungen für kontinuierliche Backups für einen Aurora-Cluster aktivieren oder AWS Backup ändern ModifyDBCluster, werden diese Änderungen aufgerufen. Dies kann die des Clusters ändernPreferredBackupWindow. Wenn im nächsten Wartungsfenster weitere Konfigurationsupdates anstehen, können durch die Aktivierung kontinuierlicher Backups auch diese ausstehenden Änderungen sofort übernommen werden.

Anmerkung

Um kontinuierliche Backups für Ihren Aurora-Cluster AWS Backup zu konfigurieren, stellen Sie sicher, dass die API-Berechtigung in der IAM-Rolle rds:ModifyDBCluster vorhanden ist, die in Ihrer Backup-Plan-Konfiguration definiert ist.

SAP HANA auf Amazon-EC2-Instances

Sie können kontinuierliche Backups erstellen, die mit zeitpunktbezogener Wiederherstellung (PITR) verwendet werden können (beachten Sie, dass On-Demand-Backups Ressourcen in dem Status bewahren, in dem sie erfasst werden, während PITR durch kontinuierliche Backups Veränderungen über einen bestimmten Zeitraum hinweg erfasst).

Mit kontinuierlichen Backups können Sie Ihre SAP-HANA-Datenbank auf einer EC2-Instance bis zu einem bestimmten, von Ihnen gewählten, Zeitpunkt zurückspulen, bis auf 1 Sekunde genau (innerhalb der letzten 35 Tage). Bei kontinuierlichen Backups wird zunächst ein vollständiges Backup Ihrer Ressource erstellt und anschließend die Transaktionsprotokolle Ihrer Ressource kontinuierlich gesichert. Bei der PITR-Wiederherstellung greifen Sie auf Ihr vollständiges Backup zu und spielen das Transaktionslog zu dem von Ihnen AWS Backup angegebenen Zeitpunkt erneut ab.

Sie können sich für kontinuierliche Backups entscheiden, wenn Sie AWS Backup mithilfe der AWS Backup Konsole oder der API einen Backup-Plan erstellen.

Aktivieren des kontinuierlichen Backups mithilfe der Konsole

  1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die AWS Backup Konsole unter https://console.aws.amazon.com/backup.

  2. Klicken Sie im Hauptnavigationsbereich auf Backup-Pläne und auf Backup-Plan erstellen.

  3. Wählen Sie unter Backup-Regeln die Option Backup-Regel hinzufügen aus.

  4. Wählen Sie im Abschnitt Konfiguration der Backup-Regeln die Option Fortlaufende Backups aktivieren für unterstützte Ressourcen aus.

Nachdem Sie die zeitpunktbezogene Wiederherstellung für SAP-HANA-Datenbank-Backups deaktiviert haben, werden weiterhin Protokolle an AWS Backup gesendet, bis der Wiederherstellungspunkt abläuft (Status entspricht EXPIRED)). Um die Übertragung der Protokolle an AWS Backup zu beenden, können Sie in SAP HANA einen alternativen Protokoll-Backup-Speicherort festlegen.

Ein kontinuierlicher Recovery-Punkt mit dem Status von STOPPED gibt an, dass ein kontinuierlicher Recovery-Punkt unterbrochen wurde. Das heißt, die Logs, die von SAP HANA übertragen wurden AWS Backup , zeigen, dass die inkrementellen Änderungen an einer Datenbank eine Lücke aufweisen. Die Wiederherstellungspunkte, die innerhalb dieser Zeitrahmenlücke auftreten, haben den Status STOPPED..

Informationen zu Problemen, die bei der Wiederherstellung kontinuierlicher Backups (Wiederherstellungspunkte) auftreten können, finden Sie im Abschnitt zur Problembehebung bei der Wiederherstellung von SAP HANA in diesem Handbuch.