View a markdown version of this page

Pencadangan berkelanjutan dan pemulihan point-in-time (PITR) - AWS Backup

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

Pencadangan berkelanjutan dan pemulihan point-in-time (PITR)

Untuk beberapa sumber daya, AWS Backup mendukung pencadangan berkelanjutan dan pemulihan point-in-time (PITR) selain backup snapshot.

Dengan pencadangan berkelanjutan, Anda dapat memulihkan sumber daya yang AWS Backup didukung dengan memutarnya kembali ke waktu tertentu yang Anda pilih, dalam presisi 1 detik (kembali maksimal 35 hari). Pencadangan berkelanjutan bekerja dengan terlebih dahulu membuat cadangan penuh sumber daya Anda, dan kemudian terus-menerus membuat cadangan log transaksi sumber daya Anda. PITR bekerja dengan mengakses cadangan penuh Anda dan memutar ulang log transaksi ke waktu yang Anda beri tahu AWS Backup untuk memulihkan.

Atau, backup snapshot dapat diambil sesering setiap jam. Backup snapshot dapat disimpan hingga maksimal 100 tahun. Snapshot dapat disalin untuk backup penuh atau inkremental.

Karena pencadangan kontinu dan snapshot menawarkan keuntungan yang berbeda, sebaiknya lindungi sumber daya dengan aturan pencadangan kontinu dan snapshot.

Cadangan sesuai permintaan mulai membuat cadangan sumber daya Anda segera. Anda dapat memilih cadangan sesuai permintaan jika Anda ingin membuat cadangan pada waktu selain waktu yang dijadwalkan yang ditentukan dalam rencana cadangan. Cadangan sesuai permintaan dapat digunakan, misalnya, untuk menguji cadangan dan fungsionalitas kapan saja.

Anda tidak dapat menggunakan cadangan sesuai permintaan dengan PITR, karena cadangan sesuai permintaan mempertahankan sumber daya dalam keadaan saat cadangan diambil, sementara PITR menggunakan pencadangan berkelanjutan, yang merekam perubahan selama periode waktu tertentu.

Anda dapat memilih untuk melakukan backup berkelanjutan untuk sumber daya yang didukung saat membuat rencana cadangan AWS Backup menggunakan AWS Backup konsol atau API. Rencana pencadangan berkelanjutan membuat satu titik pemulihan berkelanjutan dan memperbarui titik pemulihan itu setiap kali pekerjaan berjalan.

Point-in-time pertimbangan pemulihan

Perhatikan pertimbangan berikut untuk pemulihan point-in-time:

  • Fallback otomatis ke snapshot — Jika AWS Backup tidak dapat melakukan pencadangan berkelanjutan, ia mencoba melakukan pen cadangan snapshot sebagai gantinya.

  • Tidak ada dukungan untuk pencadangan berkelanjutan sesuai AWS Backup permintaan — tidak mendukung pencadangan berkelanjutan sesuai permintaan karena pencadangan sesuai permintaan merekam suatu titik waktu, sedangkan catatan pencadangan berkelanjutan berubah selama periode waktu tertentu.

  • Tidak ada dukungan untuk transisi ke cold storage — Pencadangan berkelanjutan tidak mendukung transisi ke cold storage karena transisi ke cold membutuhkan periode transisi minimum 90 hari, sedangkan pencadangan berkelanjutan memiliki periode retensi maksimum 35 hari.

  • Memulihkan aktivitas terbaru — Aktivitas Amazon RDS memungkinkan pemulihan hingga 5 menit aktivitas terbaru; Aurora memungkinkan pemulihan hingga aktivitas terbaru seperti yang ditunjukkan oleh LatestRestorableTime (biasanya kurang dari 5 menit); Amazon S3 memungkinkan pemulihan hingga aktivitas 15 menit terakhir.

penting

Satu sumber daya hanya dapat memiliki satu cadangan berkelanjutan. Perluas di bawah untuk detail tambahan dan praktik terbaik.

Setiap sumber daya (seperti bucket Amazon S3 atau database Amazon RDS) hanya dapat memiliki satu pencadangan berkelanjutan (titik pemulihan); cadangan berkelanjutan tambahan berlebihan. Ketika beberapa kebijakan, rencana, atau aturan pencadangan menginstruksikan AWS Backup untuk membuat beberapa cadangan berkelanjutan untuk sumber daya yang sama, proses berikut berlaku:

  • Jika beberapa aturan menentukan bahwa lebih dari satu pencadangan berkelanjutan harus berada dalam satu vault, ikuti AWS Backup aturan dengan periode retensi terpanjang (siklus hidup) dan mengabaikan aturan tambahan.

  • Jika beberapa aturan menentukan bahwa lebih dari satu pencadangan berkelanjutan harus berada di lebih dari satu vault, AWS Backup buat satu cadangan berkelanjutan sesuai dengan aturan pertama yang diproses. Setiap aturan berikutnya yang menentukan pencadangan berkelanjutan untuk sumber daya yang sudah memiliki cadangan berkelanjutan akan menghasilkan cadangan snapshot (periodik) sebagai gantinya.

Ketika rencana pencadangan berkelanjutan duplikat terjadi, cadangan snapshot yang dibuat setelah titik pemulihan berkelanjutan dapat menunjukkan statusCompleted with issues. Informasi terperinci dari titik pemulihan ini akan menunjukkan kesalahan yang mirip dengan“Enabling continuous backup failed, because of the following error: PITR already configured in backup plan: [ARN]”. Kesalahan ini menunjukkan bahwa sudah ada setidaknya satu cadangan berkelanjutan yang dikonfigurasi (untuk titik pemulihan yang berbeda dari yang berisi kesalahan). Pencadangan berkelanjutan pertama (titik pemulihan) dapat digunakan untuk pemulihan titik waktu (PITR) selama memiliki statusCOMPLETED.

Untuk mencegah pembuatan snapshot yang tidak diinginkan dengan masalah (dan pesan kesalahan), tinjau strategi pencadangan organisasi Anda. Jika perlu, sesuaikan rencana dan kebijakan pencadangan yang membuat beberapa cadangan berkelanjutan dari sumber daya yang sama.

Setelah Anda membuat penyesuaian yang menghasilkan hanya satu pencadangan berkelanjutan untuk sumber daya, cadangan snapshot akan dipertahankan sesuai dengan siklus hidup yang ditentukan dari rencana yang membuatnya, kemudian akan beralih ke EXPIRED dan dihapus. Pencadangan berkelanjutan dan kemampuan pemulihan point-in-time akan dipertahankan sesuai dengan aturan yang membuatnya.

Layanan yang didukung untuk pencadangan berkelanjutan dan PITR

AWS Backup mendukung pencadangan berkelanjutan dan pemulihan point-in-time untuk layanan dan aplikasi berikut:

Amazon S3

Untuk mengaktifkan PITR untuk cadangan S3, pencadangan berkelanjutan perlu menjadi bagian dari rencana cadangan.

Meskipun cadangan asli dari bucket sumber ini dapat memiliki PITR aktif, salinan tujuan lintas wilayah atau lintas akun tidak akan memiliki PITR, dan memulihkan dari salinan ini akan memulihkan ke waktu pembuatannya (salinan akan menjadi salinan snapshot) alih-alih memulihkan ke titik waktu tertentu.

AWS Backup untuk S3 bergantung pada penerimaan peristiwa S3 melalui Amazon EventBridge. Jika pengaturan ini dinonaktifkan di setelan notifikasi bucket S3, pencadangan berkelanjutan akan berhenti untuk bucket tersebut dengan setelan dimatikan. Untuk informasi selengkapnya, lihat Keter EventBridge gantungan Amazon untuk cadangan berkelanjutan S3.

Menonaktifkan AWS Backup EventBridge aturan Amazon juga akan mengakibatkan pencadangan terus menerus Anda dihentikan. Jika Anda memiliki rencana pencadangan aktif dengan aturan pencadangan berkelanjutan, ketika aturan itu dipicu ulang, EventBridge aturan Amazon AWS Backup akan membuat ulang dan cadangan berkelanjutan baru akan dibuat.

RDS

AWS Backup mendukung pencadangan berkelanjutan dan pemulihan point-in-time untuk semua instans Amazon RDS dan Aurora yang didukung oleh layanan Amazon RDS asli. AWS Backup tidak mendukung pencadangan berkelanjutan atau pemulihan point-in-time untuk cluster Amazon R Multi-AZ DS.

Jadwal pencadangan: Saat Anda mengaktifkan pencadangan berkelanjutan untuk instans Amazon RDS melalui AWS Backup, AWS Backup mengambil alih jendela pencadangan otomatis Amazon RDS (snapshot harian asli yang menghubungkan pemulihan point-in-time). AWS Backup menempatkan jendela cadangan otomatis ini di dekat jendela pemeliharaan Amazon RDS untuk mencegah konflik. Anda tidak dapat secara langsung mengonfigurasi jendela cadangan otomatis saat AWS Backup mengelola pencadangan berkelanjutan, tetapi Anda dapat memengaruhi penempatannya dengan menyesuaikan jendela pemeliharaan Amazon RDS Anda. Jendela cadangan otomatis memposisikan dirinya sendiri pada siklus pencadangan berikutnya. RDS mengambil snapshot sekali sehari, bahkan jika rencana cadangan memiliki frekuensi untuk backup snapshot selain sekali per hari.

catatan

AWS Backup tidak mengubah atau mengelola jendela pemeliharaan Amazon RDS. Jendela pemeliharaan tetap di bawah kendali Anda dan dapat disesuaikan melalui pengaturan Amazon RDS. Pekerjaan pencadangan yang dimulai oleh aturan snapshot dalam rencana cadangan Anda berjalan sesuai jadwal yang Anda tentukan dan masih dapat gagal jika tumpang tindih dengan jendela pemeliharaan. Jika ini terjadi, Anda menerima kesalahan yang mirip dengan “Pekerjaan pencadangan tidak dapat dimulai karena berada di dalam atau terlalu dekat dengan jendela pemeliharaan mingguan yang dikonfigurasi dalam instance RDS.” Untuk menghindari kesalahan ini, jadwalkan aturan pencadangan snapshot Anda di luar jendela pemeliharaan Amazon RDS yang dikonfigurasi.

Pengaturan: Setelah menerapkan aturan pencadangan AWS Backup berkelanjutan ke instans Amazon RDS, Anda tidak dapat membuat atau mengubah setelan pencadangan berkelanjutan di Amazon RDS. Anda harus melakukan modifikasi melalui AWS Backup konsol atau AWS Backup CLI. Saat Anda mengaktifkan pencadangan otomatis untuk pertama kalinya, pemadaman terjadi jika Anda mengubah periode retensi cadangan instans DB dari 0 menjadi nilai bukan nol. Rencanakan perubahan ini selama jendela pemeliharaan untuk meminimalkan dampak. Untuk informasi selengkapnya tentang mengaktifkan pencadangan otomatis, lihat Mengaktifkan pencadangan otomatis di Panduan Pengguna Amazon RDS.

Kontrol transisi pencadangan berkelanjutan untuk instans Amazon RDS kembali ke Amazon RDS:

Console
  1. Buka AWS Backup konsol di https://console.aws.amazon.com/backup.

  2. Di panel navigasi, pilih Rencana cadangan.

  3. Hapus semua rencana cadangan Amazon RDS dengan pencadangan berkelanjutan yang melindungi sumber daya itu.

  4. Pilih brankas cadangan. Hapus titik pemulihan cadangan berkelanjutan dari brankas cadangan Anda. Atau, tunggu periode retensi mereka berlalu, AWS Backup menyebabkan titik pemulihan dihapus secara otomatis.

Setelah Anda menyelesaikan langkah-langkah ini, AWS Backup akan mengalihkan kontrol cadangan berkelanjutan dari sumber daya Anda kembali ke Amazon RDS.

AWS CLI

Panggil operasi DisassociateRecoveryPoint API.

Untuk mempelajari selengkapnya, lihat DisassociateRecoveryPoint.

Izin IAM diperlukan untuk cadangan berkelanjutan Amazon RDS
  • Untuk digunakan AWS Backup untuk mengonfigurasi pencadangan berkelanjutan untuk database Amazon RDS Anda, verifikasi bahwa izin API rds:ModifyDBInstance ada di peran IAM yang ditentukan oleh konfigurasi rencana cadangan Anda. Untuk memulihkan cadangan berkelanjutan Amazon RDS, Anda harus menambahkan izin rds:RestoreDBInstanceToPointInTime ke peran IAM yang Anda kirimkan untuk pekerjaan pemulihan. Anda dapat menggunakan AWS Backup default service role untuk melakukan backup dan restore.

  • Untuk menggambarkan rentang waktu yang tersedia untuk pemulihan point-in-time, AWS Backup panggilan. rds:DescribeDBInstanceAutomatedBackups Di AWS Backup konsol, Anda harus memiliki izin rds:DescribeDBInstanceAutomatedBackups API dalam kebijakan terkelola AWS Identity and Access Management (IAM) Anda. Anda dapat menggunakan AWSBackupFullAccess atau kebijakan yang AWSBackupOperatorAccess dikelola. Kedua kebijakan memiliki semua izin yang diperlukan. Untuk informasi selengkapnya, lihat Kebijakan Terkelola.

Periode retensi: Saat Anda mengubah periode retensi PITR, AWS Backup panggilan ModifyDBInstance untuk menerapkan perubahan tersebut.

Saat AWS Backup mengaktifkan PITR untuk pertama kalinya pada instans Amazon RDS (mengubah retensi dari 0 menjadi nilai bukan nol), operasi dijadwalkan untuk terjadi selama jendela pemeliharaan database Anda berikutnya untuk mencegah downtime yang tidak terduga.

Skenario:

  • First-time Pengaktifan PITR: Saat PITR diaktifkan pada instans Amazon RDS untuk pertama kalinya (terlepas dari apakah itu dikelola oleh AWS Backup atau dikonfigurasi secara langsung), perubahan akan mengantri untuk jendela pemeliharaan berikutnya. AWS Backup secara otomatis membuat cadangan snapshot untuk mempertahankan cakupan sampai PITR menjadi aktif.

  • Perubahan retensi PITR: perubahan reten Non-zero si bukan nol berlaku segera tanpa restart.

  • Penonaktifan PITR: Perubahan dari retensi bukan nol ke nol dijadwalkan untuk jendela pemeliharaan berikutnya.

Cakupan cadangan selama transisi:

  • Pencadangan snapshot memberikan perlindungan sambil menunggu jendela pemeliharaan

  • Poin pemulihan berkelanjutan tersedia saat pekerjaan pencadangan berjalan setelah PITR diaktifkan

  • Tidak ada celah dalam perlindungan cadangan yang terjadi selama periode transisi

  • Granularitas pemulihan mungkin terbatas pada interval snapshot sampai PITR sepenuhnya aktif

Catatan: Mengh entikan instance RDS akan menghapus perubahan yang tertunda. Perubahan konfigurasi PITR akan diminta oleh pekerjaan pencadangan berikutnya dan diterapkan selama jendela pemeliharaan berikutnya.

Salinan cadangan berkelanjutan Amazon RDS:

  • Membuat salinan cadangan berkelanjutan Amazon RDS — Anda tidak dapat membuat salinan cadangan berkelanjutan Amazon RDS karena AWS Backup untuk Amazon RDS tidak mengizinkan menyalin log transaksi. Sebagai gant AWS Backup inya, buat snapshot dan salin dengan frekuensi yang ditentukan dalam rencana cadangan.

Memulihkan: Anda dapat melakukan pemulihan point-in-time menggunakan salah satu AWS Backup atau Amazon RDS. Untuk petunjuk AWS Backup konsol, lihat Mem ulihkan Database Amazon RDS. Untuk petunjuk Amazon RDS, lihat Mem ulihkan Instans DB ke waktu tertentu di Panduan Pengguna Amazon RDS.

Tip

Instans database multi AZ (zona ketersediaan) yang disetel ke Always On seharusnya tidak memiliki retensi cadangan yang disetel ke nol. Jika terjadi kesalahan, gunakan AWS CLI perintah al disassociate-recovery-point ih-alihdelete-recovery-point, lalu ubah setelan retensi menjadi 1 di pengaturan Amazon RDS Anda.

Untuk informasi umum tentang bekerja dengan Amazon RDS, lihat Panduan Pengguna Amazon RDS.

Contoh CLI untuk pemulihan RDS dan Aurora PITR

Contoh berikut menunjukkan cara mengembalikan database RDS dan Aurora ke suatu titik waktu menggunakan AWS Backup CLI dengan parameter metadata.

Contoh: Kembalikan database RDS ke titik waktu dengan metadata

aws backup start-restore-job \ --recovery-point-arn arn:aws:backup:us-east-1:123456789012:recovery-point:1EB3B5E7-9EB0-435A-A80B-108B488B0D45 \ --metadata '{"DBInstanceIdentifier":"restored-db-instance","Engine":"mysql","UseLatestRestorableTime":"false","RestoreTime":"2024-01-15T10:30:00Z"}' \ --iam-role-arn arn:aws:iam::123456789012:role/service-role/AWSBackupDefaultServiceRole \ --resource-type RDS \ --copy-source-tags-to-restored-resource
Contoh: Kembalikan cluster Aurora ke titik waktu

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

Parameter metadata berikut didukung untuk pemulihan RDS dan Aurora PITR:

  • DBInstanceIdentifier(RDS) atau DBClusterIdentifier (Aurora) - Diperlukan. Nama untuk database yang dipulihkan.

  • Mesin - Diperlukan. Mesin database (misalnya, mysql, postgres, aurora-mysql, aurora-postgresql).

  • UseLatestRestorableTime- Opsional. Setel ke “true” untuk mengembalikan ke waktu terbaru yang dapat dipulihkan, atau “false” untuk menentukan a RestoreTime.

  • RestoreTime- Opsional. Tanggal dan waktu untuk mengembalikan ke (format ISO 8601). Diperlukan UseLatestRestorableTime jika “salah”.

Salin tag ke sumber daya yang dipulihkan

Gunakan ben --copy-source-tags-to-restored-resource dera untuk menyalin tag dari database sumber ke database yang dipulihkan. Ini memastikan kontrol akses berbasis tag dan tag alokasi biaya dipertahankan.

Untuk detail lengkap tentang parameter pemulihan RDS PITR, lihat:

Aurora

Untuk mengaktifkan pencadangan berkelanjutan sumber daya Aurora Anda, lihat langkah-langkah di bagian pertama halaman ini.

Prosedur untuk mengembalikan cluster Aurora ke suatu titik waktu adalah variasi dari langkah-langkah untuk mengembalikan snapshot dari cluster aurora.

Saat Anda melakukan pemulihan titik waktu, konsol menampilkan bagian waktu pemulihan. Lihat Memulihkan cadangan berkelanjutan lebih jauh di halaman ini di Bek erja dengan pencadangan berkelanjutan.

penting

Pencadangan kontinu Aurora didukung di brankas yang dilindungi oleh AWS Backup Vault Lock, dan pengaturan retensi minimum dan maksimum vault diberlakukan pada titik pemulihan. Namun, pencadangan berkelanjutan Aurora tidak mendukung fitur vault yang memiliki celah udara secara logis. Untuk menggunakan vault yang memiliki celah udara secara logis dengan Aurora, gunakan cadangan snapshot berkala sebagai gantinya.

Tujuan titik pemulihan (RPO) untuk pencadangan kontinu Aurora biasanya kurang dari 5 menit, karena Aurora menyalin data ke Amazon S3 secara terus menerus di latar belakang. Gunakan LatestRestorableTime nilai untuk menentukan titik terbaru yang dapat Anda pulihkan.

Periode retensi dan jendela cadangan: Saat Anda mengaktifkan atau mengubah pengaturan pencadangan berkelanjutan untuk cluster Aurora, AWS Backup panggilan ModifyDBCluster untuk menerapkan perubahan tersebut. Ini dapat memodifikasi clusterPreferredBackupWindow. Jika Anda memiliki pembaruan konfigurasi lain yang menunggu jendela pemeliharaan berikutnya, mengaktifkan pencadangan berkelanjutan juga dapat segera menerapkan perubahan yang tertunda tersebut.

catatan

Untuk digunakan AWS Backup untuk mengonfigurasi pencadangan berkelanjutan untuk cluster Aurora Anda, verifikasi bahwa izin API rds:ModifyDBCluster ada di peran IAM yang ditentukan oleh konfigurasi rencana cadangan Anda.

SAP HANA pada instans Amazon EC2

Anda dapat membuat pencadangan berkelanjutan, yang dapat digunakan dengan pemulihan point-in-time (PITR) (perhatikan bahwa cadangan sesuai permintaan mempertahankan sumber daya dalam keadaan di mana mereka diambil; sedangkan PITR menggunakan pencadangan berkelanjutan yang merekam perubahan selama periode waktu tertentu).

Dengan pencadangan berkelanjutan, Anda dapat memulihkan database SAP HANA Anda pada instans EC2 dengan memutarnya kembali ke waktu tertentu yang Anda pilih, dalam presisi 1 detik (kembali maksimal 35 hari). Pencadangan berkelanjutan bekerja dengan terlebih dahulu membuat cadangan penuh sumber daya Anda, dan kemudian terus-menerus membuat cadangan log transaksi sumber daya Anda. Pemulihan PITR bekerja dengan mengakses cadangan penuh Anda dan memutar ulang log transaksi ke waktu yang Anda beri tahu AWS Backup untuk memulihkan.

Anda dapat memilih untuk melakukan backup berkelanjutan saat Anda membuat rencana cadangan AWS Backup menggunakan AWS Backup konsol atau API.

Untuk mengaktifkan pencadangan berkelanjutan menggunakan konsol
  1. Masuk ke Konsol Manajemen AWS, dan buka AWS Backup konsol di https://console.aws.amazon.com/backup.

  2. Di panel navigasi, pilih Paket cadangan, lalu pilih Buat paket cadangan.

  3. Di bawah Aturan cadangan, pilih Tambah aturan cadangan.

  4. Di bagian Konfigur asi aturan cadangan, pilih Aktifkan pencadangan berkelanjutan untuk sumber daya yang didukung.

Setelah Anda menonaktifkan PITR (point-in-time restore) untuk backup database SAP HANA, log akan terus dikirim AWS Backup hingga titik pemulihan berakhir (status sama. EXPIRED) Anda dapat mengubah ke lokasi cadangan log alternatif di SAP HANA untuk menghentikan transmisi log ke AWS Backup.

Titik pemulihan berkelanjutan dengan status STOPPED menunjukkan bahwa titik pemulihan berkelanjutan telah terganggu; yaitu, log yang dikirimkan dari SAP HANA ke AWS Backup yang menunjukkan perubahan inkremental ke database memiliki celah. Titik pemulihan yang terjadi dalam kesenjangan jangka waktu ini memiliki statusSTOPPED..

Untuk masalah yang mungkin Anda temui selama pekerjaan pemulihan cadangan berkelanjutan (titik pemulihan), lihat bagian pemecahan masalah SAP HANA Restore dari panduan ini.