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 für 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 für Sicherungen 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. In regelmäßigen Abständen werden Transaktionsprotokoll-Backups für die PITR-fähigen Datenbanken erstellt. RDS Custom speichert die automatischen Backups Ihrer DB-Instance gemäß der angegebenen Aufbewahrungsfrist für Backups. Sie können automatisierte Backups verwenden, um Ihre DB-Instance auf einen Zeitpunkt innerhalb des Aufbewahrungszeitraums für Backups wiederherzustellen.
Sie können Snapshot-Backups auch manuell erstellen. Sie können eine neue DB-Instance aus diesen Snapshot-Backups erstellen. Weitere Informationen zum manuellen Erstellen eines DB-Snapshots finden Sie unter [Erstellen eines Snapshots von RDS Custom für SQL Server](custom-backup-sqlserver.creating.md).
Obwohl Snapshot-Backups betrieblich als vollständige Backups fungieren, werden Ihnen nur die inkrementellen Speichernutzungen 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.
**Topics**
+ [Erstellen eines Snapshots von RDS Custom für SQL Server](custom-backup-sqlserver.creating.md)
+ [Wiederherstellen von einem DB-Snapshot von RDS Custom für SQL Server](custom-backup-sqlserver.restoring.md)
+ [Wiederherstellen einer Instance von RDS Custom für SQL Server auf einen bestimmten Zeitpunkt](custom-backup.pitr-sqs.md)
+ [Löschen eines Snapshots von RDS Custom für SQL Server](custom-backup-sqlserver.deleting.md)
+ [Löschen von automatisierten Backups von RDS Custom für SQL Server](custom-backup-sqlserver.deleting-backups.md)
# Erstellen eines Snapshots von RDS Custom für SQL Server
RDS Custom für 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 für 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 für SQL Server einen Amazon-EBS-Snapshot für Volume `(D:)`, das das Datenbank-Volume ist, das der 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 Erstellungszeit für Snapshots variiert je nach Gesamtanzahl und Größe Ihrer Datenbank. Weitere Informationen zur Anzahl der Datenbanken, die für eine Wiederherstellung zu einem bestimmten Zeitpunkt (PITR) in Frage kommen, finden Sie unter [Anzahl der Datenbanken, die für PITR in Frage kommen, pro Instance-Klassentyp](custom-backup.pitr-sqs.md#custom-backup.pitr.sqlserver.eligiblecountperinstance).
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 DB-Instance mit Single-AZ für Amazon RDS](USER_CreateSnapshot.md).
Erstellen Sie einen Snapshot von RDS Custom für SQL Server mit der Konsole oder der AWS CLI.
## Konsole
**So erstellen Sie einen benutzerdefinierten RDS Snapshot**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Datenbanken** aus.
1. Wählen Sie in der Liste der RDS Custom die DB-Instance, für die Sie einen Snapshot erstellen möchten.
1. Wählen Sie für **Aktionen** die Option **Take snapshot (Snapshot aufnehmen)**.
Das Fenster **Take DB Snapshot (DB-Snapshot erstellen)** wird angezeigt.
1. Geben Sie den Namen des Snapshots in das Feld **Snapshot name (Snapshot-Name)** ein.
1. Wählen Sie **Take Snapshot (Snapshot erstellen)** aus.
## AWS CLI
Sie erstellen einen Snapshot Ihrer RDS Custom DB-Instance unter Verwendung des [erstellen-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-snapshot.html) AWS CLI-Befehls.
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`.
**Example**
Für Linux, macOS oder Unix:
```
1. aws rds create-db-snapshot \
2. --db-instance-identifier my-custom-instance \
3. --db-snapshot-identifier my-custom-snapshot
```
Windows:
```
1. aws rds create-db-snapshot ^
2. --db-instance-identifier my-custom-instance ^
3. --db-snapshot-identifier my-custom-snapshot
```
# Wiederherstellen von einem DB-Snapshot von RDS Custom für SQL Server
Wenn Sie eine DB-Instance von RDS Custom für 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 für SQL Server erstellt.
Bei der Wiederherstellung aus einem Snapshot wird das Speicher-Volume auf den Zeitpunkt zurückgesetzt, zu dem der Snapshot erstellt wurde. Dies schließt alle Datenbanken und alle anderen Dateien ein, die auf dem Volume `(D:)` vorhanden waren.
## Konsole
**Wiederherstellen einer RDS Custom DB-Instance aus einem DB-Snapshot**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich die Option **Snapshots**.
1. Wählen Sie den DB-Snapshot für die Wiederherstellung aus.
1. Wählen Sie in **Actions (Aktionen)** die Option **Restore Snapshot (Snapshot wiederherstellen)** aus.
1. Geben Sie auf der Seite **Restore DB instance** (DB-Instance wiederherstellen) unter **DB-Instance-Kennung** den Namen der wiederhergestellten RDS Custom Instance ein.
1. Klicken Sie auf **Restore DB Instance** (DB-Instance wiederherstellen).
## AWS CLI
Sie stellen einen RDS Custom DB-Snapshot wieder her, indem Sie den [restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) AWS CLI-Befehl nutzen.
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.
**Example**
Für Linux, macOS oder 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 für 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 Sicherheitsaufbewahrung aktiviert sein.
Die späteste wiederherstellbare Zeit für eine DB-Instance von RDS Custom für SQL Server hängt von mehreren Faktoren ab, liegt jedoch normalerweise innerhalb von 5 Minuten vor dem aktuellen Zeitpunkt. Um den letzten wiederherstellbaren Zeitpunkt für eine DB-Instance zu ermitteln, verwenden Sie den AWS CLI [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)Befehl und sehen Sie sich den Wert an, der im `LatestRestorableTime` Feld für die DB-Instance zurückgegeben wurde. 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 auf einen bestimmten Zeitpunkt für Amazon RDS](USER_PIT.md).
**Topics**
+ [Überlegungen zu PITRs für RDS Custom für SQL Server](#custom-backup.pitr.sqlserver)
+ [Anzahl der Datenbanken, die für PITR in Frage kommen, pro Instance-Klassentyp](#custom-backup.pitr.sqlserver.eligiblecountperinstance)
+ [Datenbanken für PITR nicht berechtigt machen](#custom-backup.pitr.sqlserver.ineligible)
+ [Transaktionsprotokolle in Amazon S3](#custom-backup.pitr.sqlserver.tlogs)
+ [PITR Restore mit der, der oder der RDS-API. AWS-Managementkonsole AWS CLI](#custom-backup.pitr-sqs-concli)
## Überlegungen zu PITRs für RDS Custom für SQL Server
In RDS Custom für 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 für 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](#custom-backup.pitr.sqlserver.ineligible).
+ Die Datenbanken, die für PITR in Frage kommen, werden durch die Reihenfolge ihrer Datenbank-ID bestimmt. RDS Custom für SQL Server erlaubt bis zu 5 000 Datenbanken pro DB-Instance. Die maximale Anzahl von Datenbanken, die durch einen PITR-Vorgang für eine RDS-Custom-for-SQL-Server-DB-Instance wiederhergestellt werden, hängt vom Instance-Klassentyp ab. Weitere Informationen finden Sie unter [Anzahl der Datenbanken, die für PITR in Frage kommen, pro Instance-Klassentyp](#custom-backup.pitr.sqlserver.eligiblecountperinstance).
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 einen Skalierungsberechnungsvorgang 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 AWS Dienste. Weitere Informationen finden Sie unter [Fügen Sie eine Zugriffsrichtlinie hinzu zu AWSRDSCustom SQLServer InstanceRole](custom-setup-sqlserver.md#custom-setup-sqlserver.iam.add-policy).
+ Zeitzonenänderungen werden für RDS Custom für 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 für PITR in Frage kommen, pro Instance-Klassentyp
Die folgende Tabelle zeigt die maximale Anzahl von Datenbanken, die für PITR-Anwendungen in Frage kommen, basierend auf dem Instance-Klassentyp.
| Typ der Instance-Klasse | Maximale Anzahl der Datenbanken, die für PITR in Frage kommen |
| --- | --- |
| db.\$1.large | 100 |
| db.\$1.xlarge zu db.\$1.2xlarge | 150 |
| db.\$1.4xlarge zu db.\$1.8xlarge | 300 |
| db.\$1.12xlarge zu db.\$1.16xlarge | 600 |
| db.\$1.24xlarge, db.\$132xlarge | 1000 |
`*` *stellt die unterschiedlichen Typen von Instance-Klassen dar.*
Die maximale Anzahl von Datenbanken, die für PITR in einer DB-Instance in Frage kommen, hängt vom Instance-Klassentyp ab. Die Anzahl reicht von 100 bei den kleinsten Instance-Klassentypen bis zu 1000 bei den größten Instance-Klassentypen, die von RDS Custom für SQL Server unterstützt werden. SQL-Server-Systemdatenbanken `(master, model, msdb, tempdb)` unterliegen nicht dieser Beschränkung. Wenn eine DB-Instance je nach Typ der Ziel-Instance-Klasse 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 will send `RDS-EVENT-0352`, wenn sich die maximale Anzahl von Datenbanken, die für PITR-Anwendungen in Frage kommen, auf einer -DB-Instance ändert. Weitere Informationen finden Sie unter [Benutzerdefinierte Engine-Versionsereignisse](USER_Events.Messages.md#USER_Events.Messages.CEV).
**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, 100, unabhängig von der Instance-Klasse. Um die 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 zum Zeitpunkt der Wiederherstellung Teil von PITR auf der Quell-DB-Instance waren. Sobald die Ziel-DB-Instance die Wiederherstellungsvorgänge abgeschlossen hat und die Sicherung aktiviert ist, beginnt die DB-Instance mit der Sicherung auf der Grundlage der maximalen Anzahl von Datenbanken, die für PITR auf der Ziel-DB-Instance in Frage kommen.
Wenn Ihre DB-Instance beispielsweise auf einer `db.*.xlarge` mit 200 Datenbanken läuft:
1. RDS Custom für SQL Server wählt die ersten 150 Datenbanken, sortiert nach ihrer Datenbank-ID, für die PITR-Sicherung aus.
1. Sie ändern die Instance so, dass sie auf db.\$1.4xlarge skaliert wird.
1. Sobald der Skalierungsrechenvorgang abgeschlossen ist, wählt RDS Custom für SQL Server die ersten 300 Datenbanken, sortiert nach ihrer Datenbank-ID, für die PITR-Sicherung aus. Jede der 200 Datenbanken, die die PITR-Anforderungen erfüllen, kommt nun für PITR in Frage.
1. Sie ändern jetzt die Instance, sodass sie wieder auf db.\$1.xlarge herunterskaliert wird.
1. Sobald der Skalierungsrechenvorgang abgeschlossen ist, wählt RDS Custom für SQL Server erneut die ersten 150 Datenbanken, sortiert nach ihrer Datenbank-ID, für die PITR-Backup aus.
## Datenbanken für PITR nicht berechtigt machen
Sie können wählen, ob einzelne Datenbanken von PITR ausgeschlossen werden sollen. 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\$1pitr\$1blocked\$1databases“**
+ 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](#custom-backup.pitr.sqlserver.tlogs).
Sie können die Liste der Datenbanken, die für PITR in Frage kommen, auch mithilfe des folgenden SQL-Skripts ermitteln. Setzen Sie die `@limit`-Variable auf die maximale Anzahl von Datenbanken, die für PITR in der Instance-Klasse in Frage kommen. Weitere Informationen finden Sie unter [Anzahl der Datenbanken, die für PITR in Frage kommen, pro Instance-Klassentyp](#custom-backup.pitr.sqlserver.eligiblecountperinstance).
**So ermitteln Sie die Liste der für PITR in Frage kommenden Datenbanken 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, bei denen es sich nur um symbolische Links handelt, sind ebenfalls von Datenbanken ausgeschlossen, die für PITR-Operationen in Frage kommen. Die obige Abfrage filtert nicht nach diesen Kriterien.
## Transaktionsprotokolle in Amazon S3
Der Aufbewahrungszeitraum für Backups bestimmt, ob Transaktionsprotokolle für RDS Custom für SQL Server DB-Instances 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](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) 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`. `RdsChunkCount`bestimmt, 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 Restore mit der, der oder der RDS-API. AWS-Managementkonsole AWS CLI
Sie können eine RDS Custom for SQL Server-DB-Instance zu einem bestimmten Zeitpunkt mithilfe der AWS-ManagementkonsoleAWS CLI, der oder der RDS-API wiederherstellen.
### Konsole
**Wiederherstellen einer DB-Instance eines RDS Custom zu einer bestimmten Zeit**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Automated backups** (Automatisierte Backups) aus.
1. Wählen Sie die RDS Custom DB-Instance aus, die Sie wiederherstellen möchten.
1. Wählen Sie unter **Aktionen** die Option **Wiederherstellen auf einen bestimmten Zeitpunkt** aus.
Anschließend wird das Fenster **Restore to point in time (Zu einem bestimmten Zeitpunkt wiederherstellen)** angezeigt.
1. 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. UTC-5 ist beispielsweise Eastern Standard Time/Central Daylight Time.
1. Geben Sie für **DB-Instance-Kennung** den Namen der wiederhergestellten RDS Custom DB-Ziel-Instance ein. Der Name muss eindeutig sein.
1. Wählen Sie bei Bedarf andere Optionen aus, z. B. DB-Instance-Class.
1. Wählen Sie **Wiederherstellen auf einen bestimmten Zeitpunkt** aus.
### AWS CLI
Sie stellen eine DB-Instance zu einem bestimmten Zeitpunkt wieder her, indem Sie den point-in-time AWS CLI Befehl [ restore-db-instance-to-](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) verwenden, um eine neue benutzerdefinierte RDS-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.
**Example**
Für Linux, macOS oder Unix:
```
1. aws rds restore-db-instance-to-point-in-time \
2. --source-db-instance-identifier my-custom-db-instance\
3. --target-db-instance-identifier my-restored-custom-db-instance \
4. --custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance \
5. --restore-time 2022-10-14T23:45:00.000Z
```
Für Windows:
```
1. aws rds restore-db-instance-to-point-in-time ^
2. --source-db-instance-identifier my-custom-db-instance ^
3. --target-db-instance-identifier my-restored-custom-db-instance ^
4. --custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance ^
5. --restore-time 2022-10-14T23:45:00.000Z
```
# Löschen eines Snapshots von RDS Custom für SQL Server
Sie können DB-Snapshots löschen, die mit RDS Custom für 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-Instances 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 für SQL Server ausgeführt werden. Diese EBS-Snapshots werden automatisch gelöscht, nachdem sie nicht mehr mit vorhandenen Ressourcen von RDS Custom für SQL Server (DB-Instances oder Backups) in Verbindung stehen.
## Konsole
**So löschen Sie einen Snapshot Ihrer RDS-DB-Instance**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich die Option **Snapshots**.
1. Wählen Sie den DB-Snapshot aus, den Sie löschen möchten.
1. Wählen Sie unter **Actions (Aktionen)** die Option **Delete Snapshot (Snapshot löschen)** aus.
1. Wählen Sie auf der Bestätigungsseite die Option **Löschen** aus.
## AWS CLI
Um einen benutzerdefinierten RDS-Snapshot zu löschen, verwenden Sie den AWS CLI-Vefehl [delete-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-snapshot.html).
Die folgenden Optionen sind erforderlich:
+ `--db-snapshot-identifier` — Der zu löschende Snapshot
Das folgende Beispiel löscht den Cluster-Snapshot `my-custom-snapshot`.
**Example**
Für Linux, macOS oder Unix:
```
1. aws rds delete-db-snapshot \
2. --db-snapshot-identifier my-custom-snapshot
```
Windows:
```
1. aws rds delete-db-snapshot ^
2. --db-snapshot-identifier my-custom-snapshot
```
# Löschen von automatisierten Backups von RDS Custom für SQL Server
Sie können aufbewahrte automatisierte Backups für RDS Custom für SQL Server löschen, wenn sie nicht mehr benötigt werden. Das Verfahren entspricht dem Verfahren zum Löschen von Amazon-RDS-Backups.
## Konsole
**So löschen Sie eine aufbewahrte automatisierte Backup:**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wählen Sie im Navigationsbereich **Automated backups** (Automatisierte Backups) aus.
1. Wählen Sie **Retained (Aufbewahrt)**.
1. Wählen Sie die aufbewahrte automatisierte Sicherung, die Sie löschen möchten.
1. Klicken Sie bei ** Actions** auf **Delete**.
1. Geben Sie auf der Bestätigungsseite **delete me** und wählen Sie **Löschen** aus.
## AWS CLI
Sie können eine aufbewahrte automatisierte Sicherung mit dem AWS CLI-Befehl [delete-db-instance-automated-backup](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-instance-automated-backup.html) 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 aufbewahrten automatisierten Backups mit dem AWS CLI-Befehl [describe-db-instance-automated-backups](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instance-automated-backups.html).
Im folgenden Beispiel wird das aufbewahrte automatisierte Backup mit der Quell-DB-Instance-Ressourcenkennung `custom-db-123ABCEXAMPLE` gelöscht.
**Example**
Für Linux, macOS oder Unix:
```
1. aws rds delete-db-instance-automated-backup \
2. --dbi-resource-id custom-db-123ABCEXAMPLE
```
Windows:
```
1. aws rds delete-db-instance-automated-backup ^
2. --dbi-resource-id custom-db-123ABCEXAMPLE
```