Mencadangkan dan memulihkan instans DB Amazon RDS Custom for SQL Server - Layanan Basis Data Relasional Amazon

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Mencadangkan dan memulihkan instans DB Amazon RDS Custom for SQL Server

Seperti Amazon RDS, RDS Custom membuat dan menyimpan cadangan otomatis instans DB RDS Custom for SQL Server Anda saat retensi cadangan diaktifkan. Anda juga dapat mencadangkan instans DB secara manual. Cadangan otomatis terdiri dari cadangan snapshot dan cadangan log transaksi. Cadangan snapshot diambil untuk seluruh volume penyimpanan instans DB selama jendela cadangan yang Anda tentukan. Cadangan log transaksi diambil untuk basis data yang memenuhi syarat PITR pada periode interval reguler. RDS Custom menyimpan cadangan otomatis instans DB Anda sesuai dengan periode retensi cadangan yang Anda tentukan. Anda dapat menggunakan cadangan otomatis untuk memulihkan instans DB Anda ke titik waktu dalam periode retensi cadangan.

Anda juga dapat mengambil cadangan snapshot secara manual. Anda dapat membuat instans DB baru dari cadangan snapshot ini kapan saja. Untuk informasi selengkapnya tentang cara membuat snapshot DB secara manual, lihat Membuat snapshot RDS Custom for SQL Server.

Meskipun cadangan snapshot berfungsi secara operasional sebagai cadangan penuh, Anda hanya ditagih untuk penggunaan penyimpanan tambahan. Snapshot pertama instans DB RDS Custom berisi data untuk instans DB penuh. Snapshot berikutnya dari basis data yang sama bersifat inkremental, artinya hanya data yang berubah setelah snapshot terbaru Anda yang disimpan.

Membuat snapshot RDS Custom for SQL Server

RDS Custom for SQL Server membuat snapshot volume penyimpanan instans DB Anda, mencadangkan seluruh instans DB dan bukan hanya basis data individual. Saat Anda membuat snapshot, tentukan instans DB RDS Custom for SQL Server mana yang akan dicadangkan. Beri nama snapshot sehingga Anda dapat melakukan proses pemulihan dari snapshot tersebut nanti.

Saat Anda membuat snapshot, RDS Custom for SQL Server membuat snapshot Amazon EBS untuk volume (D:), yang merupakan volume basis data yang dilampirkan ke instans DB. Agar mudah dikaitkan dengan instans DB tertentu, snapshot ditandai dengan DBSnapshotIdentifier, DbiResourceId, dan VolumeType.

Membuat snapshot DB menghasilkan suspensi I/O singkat. Suspensi ini dapat bertahan beberapa detik hingga beberapa menit, bergantung pada ukuran dan kelas instans DB Anda. Waktu pembuatan snapshot bervariasi menurut jumlah total dan ukuran basis data Anda. Untuk mempelajari selengkapnya tentang jumlah basis data yang memenuhi syarat untuk operasi pemulihan titik waktu (PITR), lihat Jumlah basis data yang memenuhi syarat untuk PITR per jenis kelas instans.

Karena snapshot mencakup seluruh volume penyimpanan, ukuran file seperti file sementara juga memengaruhi waktu pembuatan snapshot. Untuk mempelajari selengkapnya tentang membuat snapshot, lihat Membuat snapshot DB untuk instans DB Single-AZ.

Buat snapshot RDS Custom for SQL Server menggunakan konsol atau AWS CLI.

Cara membuat snapshot RDS Custom
  1. Masuk ke AWS Management Console dan buka konsol Amazon RDS di https://console.aws.amazon.com/rds/.

  2. Di panel navigasi, pilih Basis Data.

  3. Dalam daftar instans DB RDS Custom, pilih instans yang ingin Anda ambil snapshot-nya.

  4. Untuk Tindakan, pilih Ambil snapshot.

    Jendela Ambil snapshot DB akan muncul.

  5. Untuk Nama snapshot, masukkan nama snapshot.

  6. Pilih Ambil snapshot.

Anda membuat snapshot dari instans RDS Custom DB dengan menggunakan perintah. create-db-snapshotAWS CLI

Tentukan opsi berikut:

  • --db-instance-identifier — Mengidentifikasi instans DB RDS Custom mana yang akan Anda cadangkan

  • --db-snapshot-identifier — Memberi nama snapshot RDS Custom sehingga Anda dapat melakukan proses pemulihan dari snapshot tersebut nanti

Dalam contoh ini, Anda membuat snapshot DB bernama my-custom-snapshot untuk instans DB RDS Custom bernama my-custom-instance.

Untuk Linux, macOS, atau Unix:

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

Untuk Windows:

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

Memulihkan dari snapshot DB RDS Custom for SQL Server

Saat memulihkan instans DB RDS Custom for SQL Server, Anda memberikan nama untuk snapshot DB dan instans baru. Anda tidak dapat memulihkan dari snapshot ke instans DB RDS Custom yang ada. Instans DB RDS Custom for SQL Server baru dibuat saat Anda melakukan pemulihan.

Memulihkan dari snapshot akan mengembalikan volume penyimpanan ke titik waktu ketika snapshot diambil. Hal ini akan mencakup semua basis data dan file lain yang ada pada volume (D:).

Cara memulihkan instans DB RDS Custom dari snapshot DB
  1. Masuk ke AWS Management Console dan buka konsol Amazon RDS di https://console.aws.amazon.com/rds/.

  2. Di panel navigasi, pilih Snapshot.

  3. Pilih snapshot DB yang ingin Anda pulihkan.

  4. Untuk Tindakan, pilih Pulihkan snapshot.

  5. Di halaman Pulihkan instans DB, untuk Pengidentifikasi instans DB, masukkan nama instans DB RDS Custom Anda yang dipulihkan.

  6. Pilih Pulihkan instans DB.

Anda mengembalikan snapshot RDS Custom DB dengan menggunakan perintah restore-db-instance-fromAWS CLI-db-snapshot.

Jika snapshot yang Anda pulihkan adalah untuk instans DB privat, pastikan untuk menentukan db-subnet-group-name dan no-publicly-accessible yang benar. Jika tidak, default instans DB diatur agar dapat diakses publik. Opsi berikut diperlukan:

  • db-snapshot-identifier — Mengidentifikasi snapshot yang akan dipulihkan

  • db-instance-identifier — Menentukan nama instans DB RDS Custom yang akan dibuat dari snapshot DB

  • custom-iam-instance-profile — Menentukan profil instans yang terkait dengan instans Amazon EC2 yang mendasari instans DB RDS Custom.

Kode berikut memulihkan snapshot bernama my-custom-snapshot untuk my-custom-instance.

Untuk Linux, macOS, atau 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

Untuk 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

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 describe-db-instancesperintah dan lihat nilai yang dikembalikan di LatestRestorableTime bidang untuk instans DB. 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 dengan waktu yang ditentukan.

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 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.

    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 layanan AWS lain. Untuk informasi selengkapnya, lihat Menambahkan kebijakan akses ke AWSRDSCustomSQLServerInstanceRole.

  • 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.

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.

  2. Anda memodifikasi instans untuk menaikkan skala hingga db.*.4xlarge.

  3. 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.

  4. Sekarang Anda memodifikasi instans untuk menurunkan skala kembali ke db.*.xlarge.

  5. 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.

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.

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 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

Pemulihan PITR menggunakan AWS Management Console, AWS CLI, atau API RDS.

Anda dapat memulihkan instans DB RDS Custom for SQL Server ke suatu titik waktu menggunakan AWS Management Console, AWS CLI, atau API RDS.

Cara memulihkan instans DB RDS Custom ke waktu tertentu
  1. Masuk ke AWS Management Console dan buka konsol Amazon RDS di https://console.aws.amazon.com/rds/.

  2. Di panel navigasi, pilih Pencadangan otomatis.

  3. Pilih instans DB RDS Custom yang ingin Anda pulihkan.

  4. Untuk Tindakan, pilih Pulihkan ke titik waktu.

    Jendela Pulihkan ke titik waktu akan muncul.

  5. 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 Standar Timur/Waktu Musim Panas Tengah.

  6. Untuk Pengidentifikasi instans DB, masukkan nama target instans DB RDS Custom yang dipulihkan. Nama harus unik.

  7. Pilih opsi lain sesuai kebutuhan, seperti kelas instans DB.

  8. Pilih Pulihkan ke titik waktu.

Anda mengembalikan instans DB ke waktu tertentu dengan menggunakan point-in-time AWS CLI perintah restore-db-instance-to- untuk membuat instance RDS Custom DB 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.

Untuk Linux, macOS, atau 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

Untuk 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

Menghapus snapshot RDS Custom for SQL Server

Anda dapat menghapus snapshot DB yang dikelola RDS Custom for SQL Server saat tidak lagi membutuhkannya. Prosedur penghapusan sama untuk instans DB Amazon RDS dan RDS Custom.

Snapshot Amazon EBS untuk biner dan volume root tetap ada di akun Anda untuk waktu yang lebih lama karena mungkin ditautkan ke beberapa instans yang berjalan di akun Anda atau ke snapshot RDS Custom for SQL Server lainnya. Snapshot EBS ini dihapus secara otomatis setelah tidak lagi terkait dengan sumber daya RDS Custom for SQL Server yang ada (instans DB atau cadangan).

Cara menghapus snapshot instans DB RDS Custom
  1. Masuk ke AWS Management Console dan buka konsol Amazon RDS di https://console.aws.amazon.com/rds/.

  2. Di panel navigasi, pilih Snapshot.

  3. Pilih snapshot DB yang ingin Anda hapus.

  4. Untuk Tindakan, pilih Hapus snapshot.

  5. Pilih Hapus di halaman konfirmasi.

Untuk menghapus snapshot RDS Custom, gunakan perintah. AWS CLI delete-db-snapshot

Opsi berikut diperlukan:

  • --db-snapshot-identifier — Snapshot yang akan dihapus

Contoh berikut menghapus snapshot DB my-custom-snapshot.

Untuk Linux, macOS, atau Unix:

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

Untuk Windows:

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

Menghapus cadangan otomatis RDS Custom for SQL Server

Anda dapat menghapus cadangan otomatis yang disimpan untuk RDS Custom for SQL Server saat tidak diperlukan lagi. Prosedurnya sama dengan prosedur untuk menghapus cadangan Amazon RDS.

Untuk menghapus cadangan otomatis yang dipertahankan
  1. Masuk ke AWS Management Console lalu buka konsol Amazon RDS di https://console.aws.amazon.com/rds/.

  2. Di panel navigasi, pilih Pencadangan otomatis.

  3. Pilih Dipertahankan.

  4. Pilih cadangan otomatis yang dipertahankan yang ingin Anda hapus.

  5. Untuk Tindakan, pilih Hapus.

  6. Di halaman konfirmasi, masukkan delete me dan pilih Hapus.

Anda dapat menghapus cadangan otomatis yang dipertahankan dengan menggunakan AWS CLI perintah delete-db-instance-automated-backup.

Opsi berikut digunakan untuk menghapus cadangan otomatis yang dipertahankan:

Contoh berikut menghapus cadangan otomatis yang dipertahankan dengan pengidentifikasi sumber daya instans DB sumber custom-db-123ABCEXAMPLE.

Untuk Linux, macOS, atau Unix:

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

Untuk Windows:

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