Sichern und Wiederherstellen einer DB-Instance von Amazon RDS Custom for SQL Server - Amazon Relational Database Service
Erstellen eines Snapshots von RDS Custom for SQL ServerWiederherstellen von einem DB-Snapshot von RDS Custom for SQL ServerP-oint-in-time WiederherstellungLöschen eines Snapshots von RDS Custom for SQL ServerLöschen von automatisierten Backups von RDS Custom for SQL Server

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.

Sichern und Wiederherstellen einer DB-Instance von Amazon RDS Custom for SQL Server

Wie Amazon RDS erstellt RDS Custom automatisierte Backups Ihrer DB-Instance von RDS Custom für SQL Server und speichert diese, wenn die Aufbewahrung von Backups aktiviert ist. Sie können Ihre DB-Instance auch sichern, indem Sie manuell einen DB-Snapshot erstellen. Die automatisierten Backups bestehen aus Snapshot-Backups und Transaktionsprotokoll-Backups. Snapshot-Backups werden für das gesamte Speichervolumen der DB-Instance während des von Ihnen angegebenen Backup-Fensters erstellt. Transaktionsprotokoll-Backups werden für die PITR-fähigen Datenbanken in regelmäßigen Abständen erstellt. RDS Custom speichert die automatisierten Backups Ihrer DB-Instance gemäß dem von Ihnen angegebenen Aufbewahrungszeitraum für Backups. Sie können automatisierte Backups verwenden, um Ihre DB-Instance auf einen bestimmten Zeitpunkt innerhalb des Aufbewahrungszeitraums für Backups wiederherzustellen.

Sie können Snapshot-Backups auch manuell erstellen. Sie können aus diesen Snapshot-Backups jederzeit eine neue DB-Instance erstellen. Weitere Informationen zum manuellen Erstellen eines DB-Snapshots finden Sie unter Erstellen eines Snapshots von RDS Custom for SQL Server.

Snapshot-Backups dienen zwar betrieblich als vollständige Backups, Ihnen wird jedoch nur die inkrementelle Speichernutzung in Rechnung gestellt. Der erste Snapshot einer RDS Custom DB-Instance enthält die Daten der vollständigen DB-Instance. Bei den nachfolgenden Snapshots derselben Datenbank handelt es sich um inkrementelle Snapshots, d. h. es werden nur die Daten gespeichert, die sich seit der letzten Snapshot-Speicherung geändert haben.

Erstellen eines Snapshots von RDS Custom for SQL Server

RDS Custom for SQL Server erstellt einen Snapshot für das Speichervolume Ihrer DB-Instance, damit die gesamte DB-Instance gesichert wird und nicht nur einzelne Datenbanken. Wenn Sie einen Snapshot erstellen, geben Sie an, welche DB-Instance von RDS Custom for SQL Server gesichert werden soll. Geben Sie dann dem DB-Snapshot einen Namen, sodass über diesen eine Wiederherstellung zu einem späteren Zeitpunkt möglich ist.

Wenn Sie einen Snapshot erstellen, erstellt RDS Custom for SQL Server einen Amazon-EBS-Snapshot für Volume . Dabei handelt es sich um das Datenbank-Volume(D:), das an die DB-Instance angefügt ist. Damit Snapshots einfach mit einer bestimmten DB-Instance verknüpft werden können, werden sie mit DBSnapshotIdentifier, DbiResourceId und VolumeType getaggt.

Das Erstellen eines DB-Snapshots führt zu einer kurzen I/O-Suspendierung. Diese Suspendierung kann je nach Größe und Klasse Ihrer DB-Instance einige Sekunden bis einige Minuten dauern. Die Snapshot-Erstellungszeit variiert je nach Gesamtzahl und Größe Ihrer Datenbanken. Weitere Informationen zur Anzahl der Datenbanken, die für eine zeitpunktbezogene Wiederherstellung (PITR) in Frage kommen, finden Sie unter Anzahl der Datenbanken, die pro Instance-Klassentyp für PITR in Frage kommen.

Da der Snapshot das gesamte Speichervolume umfasst, wirkt sich die Größe von Dateien, wie z. B. temporäre Dateien, auch auf die Zeit aus, die zum Erstellen des Snapshots benötigt wird. Weitere Informationen zum Erstellen von Snapshots finden Sie unter Erstellen eines DB-Snapshots für eine Single-AZ-DB-Instance.

Erstellen Sie einen Snapshot von RDS Custom for SQL Server mit der Konsole oder der AWS CLI.

So erstellen Sie einen benutzerdefinierten RDS Snapshot

  1. Melden Sie sich bei der AWS Management Console an und öffnen Sie die Amazon RDS-Konsole unter https://console.aws.amazon.com/rds/.

  2. Wählen Sie im Navigationsbereich Datenbanken aus.

  3. Wählen Sie in der Liste der RDS Custom die DB-Instance, für die Sie einen Snapshot erstellen möchten.

  4. Wählen Sie für Aktionen die Option Take snapshot (Snapshot aufnehmen).

    Das Fenster Take DB Snapshot (DB-Snapshot erstellen) wird angezeigt.

  5. Geben Sie den Namen des Snapshots in das Feld Snapshot name (Snapshot-Name) ein.

  6. Wählen Sie Take Snapshot (Snapshot erstellen) aus.

Sie erstellen einen Snapshot einer RDS Custom DB-Instance mit dem create-db-snapshot AWS CLI Befehl .

Folgende Optionen stehen Ihnen zur Verfügung:

  • --db-instance-identifier — Identifiziert, welche RDS-DB-Instance Sie sichern werden

  • --db-snapshot-identifier — Benennt Ihren RDS-Snapshot, sodass Sie später wiederherstellen können

In diesem Beispiel erstellen Sie den DB-Snapshot my-custom-snapshot für die RDS Custom DB-Instance mit dem Namen my-custom-instance.

Für Linux, macOSoder Unix:

aws rds create-db-snapshot \
    --db-instance-identifier my-custom-instance \
    --db-snapshot-identifier my-custom-snapshot

Windows:

aws rds create-db-snapshot ^
    --db-instance-identifier my-custom-instance ^
    --db-snapshot-identifier my-custom-snapshot

Wiederherstellen von einem DB-Snapshot von RDS Custom for SQL Server

Wenn Sie eine DB-Instance von RDS Custom for SQL Server wiederherstellen, geben Sie den Namen des DB-Snapshots und einen Namen für die neue Instance an. Sie können nicht von einem Snapshot auf eine vorhandene RDS-DB-Instance wiederherstellen. Bei der Wiederherstellung wird eine neue DB-Instance von RDS Custom for SQL Server erstellt.

Beim Wiederherstellen aus einem Snapshot wird das Speichervolume zu dem Zeitpunkt wiederhergestellt, zu dem der Snapshot erstellt wurde. Dazu gehören alle Datenbanken und alle anderen Dateien, die auf dem (D:) Volume vorhanden waren.

Wiederherstellen einer RDS Custom DB-Instance aus einem DB-Snapshot

  1. Melden Sie sich bei der AWS Management Console an und öffnen Sie die Amazon-RDS-Konsole unter https://console.aws.amazon.com/rds/.

  2. Wählen Sie im Navigationsbereich die Option Snapshots.

  3. Wählen Sie den DB-Snapshot für die Wiederherstellung aus.

  4. Wählen Sie in Actions (Aktionen) die Option Restore Snapshot (Snapshot wiederherstellen) aus.

  5. Geben Sie auf der Seite Restore DB instance (DB-Instance wiederherstellen) unter DB-Instance-Kennung den Namen der wiederhergestellten RDS Custom Instance ein.

  6. Klicken Sie auf Restore DB Instance (DB-Instance wiederherstellen).

Sie stellen einen RDS Custom DB-Snapshot mit dem AWS CLI Befehl restore-db-instance-from-db-snapshot wieder her.

Wenn der Snapshot, von dem Sie wiederherstellen, für eine private DB-Instance bestimmt ist, geben Sie beide die richtigen db-subnet-group-name und no-publicly-accessible an. Andernfalls ist die DB-Instance standardmäßig öffentlich zugänglich. Die folgenden Optionen sind erforderlich:

  • db-snapshot-identifier — Identifiziert den Snapshot, aus dem wiederhergestellt werden soll

  • db-instance-identifier — Gibt den Namen der RDS Custom DB-Instance an, die aus dem DB-Snapshot erstellt werden soll

  • custom-iam-instance-profile – Gibt das Instance-Profil an, das mit der zugrunde liegenden Amazon-EC2-Instance einer RDS-Custom-DB-Instance verknüpft ist.

Der folgende Code stellt den Snapshot mit dem Namen my-custom-snapshot zu my-custom-instance her.

Für Linux, macOSoder Unix:

aws rds restore-db-instance-from-db-snapshot \
  --db-snapshot-identifier my-custom-snapshot \
  --db-instance-identifier my-custom-instance \
  --custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance \
  --no-publicly-accessible

Windows:

aws rds restore-db-instance-from-db-snapshot ^
  --db-snapshot-identifier my-custom-snapshot ^
  --db-instance-identifier my-custom-instance ^
  --custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance ^
  --no-publicly-accessible

Wiederherstellen einer Instance von RDS Custom for SQL Server auf einen bestimmten Zeitpunkt

Sie können eine DB-Instanceeinen DB-Cluster zu einem bestimmten Zeitpunkt wiederherstellen, indem Sie eine neue DB-Instanceeinen neuen DB-Cluster erstellen. Um PITR zu unterstützen, muss für Ihre DB-Instances die Aufbewahrung von Backups aktiviert sein.

Die späteste wiederherstellbare Zeit für eine DB-Instance von RDS Custom for SQL Server hängt von mehreren Faktoren ab, liegt jedoch normalerweise innerhalb von 5 Minuten vor dem aktuellen Zeitpunkt. Um die neueste wiederherstellbare Zeit für eine DB-Instance anzuzeigen, verwenden Sie den -AWS CLIdescribe-db-instancesBefehl und sehen Sie sich den Wert an, der im LatestRestorableTime Feld für die DB-Instance zurückgegeben wird. Um die neueste Wiederherstellungszeit für jede DB-Instance in der Amazon RDS-Konsole anzuzeigen, wählen Sie Automatische Backups.

Sie können die Backup auf jeden beliebigen Zeitpunkt innerhalb des Aufbewahrungszeitraums für Backups vornehmen. Um den frühesten wiederherstellbaren Zeitpunkt für jede DB-Instance anzuzeigen, wählen Sie Automatische Backups in der Amazon RDS-Konsole aus.

Allgemeine Informationen zu PITR finden Sie unter Wiederherstellen einer DB-Instance zu einer bestimmten Zeit.

Überlegungen zu PITRs für RDS Custom for SQL Server

In RDS Custom for SQL Server unterscheidet sich PITR in folgenden wichtigen Weisen von PITR in Amazon RDS:

  • PITR stellt nur die Datenbanken in der DB-Instance wieder her. Es stellt das Betriebssystem oder die Dateien auf dem Laufwerk C: nicht wieder her.

  • Für eine RDS Custom for SQL Server DB-Instance wird eine Datenbank automatisch gesichert und ist nur unter den folgenden Bedingungen für PITR berechtigt:

    • Die Datenbank ist online.

    • Sein Wiederherstellungsmodell ist auf FULL gesetzt.

    • Es ist beschreibbar.

    • Es hat seine physischen Dateien auf dem Laufwerk D:.

    • Sie ist nicht in der rds_pitr_blocked_databases-Tabelle aufgeführt. Weitere Informationen finden Sie unter Datenbanken für PITR nicht berechtigt machen.

  • Die Datenbanken, die für PITR in Frage kommen, werden durch die Reihenfolge ihrer Datenbank-ID bestimmt. RDS Custom for SQL Server erlaubt bis zu 5 000 Datenbanken pro DB-Instance. Die maximale Anzahl von Datenbanken, die durch eine PITR-Operation für eine DB-Instance von RDS Custom für SQL Server wiederhergestellt werden, hängt jedoch vom Instance-Klassentyp ab. Weitere Informationen finden Sie unter Anzahl der Datenbanken, die pro Instance-Klassentyp für PITR in Frage kommen.

    Andere Datenbanken, die nicht Teil von PITR sind, können aus DB-Snapshots wiederhergestellt werden, einschließlich der automatisierten Snapshot-Backups, die für PITR verwendet werden.

  • Das Hinzufügen einer neuen Datenbank, das Umbenennen einer Datenbank oder das Wiederherstellen einer Datenbank, die für PITR berechtigt ist, initiiert einen Snapshot der DB-Instance.

  • Die maximale Anzahl von Datenbanken, die für PITR in Frage kommen, ändert sich je nach Klassentyp der Ziel-Instance, wenn die Datenbank-Instance eine Skalierungsberechnung durchläuft. Wenn die Instance hochskaliert wird, sodass mehr Datenbanken auf der Instance für PITR in Frage kommen, wird ein neuer Snapshot erstellt.

  • Wiederhergestellte Datenbanken haben denselben Namen wie in der Quell-DB-Instance. Wenn Sie möchten, können Sie einen anderen Namen eingeben.

  • AWSRDSCustomSQLServerIamRolePolicy erfordert Zugriff auf andere -AWSServices. Weitere Informationen finden Sie unter Fügen Sie eine Zugriffsrichtlinie hinzu zu AWSRDSCustomSQLServerInstanceRole.

  • Zeitzonenänderungen werden für RDS Custom for SQL Server nicht unterstützt. Wenn Sie die Zeitzone des Betriebssystems oder der DB-Instance ändern, funktioniert PITR (und andere Automatisierung) nicht.

Anzahl der Datenbanken, die pro Instance-Klassentyp für PITR in Frage kommen

Die folgende Tabelle zeigt die maximale Anzahl von Datenbanken, die basierend auf dem Instance-Klassentyp für PITR berechtigt sind.

Typ der Instance-Klasse Maximale Anzahl von PITR-fähigen Datenbanken
db.*.large 100
db.*.xlarge zu db.*.2xlarge 150
db.*.4xlarge zu db.*.8xlarge 300
db.*.12xlarge zu db.*.16xlarge 600
db.*.24xlarge, db.*32xlarge 1000

* Stellt verschiedene Instance-Klassentypen dar.

Die maximale Anzahl von Datenbanken, die für PITR in einer DB-Instance in Frage kommen, hängt vom Instance-Klassentyp ab. Die Zahl reicht von 100 auf der kleinsten bis 1000 auf den größten Instance-Klassentypen, die von RDS Custom für SQL Server unterstützt werden. SQL Server-Systemdatenbanken (master, model, msdb, tempdb), sind nicht in diesem Limit enthalten. Wenn eine DB-Instance je nach Ziel-Instance-Klassentyp hoch- oder herunterskaliert wird, aktualisiert RDS Custom automatisch die Anzahl der Datenbanken, die für PITR in Frage kommen. RDS Custom für SQL Server sendet RDS-EVENT-0352, wenn sich die maximale Anzahl von Datenbanken, die für PITR in Frage kommen, auf einer DB-Instance ändert. Weitere Informationen finden Sie unter Benutzerdefinierte Engine-Versionsereignisse.

Anmerkung

Die PITR-Unterstützung für mehr als 100 Datenbanken ist nur für DB-Instances verfügbar, die nach dem 26. August 2023 erstellt wurden. Für Instances, die vor dem 26. August 2023 erstellt wurden, beträgt die maximale Anzahl von Datenbanken, die für PITR in Frage kommen, unabhängig von der Instance-Klasse 100. Um PITR-Unterstützung für mehr als 100 Datenbanken auf DB-Instances zu aktivieren, die vor dem 26. August 2023 erstellt wurden, können Sie die folgende Aktion ausführen:

  • Aktualisieren Sie die DB-Engine-Version auf 15.00.4322.2.v1 oder höher

Während eines PITR-Vorgangs stellt RDS Custom alle Datenbanken wieder her, die Teil von PITR waren, und zwar zum Zeitpunkt der Wiederherstellung auf der Quell-DB-Instance. Sobald die Ziel-DB-Instance Wiederherstellungsvorgänge abgeschlossen hat und die Aufbewahrung von Backups aktiviert ist, beginnt die DB-Instance mit der Sicherung basierend auf der maximalen Anzahl von Datenbanken, die für PITR auf der Ziel-DB-Instance in Frage kommen.

Wenn Ihre DB-Instance beispielsweise auf einem mit 200 Datenbanken ausgeführt db.*.xlarge wird:

  1. RDS Custom für SQL Server wählt die ersten 150 Datenbanken, geordnet nach ihrer Datenbank-ID, für die PITR-Sicherung aus.

  2. Sie ändern die Instance so, dass sie auf db.*.4xlarge hochskaliert wird.

  3. Sobald der Skalierungs-Datenverarbeitungsvorgang abgeschlossen ist, wählt RDS Custom für SQL Server die ersten 300 Datenbanken, geordnet nach ihrer Datenbank-ID, für PITR-Backup aus. Jede der 200 Datenbanken, die die PITR-Anforderungsbedingungen erfüllen, ist jetzt für PITR berechtigt.

  4. Sie ändern jetzt die Instance so, dass sie wieder auf db.*.xlarge herunterskaliert wird.

  5. Sobald der Skalierungs-Datenverarbeitungsvorgang abgeschlossen ist, wählt RDS Custom für SQL Server erneut die ersten 150 Datenbanken aus, geordnet nach ihrer Datenbank-ID, für die PITR-Sicherung.

Datenbanken für PITR nicht berechtigt machen

Sie können einzelne Datenbanken von PITR ausschließen. Um dies zu tun, legen Sie ihre database_id-Werte in eine rds_pitr_blocked_databases-Tabelle. Verwenden Sie den folgenden -Befehl, um die Tabelle zu erstellen.

So erstellen Sie die Tabelle „rds_pitr_blocked_databases“

  • Führen Sie das folgende Skript aus.

    create table msdb..rds_pitr_blocked_databases
(
database_id INT NOT NULL,
database_name SYSNAME NOT NULL,
db_entry_updated_date datetime NOT NULL DEFAULT GETDATE(),
db_entry_updated_by SYSNAME NOT NULL DEFAULT CURRENT_USER,
PRIMARY KEY (database_id)
);

Eine Liste der berechtigten und nicht berechtigten Datenbanken finden Sie in der RI.End-Datei im RDSCustomForSQLServer/Instances/DB_instance_resource_ID/TransactionLogMetadata-Verzeichnis im Amazon S3-Bucket do-not-delete-rds-custom-$ACCOUNT_ID-$REGION-unique_identifier. Weitere Informationen zur Datei RI.End finden Sie unter Transaktionsprotokolle in Amazon S3.

Sie können die Liste der berechtigten Datenbanken für PITR auch mithilfe des folgenden SQL-Skripts ermitteln. Legen Sie die @limit Variable auf die maximale Anzahl von Datenbanken in fest, die für PITR für die Instance-Klasse berechtigt sind. Weitere Informationen finden Sie unter Anzahl der Datenbanken, die pro Instance-Klassentyp für PITR in Frage kommen.

So ermitteln Sie die Liste der berechtigten Datenbanken für PITR in einer DB-Instance-Klasse

  • Führen Sie das folgende Skript aus.

    DECLARE @Limit INT;
SET @Limit = (insert-database-instance-limit-here);

USE msdb;
IF (EXISTS (SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'dbo' AND  TABLE_NAME = 'rds_pitr_blocked_databases'))
    WITH TABLE0 AS (
        SELECT hdrs.database_id as DatabaseId, sdb.name as DatabaseName, 'ALWAYS_ON_NOT_WRITABLE_REPLICA' as Reason, NULL as DatabaseNameOnPitrTable
        FROM sys.dm_hadr_database_replica_states hdrs
        INNER JOIN sys.databases sdb ON sdb.database_id = hdrs.database_id
        WHERE (hdrs.is_local = 1 AND hdrs.is_primary_replica = 0) 
        OR (sys.fn_hadr_is_primary_replica (sdb.name) = 1 AND DATABASEPROPERTYEX (sdb.name, 'Updateability') = 'READ_ONLY')
    ),
    TABLE1 as (
            SELECT dbs.database_id as DatabaseId, sysdbs.name as DatabaseName, 'OPTOUT' as Reason,
            CASE WHEN dbs.database_name = sysdbs.name THEN NULL ELSE dbs.database_name END AS DatabaseNameOnPitrTable
            FROM msdb.dbo.rds_pitr_blocked_databases dbs
            INNER JOIN sys.databases sysdbs ON dbs.database_id = sysdbs.database_id
            WHERE sysdbs.database_id > 4
            ),
    TABLE2 as (
            SELECT
            db.name AS DatabaseName,
            db.create_date AS CreateDate,
            db.state_desc AS DatabaseState,
            db.database_id AS DatabaseId,
            rs.database_guid AS DatabaseGuid,
            rs.last_log_backup_lsn AS LastLogBackupLSN,
            rs.recovery_fork_guid RecoveryForkGuid,
            rs.first_recovery_fork_guid AS FirstRecoveryForkGuid,
            db.recovery_model_desc AS RecoveryModel,
            db.is_auto_close_on AS IsAutoClose,
            db.is_read_only as IsReadOnly,
            NEWID() as FileName,
            CASE WHEN(db.state_desc = 'ONLINE'
                    AND db.recovery_model_desc != 'SIMPLE' 
                    AND((db.is_auto_close_on = 0 and db.collation_name IS NOT NULL) OR db.is_auto_close_on = 1)) 
                    AND db.is_read_only != 1
                    AND db.user_access = 0
                    AND db.source_database_id IS NULL
                    AND db.is_in_standby != 1
                    THEN 1 ELSE 0 END AS IsPartOfSnapshot,
            CASE WHEN db.source_database_id IS NULL THEN 0 ELSE 1 END AS IsDatabaseSnapshot
            FROM sys.databases db
            INNER JOIN sys.database_recovery_status rs
            ON db.database_id = rs.database_id
            WHERE DB_NAME(db.database_id) NOT IN('tempdb') AND
            db.database_id NOT IN (SELECT DISTINCT DatabaseId FROM TABLE1) AND
            db.database_id NOT IN (SELECT DISTINCT DatabaseId FROM TABLE0)
        ),
        TABLE3 as(
            Select @Limit+count(DatabaseName) as TotalNumberOfDatabases from TABLE2 where TABLE2.IsPartOfSnapshot=1 and DatabaseName in ('master','model','msdb')
        )
        SELECT TOP(SELECT TotalNumberOfDatabases from TABLE3)  DatabaseName,CreateDate,DatabaseState,DatabaseId from TABLE2 where TABLE2.IsPartOfSnapshot=1
        ORDER BY TABLE2.DatabaseID ASC
ELSE
    WITH TABLE0 AS (
        SELECT hdrs.database_id as DatabaseId, sdb.name as DatabaseName, 'ALWAYS_ON_NOT_WRITABLE_REPLICA' as Reason, NULL as DatabaseNameOnPitrTable
        FROM sys.dm_hadr_database_replica_states hdrs
        INNER JOIN sys.databases sdb ON sdb.database_id = hdrs.database_id
        WHERE (hdrs.is_local = 1 AND hdrs.is_primary_replica = 0) 
        OR (sys.fn_hadr_is_primary_replica (sdb.name) = 1 AND DATABASEPROPERTYEX (sdb.name, 'Updateability') = 'READ_ONLY')
    ),
    TABLE1 as (
            SELECT
            db.name AS DatabaseName,
            db.create_date AS CreateDate,
            db.state_desc AS DatabaseState,
            db.database_id AS DatabaseId,
            rs.database_guid AS DatabaseGuid,
            rs.last_log_backup_lsn AS LastLogBackupLSN,
            rs.recovery_fork_guid RecoveryForkGuid,
            rs.first_recovery_fork_guid AS FirstRecoveryForkGuid,
            db.recovery_model_desc AS RecoveryModel,
            db.is_auto_close_on AS IsAutoClose,
            db.is_read_only as IsReadOnly,
            NEWID() as FileName,
            CASE WHEN(db.state_desc = 'ONLINE'
                    AND db.recovery_model_desc != 'SIMPLE' 
                    AND((db.is_auto_close_on = 0 and db.collation_name IS NOT NULL) OR db.is_auto_close_on = 1)) 
                    AND db.is_read_only != 1
                    AND db.user_access = 0
                    AND db.source_database_id IS NULL
                    AND db.is_in_standby != 1
                    THEN 1 ELSE 0 END AS IsPartOfSnapshot,
            CASE WHEN db.source_database_id IS NULL THEN 0 ELSE 1 END AS IsDatabaseSnapshot
            FROM sys.databases db
            INNER JOIN sys.database_recovery_status rs
            ON db.database_id = rs.database_id
            WHERE DB_NAME(db.database_id) NOT IN('tempdb') AND
            db.database_id NOT IN (SELECT DISTINCT DatabaseId FROM TABLE0)
        ),
        TABLE2 as(
            SELECT @Limit+count(DatabaseName) as TotalNumberOfDatabases from TABLE1 where TABLE1.IsPartOfSnapshot=1 and DatabaseName in ('master','model','msdb')
        )
        select top(select TotalNumberOfDatabases from TABLE2)  DatabaseName,CreateDate,DatabaseState,DatabaseId from TABLE1 where TABLE1.IsPartOfSnapshot=1
        ORDER BY TABLE1.DatabaseID ASC
Anmerkung

Die Datenbanken, die nur symbolische Links sind, werden auch von Datenbanken ausgeschlossen, die für PITR-Operationen in Frage kommen. Die obige Abfrage filtert nicht basierend auf diesen Kriterien.

Transaktionsprotokolle in Amazon S3

Der Aufbewahrungszeitraum für Backups bestimmt, ob Transaktionsprotokolle für RDS Custom for SQL Server DB-Instanzen automatisch extrahiert und auf Amazon S3 hochgeladen werden. Ein Wert ungleich Null bedeutet, dass automatische Backups erstellt werden und der RDS Custom Agent die Transaktionsprotokolle alle 5 Minuten auf S3 hochlädt.

Transaktionsprotokolldateien auf S3 werden im Ruhezustand mit dem AWS KMS key die Sie angegeben haben, als Sie Ihre DB-Instance erstellt haben. Weitere Informationen finden Sie unter Schutz von Daten durch serverseitige Verschlüsselung im Amazon Simple Storage Service User Guide.

Die Transaktionsprotokolle für jede Datenbank werden in einen S3-Bucket namens do-not-delete-rds-custom-$ACCOUNT_ID-$REGION-unique_identifier hochgeladen. Das RDSCustomForSQLServer/Instances/DB_instance_resource_ID-Verzeichnis im S3-Bucket enthält zwei Unterverzeichnisse:

  • TransactionLogs — Enthält die Transaktionsprotokolle für jede Datenbank und ihre jeweiligen Metadaten.

    Der Name der Transaktionslog-Datei folgt dem Muster yyyyMMddHHmm.database_id.timestamp, Beispiel:

    202110202230.11.1634769287

    Derselbe Dateiname mit dem Suffix _metadata enthält Informationen über das Transaktionslog wie Log-Sequenznummern, Datenbankname und RdsChunkCount. RdsChunkCountbestimmt, wie viele physische Dateien eine einzelne Transaktionslogdatei darstellen. Möglicherweise sehen Sie Dateien mit Suffixen _0001, _0002 und so weiter, was die physischen Teile einer Transaktionslogdatei bedeutet. Wenn Sie eine Chunked Transaktionslogdatei verwenden möchten, müssen Sie die Chunks nach dem Herunterladen zusammenführen.

    Betrachten Sie ein Szenario, in dem Sie folgende Dateien haben:

    • 202110202230.11.1634769287

    • 202110202230.11.1634769287_0001

    • 202110202230.11.1634769287_0002

    • 202110202230.11.1634769287_metadata

    Das RdsChunkCount ist 3. Die Reihenfolge zum Zusammenführen der Dateien ist die folgende: 202110202230.11.1634769287, 202110202230.11.1634769287_0001, 202110202230.11.1634769287_0002.

  • TransactionLogMetadata — Enthält Metadateninformationen über jede Iteration der Transaktionslog-Extraktion.

    Die RI.End enthält Informationen für alle Datenbanken, deren Transaktionsprotokolle extrahiert wurden, und für alle Datenbanken, die vorhanden sind, aber ihre Transaktionsprotokolle nicht extrahiert wurden. Der RI.End-Dateiname folgt dem Muster yyyyMMddHHmm.RI.End.timestamp, Beispiel:

    202110202230.RI.End.1634769281

PITR-Wiederherstellung mit der AWS Management Console, der AWS CLIoder der RDS-API.

Sie können eine DB-Instance von RDS Custom for SQL Server mit der AWS Management Console, der AWS CLI oder der RDS-API auf einen bestimmten Zeitpunkt wiederherstellen.

Wiederherstellen einer DB-Instance eines RDS Custom zu einer bestimmten Zeit

  1. Melden Sie sich bei der AWS Management Console an und öffnen Sie die Amazon-RDS-Konsole unter https://console.aws.amazon.com/rds/.

  2. Wählen Sie im Navigationsbereich Automated backups (Automatisierte Backups) aus.

  3. Wählen Sie die RDS Custom DB-Instance aus, die Sie wiederherstellen möchten.

  4. Wählen Sie unter Aktionen die Option Restore to point in time (Zu einem bestimmten Zeitpunkt wiederherstellen) aus.

    Anschließend wird das Fenster Restore to point in time (Zu einem bestimmten Zeitpunkt wiederherstellen) angezeigt.

  5. Wählen Sie Späteste Wiederherstellungszeit, um auf den spätesten möglichen Zeitpunkt wiederherzustellen oder wählen Sie Benutzerdefiniert, um eine Zeit auszuwählen.

    Geben Sie bei der Auswahl von Custom das Datum und die Uhrzeit ein, zu der Sie den Instance-Cluster wiederherstellen möchten.

    Zeiten werden in Ihrer lokalen Zeitzone angezeigt, die durch einen Offset von Coordinated Universal Time (UTC) angezeigt wird. Beispiel: UTC-5 ist Ost Standardzeit/Zentral Sommerzeit.

  6. Geben Sie für DB-Instance-Kennung den Namen der wiederhergestellten RDS Custom DB-Ziel-Instance ein. Der Name muss eindeutig sein.

  7. Wählen Sie bei Bedarf andere Optionen aus, z. B. DB-Instance-Class.

  8. Wählen Sie Restore to point in time (Zu einem bestimmten Zeitpunkt wiederherstellen) aus.

Sie stellen eine DB-Instance zu einer bestimmten Zeit wieder her, indem Sie den AWS CLI Befehl restore-db-instance-to-point-in-time verwenden, um eine neue RDS Custom DB-Instance zu erstellen.

Verwenden Sie eine der folgenden Optionen, um die Sicherung anzugeben, von der wiederhergestellt werden soll:

  • --source-db-instance-identifier mysourcedbinstance

  • --source-dbi-resource-id dbinstanceresourceID

  • --source-db-instance-automated-backups-arn backupARN

Die Option custom-iam-instance-profile ist erforderlich.

Der folgende Befehl stellt my-custom-db-instance auf eine neue DB-Instance namens my-restored-custom-db-instance wieder her, und zwar zum angegebenen Zeitpunkt.

Für Linux, macOSoder Unix:

aws rds restore-db-instance-to-point-in-time \
    --source-db-instance-identifier my-custom-db-instance\
    --target-db-instance-identifier my-restored-custom-db-instance \
    --custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance \
    --restore-time 2022-10-14T23:45:00.000Z

Windows:

aws rds restore-db-instance-to-point-in-time ^
    --source-db-instance-identifier my-custom-db-instance ^
    --target-db-instance-identifier my-restored-custom-db-instance ^
    --custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance ^
    --restore-time 2022-10-14T23:45:00.000Z

Löschen eines Snapshots von RDS Custom for SQL Server

Sie können DB-Snapshots löschen, die mit RDS Custom for SQL Server verwaltet werden, wenn Sie sie nicht mehr benötigen. Der Löschvorgang ist sowohl für Amazon RDS- als auch für RDS Custom DB-Instanzen identisch.

Die Amazon-EBS-Snapshots für die Binär- und Root-Volumes bleiben länger in Ihrem Konto, da sie möglicherweise mit einigen Instances verknüpft sind, die in Ihrem Konto oder mit anderen Snapshots von RDS Custom for SQL Server ausgeführt werden. Diese EBS-Snapshots werden automatisch gelöscht, nachdem sie nicht mehr mit vorhandenen Ressourcen von RDS Custom for SQL Server (DB-Instances oder Backups) in Verbindung stehen.

So löschen Sie einen Snapshot Ihrer RDS-DB-Instance

  1. Melden Sie sich bei der AWS Management Console an und öffnen Sie die Amazon-RDS-Konsole unter https://console.aws.amazon.com/rds/.

  2. Wählen Sie im Navigationsbereich die Option Snapshots.

  3. Wählen Sie den DB-Snapshot aus, den Sie löschen möchten.

  4. Wählen Sie unter Actions (Aktionen) die Option Delete Snapshot (Snapshot löschen) aus.

  5. Wählen Sie auf der Bestätigungsseite die Option Delete (Löschen) aus.

Verwenden Sie den AWS CLI Befehl , um einen benutzerdefinierten RDS-Snapshot zu löschendelete-db-snapshot.

Die folgenden Optionen sind erforderlich:

  • --db-snapshot-identifier — Der zu löschende Snapshot

Das folgende Beispiel löscht den Cluster-Snapshot my-custom-snapshot.

Für Linux, macOSoder Unix:

aws rds delete-db-snapshot \  
  --db-snapshot-identifier my-custom-snapshot

Windows:

aws rds delete-db-snapshot ^
  --db-snapshot-identifier my-custom-snapshot

Löschen von automatisierten Backups von RDS Custom for SQL Server

Sie können aufbewahrte automatisierte Backups für RDS Custom for SQL Server löschen, wenn sie nicht mehr benötigt werden. Das Verfahren entspricht dem Verfahren zum Löschen von Amazon RDS-Backups.

So löschen Sie eine aufbewahrte automatisierte Backup:

  1. Melden Sie sich bei der AWS Management Console an und öffnen Sie die Amazon-RDS-Konsole unter https://console.aws.amazon.com/rds/.

  2. Wählen Sie im Navigationsbereich Automated backups (Automatisierte Backups) aus.

  3. Wählen Sie Retained (Aufbewahrt).

  4. Wählen Sie die aufbewahrte automatisierte Sicherung, die Sie löschen möchten.

  5. Klicken Sie bei Actions auf Delete.

  6. Geben Sie auf der Bestätigungsseite delete me und wählen Sie Löschen aus.

Sie können ein aufbewahrtes automatisiertes Backup mit dem AWS CLI Befehl delete-db-instance-automated-backup löschen.

Zum Löschen einer aufbewahrten automatisierten Sicherung werden die folgenden Optionen verwendet.

  • --dbi-resource-id – Die Ressourcenkennung für die Quell-RDS-Custom-DB-Instance.

    Sie finden die Ressourcenkennung für die Quell-DB-Instance eines beibehaltenen automatisierten Backups mithilfe des AWS CLI Befehls describe-db-instance-automated-Backups .

Im folgenden Beispiel wird das aufbewahrte automatisierte Backup mit der Quell-DB-Instance-Ressourcenkennung custom-db-123ABCEXAMPLE gelöscht.

Für Linux, macOSoder Unix:

aws rds delete-db-instance-automated-backup \
    --dbi-resource-id custom-db-123ABCEXAMPLE

Windows:

aws rds delete-db-instance-automated-backup ^
    --dbi-resource-id custom-db-123ABCEXAMPLE