Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Memulihkan instans RDS Custom for SQL Server ke suatu titik waktu
Anda dapat memulihkan instans DB ke titik waktu tertentu (PITR) dan membuat instans DB baru. Untuk mendukung PITR, instans DB Anda harus mengaktifkan retensi cadangan.
Waktu pemulihan terbaru untuk instans DB RDS Custom for SQL Server bergantung pada beberapa faktor, tetapi biasanya dalam 5 menit dari waktu saat ini. Untuk melihat waktu restorable terbaru untuk instans DB, gunakan AWS CLI [perintah deskripsi-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) dan lihat nilai yang dikembalikan di bidang untuk instans DB. `LatestRestorableTime` Untuk melihat waktu pemulihan terbaru setiap instans DB di konsol Amazon RDS, pilih **Cadangan otomatis**.
Anda dapat memulihkan ke titik waktu mana pun dalam periode retensi cadangan Anda. Untuk melihat waktu pemulihan terbaru setiap instans DB, pilih **Cadangan otomatis** di konsol Amazon RDS.
Untuk informasi umum tentang PITR, lihat [Memulihkan instans DB ke waktu yang ditentukan untuk Amazon RDS](USER_PIT.md).
**Topics**
+ [Pertimbangan PITR untuk RDS Custom for SQL Server](#custom-backup.pitr.sqlserver)
+ [Jumlah basis data yang memenuhi syarat untuk PITR per jenis kelas instans](#custom-backup.pitr.sqlserver.eligiblecountperinstance)
+ [Membuat basis data tidak memenuhi syarat untuk PITR](#custom-backup.pitr.sqlserver.ineligible)
+ [Log transaksi di Amazon S3](#custom-backup.pitr.sqlserver.tlogs)
+ [PITR Restore menggunakan Konsol Manajemen AWS, AWS CLI, atau RDS API.](#custom-backup.pitr-sqs-concli)
## Pertimbangan PITR untuk RDS Custom for SQL Server
PITR di RDS Custom for SQL Server berbeda dari PITR di Amazon RDS dalam beberapa hal penting berikut:
+ PITR hanya memulihkan basis data dalam instans DB. PITR tidak memulihkan sistem operasi atau file pada drive C:.
+ Untuk instans DB RDS Custom for SQL Server, basis data dicadangkan secara otomatis dan memenuhi syarat untuk PITR hanya dalam kondisi berikut:
+ Basis data online.
+ Model pemulihannya diatur ke `FULL`.
+ Dapat ditulis.
+ Memiliki file fisik di drive D:.
+ Tidak tercantum dalam tabel `rds_pitr_blocked_databases`. Untuk informasi selengkapnya, lihat [Membuat basis data tidak memenuhi syarat untuk PITR](#custom-backup.pitr.sqlserver.ineligible).
+ Basis data yang memenuhi syarat untuk PITR ditentukan oleh urutan ID basis data. RDS Custom for SQL Server memungkinkan hingga 5.000 basis data per instans DB. Namun, jumlah maksimum basis data yang dipulihkan oleh operasi PITR untuk instans DB RDS Custom for SQL Server bergantung pada jenis kelas instans. Untuk informasi selengkapnya, lihat [Jumlah basis data yang memenuhi syarat untuk PITR per jenis kelas instans](#custom-backup.pitr.sqlserver.eligiblecountperinstance).
Basis data lain yang bukan bagian dari PITR dapat dipulihkan dari snapshot DB, termasuk cadangan snapshot otomatis yang digunakan untuk PITR.
+ Menambahkan basis data baru, mengganti nama basis data, atau memulihkan basis data yang memenuhi syarat untuk PITR memulai snapshot instans DB.
+ Jumlah maksimum basis data yang memenuhi syarat untuk PITR berubah ketika instans basis data melewati operasi komputasi skala, bergantung pada jenis kelas instans target. Jika skala instans dinaikkan dan memungkinkan lebih banyak basis data pada instans memenuhi syarat untuk PITR, snapshot baru akan diambil.
+ Basis data yang dipulihkan memiliki nama yang sama seperti pada instans DB sumber. Anda tidak dapat menentukan nama yang berbeda.
+ `AWSRDSCustomSQLServerIamRolePolicy`membutuhkan akses ke AWS layanan lain. Untuk informasi selengkapnya, lihat [Menambahkan kebijakan akses ke AWSRDSCustomSQLServerInstanceRole](custom-setup-sqlserver.md#custom-setup-sqlserver.iam.add-policy).
+ Perubahan zona waktu tidak didukung untuk RDS Custom for SQL Server. Jika Anda mengubah zona waktu sistem operasi atau instans DB, PITR (dan otomatisasi lainnya) tidak berfungsi.
## Jumlah basis data yang memenuhi syarat untuk PITR per jenis kelas instans
Tabel berikut menunjukkan jumlah maksimum basis data yang memenuhi syarat untuk PITR berdasarkan jenis kelas instans.
| Jenis kelas instans | Jumlah maksimum basis data yang memenuhi syarat untuk PITR |
| --- | --- |
| db.\*.large | 100 |
| db.\*.xlarge hingga db.\*.2xlarge | 150 |
| db.\*.4xlarge hingga db.\*.8xlarge | 300 |
| db.\*.12xlarge hingga db.\*.16xlarge | 600 |
| db.\*.24xlarge, db.\*32xlarge | 1000 |
`*` *Menunjukkan jenis kelas instans yang berbeda.*
Jumlah maksimum basis data yang memenuhi syarat untuk PITR pada instans DB bergantung pada jenis kelas instans. Jumlahnya berkisar dari 100 pada jenis kelas instans terkecil hingga 1000 pada jenis kelas instans terbesar yang didukung oleh RDS Custom for SQL Server. Basis data sistem SQL server `(master, model, msdb, tempdb)`, tidak termasuk dalam batas ini. Ketika skala instans DB dinaikkan atau diturunkan, bergantung pada jenis kelas instans target, RDS Custom akan otomatis memperbarui jumlah basis data yang memenuhi syarat untuk PITR. RDS Custom for SQL Server akan mengirim `RDS-EVENT-0352` ketika jumlah maksimum basis data yang memenuhi syarat untuk PITR berubah pada instans DB. Untuk informasi selengkapnya, lihat [Peristiwa versi mesin kustom](USER_Events.Messages.md#USER_Events.Messages.CEV).
**catatan**
Dukungan PITR untuk lebih dari 100 basis data hanya tersedia pada instans DB yang dibuat setelah 26 Agustus 2023. Untuk instans yang dibuat sebelum 26 Agustus 2023, jumlah maksimum basis data yang memenuhi syarat untuk PITR adalah 100, terlepas dari kelas instansnya. Guna mengaktifkan dukungan PITR untuk lebih dari 100 basis data pada instans DB yang dibuat sebelum 26 Agustus 2023, Anda dapat melakukan tindakan berikut:
Tingkatkan versi mesin DB ke 15.00.4322.2.v1 atau lebih tinggi
Selama operasi PITR, RDS Custom akan memulihkan semua basis data yang merupakan bagian dari PITR pada instans DB sumber pada waktu pemulihan. Setelah instans DB target menyelesaikan operasi pemulihan, jika retensi cadangan diaktifkan, instans DB akan mulai mencadangkan berdasarkan jumlah maksimum basis data yang memenuhi syarat untuk PITR pada instans DB target.
Misalnya, jika instans DB Anda berjalan pada `db.*.xlarge` yang memiliki 200 basis data:
1. RDS Custom for SQL Server akan memilih 150 basis data pertama yang diurutkan berdasarkan ID basis data untuk cadangan PITR.
1. Anda memodifikasi instans untuk menaikkan skala hingga db.\*.4xlarge.
1. Setelah operasi komputasi skala selesai, RDS Custom for SQL Server akan memilih 300 basis data pertama, diurutkan berdasarkan ID basis data, untuk cadangan PITR. Masing-masing dari 200 basis data yang memenuhi kondisi persyaratan PITR sekarang akan memenuhi syarat untuk PITR.
1. Sekarang Anda memodifikasi instans untuk menurunkan skala kembali ke db.\*.xlarge.
1. Setelah operasi komputasi skala selesai, RDS Custom for SQL Server akan kembali memilih 150 basis data pertama, diurutkan berdasarkan ID basis data, untuk cadangan PITR.
## Membuat basis data tidak memenuhi syarat untuk PITR
Anda dapat memilih untuk mengecualikan basis data individual dari PITR. Untuk melakukan ini, masukkan nilai `database_id` ke dalam tabel `rds_pitr_blocked_databases`. Gunakan skrip SQL berikut untuk membuat tabel.
**Cara membuat tabel rds\_pitr\_blocked\_databases**
+ Jalankan skrip SQL berikut.
```
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)
);
```
Untuk daftar basis data yang memenuhi syarat dan tidak memenuhi syarat, lihat file `RI.End` pada direktori `RDSCustomForSQLServer/Instances/{{DB_instance_resource_ID}}/TransactionLogMetadata` di bucket Amazon S3 `do-not-delete-rds-custom-{{$ACCOUNT_ID}}-{{$REGION}}-{{unique_identifier}}`. Untuk informasi selengkapnya tentang file `RI.End`, lihat [Log transaksi di Amazon S3](#custom-backup.pitr.sqlserver.tlogs).
Anda juga dapat menentukan daftar basis data yang memenuhi syarat untuk PITR menggunakan skrip SQL berikut. Tetapkan variabel `@limit` ke jumlah maksimum basis data yang memenuhi syarat untuk PITR untuk kelas instans. Untuk informasi selengkapnya, lihat [Jumlah basis data yang memenuhi syarat untuk PITR per jenis kelas instans](#custom-backup.pitr.sqlserver.eligiblecountperinstance).
**Cara menentukan daftar basis data yang memenuhi syarat untuk PITR pada kelas instans DB**
+ Jalankan skrip SQL berikut.
```
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
```
**catatan**
Basis data yang hanya merupakan tautan simbolis juga dikecualikan dari basis data yang memenuhi syarat untuk operasi PITR. Kueri di atas tidak memfilter berdasarkan kriteria ini.
## Log transaksi di Amazon S3
Periode retensi cadangan menentukan apakah log transaksi untuk instans DB RDS Custom for SQL Server secara otomatis diekstraksi dan diunggah ke Amazon S3. Nilai bukan nol berarti cadangan otomatis dibuat dan agen RDS Custom mengunggah log transaksi ke S3 setiap 5 menit.
File log transaksi pada S3 dienkripsi saat diam menggunakan AWS KMS key yang Anda berikan saat membuat instans DB. Untuk informasi selengkapnya, lihat [Melindungi data menggunakan enkripsi sisi server](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) di *Panduan Pengguna Amazon Simple Storage Service*.
Log transaksi untuk setiap basis data diunggah ke bucket S3 bernama `do-not-delete-rds-custom-{{$ACCOUNT_ID}}-{{$REGION}}-{{unique_identifier}}`. Direktori `RDSCustomForSQLServer/Instances/{{DB_instance_resource_ID}}` di bucket S3 berisi dua subdirektori:
+ `TransactionLogs` — Berisi log transaksi untuk setiap basis data dan metadata masing-masing.
Nama file log transaksi mengikuti pola `{{yyyyMMddHHmm}}.{{database_id}}.{{timestamp}}`, misalnya:
```
202110202230.11.1634769287
```
Nama file yang sama dengan akhiran `_metadata` berisi informasi tentang log transaksi seperti nomor urut log, nama basis data, dan `RdsChunkCount`. `RdsChunkCount` menentukan berapa banyak file fisik yang mewakili satu file log transaksi. Anda mungkin melihat file dengan sufiks `_0001`, `_0002`, dan sebagainya, yang berarti potongan fisik dari file log transaksi. Jika Anda ingin menggunakan potongan file log transaksi, pastikan untuk menggabungkan potongan setelah mengunduhnya.
Pertimbangkan skenario ketika Anda memiliki file berikut:
+ `202110202230.11.1634769287`
+ ` 202110202230.11.1634769287_0001`
+ ` 202110202230.11.1634769287_0002 `
+ ` 202110202230.11.1634769287_metadata`
`RdsChunkCount` adalah `3`. Urutan untuk menggabungkan file adalah sebagai berikut: `202110202230.11.1634769287`, ` 202110202230.11.1634769287_0001`, `202110202230.11.1634769287_0002`.
+ `TransactionLogMetadata` — Berisi informasi metadata tentang setiap iterasi ekstraksi log transaksi.
File `RI.End` berisi informasi untuk semua basis data yang log transaksinya diekstraksi dan semua basis data yang ada tetapi tidak log transaksinya tidak diekstraksi. Nama file `RI.End` mengikuti pola `{{yyyyMMddHHmm}}.RI.End.{{timestamp}}`, misalnya:
```
202110202230.RI.End.1634769281
```
## PITR Restore menggunakan Konsol Manajemen AWS, AWS CLI, atau RDS API.
Anda dapat memulihkan instans RDS Custom for SQL Server DB ke titik waktu menggunakan Konsol Manajemen AWS, API AWS CLI, atau RDS.
### Konsol
**Cara memulihkan instans DB RDS Custom ke waktu tertentu**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon RDS di [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Di panel navigasi, pilih **Pencadangan otomatis**.
1. Pilih instans DB RDS Custom yang ingin Anda pulihkan.
1. Untuk **Tindakan**, pilih **Pulihkan ke titik waktu**.
Jendela **Pulihkan ke titik waktu** akan muncul.
1. Pilih **Waktu pemulihan terbaru** untuk memulihkan ke waktu terbaru yang dimungkinkan atau pilih **Kustom** untuk memilih waktu.
Jika Anda memilih **Kustom**, masukkan tanggal dan waktu untuk memulihkan instans.
Waktu ditampilkan dalam zona waktu lokal Anda, yang ditunjukkan dengan offset dari Waktu Universal Terkoordinasi (UTC). Misalnya, UTC-5 adalah Waktu Time/Central Siang Standar Timur.
1. Untuk **Pengidentifikasi instans DB**, masukkan nama target instans DB RDS Custom yang dipulihkan. Nama harus unik.
1. Pilih opsi lain sesuai kebutuhan, seperti kelas instans DB.
1. Pilih **Pulihkan ke titik waktu**.
### AWS CLI
Anda memulihkan instans DB ke waktu tertentu menggunakan perintah AWS CLI [restore-db-instans-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) untuk membuat instans DB RDS Custom baru.
Gunakan salah satu opsi berikut untuk menentukan cadangan yang akan dipulihkan dari:
+ `--source-db-instance-identifier {{mysourcedbinstance}}`
+ `--source-dbi-resource-id {{dbinstanceresourceID}}`
+ `--source-db-instance-automated-backups-arn {{backupARN}}`
Opsi `custom-iam-instance-profile` diperlukan.
Contoh berikut memulihkan `my-custom-db-instance` ke instans DB baru bernama `my-restored-custom-db-instance` pada waktu yang ditentukan.
**Example**
Untuk Linux, macOS, atau 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}}
```
Untuk 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}}
```