Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Backup dan pemulihan layanan cloud-native AWS
Pendekatan pencadangan dan pemulihan Anda harus mencakup AWS layanan yang digunakan dalam beban kerja Anda. AWS menyediakan fitur dan opsi khusus layanan untuk mengelola dan berinteraksi dengan data Anda. Anda dapat menggunakan konsol, operasi AWS CLI SDKs, dan API untuk mengimplementasikan pencadangan dan pemulihan untuk AWS layanan yang Anda gunakan. Panduan ini mencakup [Amazon RDS](rds.md) dan [Amazon DynamoDB](dynamodb.md) sebagai contoh. AWS Backup mendukung DynamoDB dan Amazon RDS dan harus digunakan jika memenuhi kebutuhan Anda.
# Backup dan pemulihan untuk Amazon RDS
Amazon RDS menyertakan fitur untuk mengotomatiskan cadangan basis data. Amazon RDS membuat snapshot volume penyimpanan instans database Anda, mencadangkan seluruh instans DB, bukan database individual saja. Menggunakan Amazon RDS, Anda dapat membuat jendela cadangan untuk pencadangan otomatis, membuat snapshot instance database, dan berbagi serta menyalin snapshot di seluruh Wilayah dan akun.
Amazon RDS menyediakan dua opsi berbeda untuk mencadangkan dan memulihkan instans DB Anda:
+ **Pencadangan otomatis** menyediakan point-in-time pemulihan (PITR) instans DB Anda. Pencadangan otomatis diaktifkan secara default saat Anda membuat instans DB baru.
Amazon RDS melakukan pencadangan harian data Anda selama jendela cadangan yang Anda tentukan saat Anda membuat instans DB. Anda dapat mengonfigurasi periode retensi hingga 35 hari untuk pencadangan otomatis. Amazon RDS juga mengunggah log transaksi untuk instans DB ke Amazon S3 setiap 5 menit. Amazon RDS menggunakan backup harian Anda bersama dengan log transaksi database Anda untuk memulihkan instans DB Anda. Anda dapat mengembalikan instance ke detik apa pun selama periode retensi Anda, hingga `LatestRestorableTime` (biasanya, lima menit terakhir).
Untuk menemukan waktu restorable terbaru untuk instans DB Anda, gunakan panggilan API. `DescribeDBInstances` Atau lihat tab **Deskripsi** untuk database di konsol Amazon RDS.
Saat Anda memulai PITR, log transaksi digabungkan dengan cadangan harian yang paling tepat untuk mengembalikan instans DB Anda ke waktu yang diminta.
+ **Snapshot DB** adalah cadangan yang diprakarsai pengguna yang dapat Anda gunakan untuk mengembalikan instans DB Anda ke status yang dikenal sesering yang Anda suka. Anda kemudian dapat mengembalikan ke keadaan itu kapan saja. Anda dapat menggunakan konsol Amazon RDS atau panggilan `CreateDBSnapshot` API untuk membuat snapshot DB. Snapshot ini disimpan hingga Anda menggunakan konsol atau panggilan `DeleteDBSnapshot` API untuk menghapusnya secara eksplisit.
Kedua opsi cadangan ini didukung untuk Amazon RDS di AWS Backup, yang juga menyediakan fitur lainnya. Pertimbangkan AWS Backup untuk menggunakan paket cadangan standar untuk basis data Amazon RDS Anda, dan gunakan opsi pencadangan instans yang dimulai pengguna saat paket cadangan untuk database tertentu unik.
Amazon RDS mencegah akses langsung ke penyimpanan dasar yang digunakan oleh instans DB. Ini juga mencegah Anda dari langsung mengekspor database pada instance RDS DB ke disk lokalnya. Dalam beberapa kasus, Anda dapat menggunakan fungsi cadangan dan pemulihan asli menggunakan utilitas klien. Misalnya, Anda dapat menggunakan perintah [mysqldump dengan database Amazon RDS MySQL untuk mengekspor database ke mesin klien lokal](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Exporting.NonRDSRepl.html) Anda. Dalam beberapa kasus, Amazon RDS juga menyediakan opsi tambahan untuk melakukan pencadangan asli dan pemulihan database. Misalnya, Amazon RDS menyediakan prosedur tersimpan untuk [mengekspor dan mengimpor cadangan database RDS dari database](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Procedural.Importing.html) SQL Server.
Pastikan untuk menguji secara menyeluruh proses pemulihan database Anda dan dampaknya pada klien database sebagai bagian dari pendekatan pencadangan dan pemulihan Anda secara keseluruhan.
## Menggunakan catatan DNS CNAME untuk mengurangi dampak klien selama pemulihan database
Saat Anda memulihkan database dengan menggunakan PITR atau snapshot instans RDS DB, instans DB baru dengan titik akhir baru akan dibuat. Dengan cara ini, Anda dapat membuat beberapa instans DB dari snapshot atau titik waktu DB tertentu. Ada pertimbangan khusus saat Anda mengembalikan instans RDS DB untuk menggantikan instans RDS DB langsung. Misalnya, Anda harus menentukan bagaimana Anda akan mengarahkan klien database yang ada ke instance baru dengan gangguan dan modifikasi minimal. Anda juga harus memastikan kontinuitas dan konsistensi dalam data dalam database dengan mempertimbangkan waktu data yang dipulihkan dan waktu pemulihan ketika instance baru mulai menerima penulisan.
Anda dapat membuat catatan CNAME DNS terpisah yang menunjuk ke titik akhir instans DB Anda dan meminta klien Anda menggunakan nama DNS ini. Kemudian Anda dapat memperbarui CNAME untuk menunjuk ke titik akhir baru yang dipulihkan tanpa harus memperbarui klien database Anda.
Atur Time to Live (TTL) untuk catatan CNAME Anda ke nilai yang sesuai. TTL yang Anda tentukan menentukan berapa lama rekaman di-cache dengan resolver DNS sebelum permintaan lain dibuat. Penting untuk dicatat bahwa beberapa resolver atau aplikasi DNS mungkin tidak menghormati TTL, dan mereka mungkin menyimpan catatan lebih lama dari TTL. Untuk Amazon Route 53, jika Anda menentukan nilai yang lebih panjang (misalnya, 172800 detik, atau dua hari), Anda mengurangi jumlah panggilan yang harus dilakukan oleh resolver rekursif DNS ke Route 53 untuk mendapatkan informasi terbaru dalam catatan ini. Ini mengurangi latensi dan mengurangi tagihan Anda untuk layanan Route 53. Untuk informasi selengkapnya, lihat [Cara Amazon Route 53 merutekan lalu lintas untuk domain Anda](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/welcome-dns-service.html#welcome-dns-service-how-route-53-routes-traffic).
Aplikasi dan sistem operasi klien mungkin juga menyimpan informasi DNS yang harus Anda flush atau restart untuk memulai permintaan resolusi DNS baru dan mengambil catatan CNAME yang diperbarui.
Saat Anda memulai pemulihan basis data dan mengalihkan lalu lintas ke instans yang dipulihkan, verifikasi bahwa semua klien Anda menulis ke instance yang dipulihkan alih-alih instance Anda sebelumnya. Arsitektur data Anda mungkin mendukung pemulihan database Anda, memperbarui DNS untuk mengalihkan lalu lintas ke instans yang dipulihkan, dan kemudian memulihkan data apa pun yang mungkin masih ditulis ke instance Anda sebelumnya. Jika tidak demikian, Anda dapat menghentikan instans yang ada sebelum memperbarui catatan DNS CNAME. Kemudian semua akses berasal dari instance Anda yang baru dipulihkan. Ini untuk sementara dapat menyebabkan masalah koneksi untuk beberapa klien database Anda yang dapat Anda tangani secara individual. Untuk mengurangi dampak klien, Anda dapat melakukan pemulihan database selama jendela pemeliharaan.
Tulis aplikasi Anda untuk menangani kegagalan koneksi database dengan anggun dengan percobaan ulang menggunakan backoff eksponensial. Hal ini memungkinkan aplikasi Anda untuk pulih ketika koneksi database menjadi tidak tersedia selama pemulihan tanpa menyebabkan aplikasi Anda tiba-tiba crash.
Setelah menyelesaikan proses pemulihan, Anda dapat menyimpan instance sebelumnya dalam keadaan berhenti. Atau Anda dapat menggunakan aturan grup keamanan untuk membatasi lalu lintas ke contoh Anda sebelumnya sampai Anda puas bahwa itu tidak lagi diperlukan. Untuk pendekatan dekomisioning bertahap, pertama-tama batasi akses ke database yang sedang berjalan oleh grup keamanan. Anda akhirnya dapat menghentikan instance ketika tidak lagi diperlukan. Akhirnya, ambil snapshot dari instance database dan hapus.
# Backup dan pemulihan untuk DynamoDB
DynamoDB menyediakan PITR, yang membuat backup hampir terus menerus dari data tabel DynamoDB Anda. Saat diaktifkan, DynamoDB mempertahankan pencadangan tambahan tabel Anda selama 35 hari terakhir hingga Anda mematikannya secara eksplisit.
Anda juga dapat membuat cadangan sesuai permintaan tabel DynamoDB Anda dengan menggunakan konsol DynamoDB, DynamoDB API, atau DynamoDB. AWS CLI Untuk informasi selengkapnya, lihat [Mencadangkan tabel DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Backup.Tutorial.html). Anda dapat menjadwalkan backup periodik atau future dengan menggunakan AWS Backup, atau Anda dapat menyesuaikan dan mengotomatiskan pendekatan backup Anda dengan menggunakan fungsi Lambda. Untuk informasi selengkapnya tentang penggunaan fungsi Lambda untuk pencadangan DynamoDB, lihat posting blog [Solusi tanpa server untuk menjadwalkan Backup Amazon DynamoDB On-Demand Anda](https://aws.amazon.com/blogs/database/a-serverless-solution-to-schedule-your-amazon-dynamodb-on-demand-backup/). Jika Anda tidak ingin membuat skrip penjadwalan dan pekerjaan pembersihan, Anda dapat menggunakannya AWS Backup untuk membuat rencana cadangan. Paket cadangan mencakup jadwal dan kebijakan retensi untuk tabel DynamoDB Anda. AWS Backup membuat cadangan dan menghapus cadangan sebelumnya berdasarkan jadwal retensi Anda. AWS Backup juga mencakup opsi cadangan DynamoDB lanjutan yang tidak tersedia di layanan DynamoDB, termasuk penyimpanan berjenjang berbiaya lebih rendah, dan salinan lintas akun dan lintas wilayah. Untuk informasi selengkapnya, lihat Cadangan [DynamoDB lanjutan](https://docs.aws.amazon.com/aws-backup/latest/devguide/advanced-ddb-backup.html).
Anda harus mengatur hal berikut secara manual pada tabel DynamoDB yang dipulihkan:
+ Kebijakan penskalaan otomatis
+ Kebijakan IAM
+ CloudWatch Metrik dan alarm Amazon
+ Tanda
+ Pengaturan aliran
+ Pengaturan TTL
Anda hanya dapat mengembalikan seluruh data tabel ke tabel baru dari cadangan. Anda dapat menulis ke tabel yang dipulihkan hanya setelah tabel tersebut aktif.
Proses pemulihan Anda harus mempertimbangkan bagaimana klien akan diarahkan untuk menggunakan nama tabel yang baru dipulihkan. Anda dapat mengonfigurasi aplikasi dan klien Anda untuk mengambil nama tabel DynamoDB dari file konfigurasi, nilai Parameter Store AWS Systems Manager , atau referensi lain yang dapat diperbarui secara dinamis untuk mencerminkan nama tabel yang harus digunakan klien.
Sebagai bagian dari proses pemulihan, Anda harus mempertimbangkan dengan cermat proses peralihan Anda. Anda dapat memilih untuk menolak akses ke tabel DynamoDB yang ada melalui izin IAM dan mengizinkan akses ke tabel baru Anda. Anda kemudian dapat memperbarui konfigurasi aplikasi dan klien untuk menggunakan tabel baru. Anda mungkin juga perlu mendamaikan perbedaan antara tabel DynamoDB yang ada dan tabel DynamoDB yang baru dipulihkan.