Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Memilih strategi pemulihan bencana Anda untuk beban kerja Amazon DynamoDB
Sebelum memilih strategi DynamoDB DR, Anda harus menentukan persyaratan pemulihan bisnis Anda. Analisis awal ini mencegah rekayasa berlebihan yang mahal sambil membantu memastikan Anda memenuhi kebutuhan kelangsungan bisnis yang kritis. Pendekatan optimal menyeimbangkan empat faktor utama: kecepatan pemulihan, toleransi kehilangan data, kompleksitas implementasi, dan biaya operasional.
Mari kita pahami dua metrik utama yang membentuk strategi DR Anda:
+ **Tujuan waktu pemulihan (RTO)** — Ini adalah penundaan maksimum yang dapat diterima antara gangguan layanan dan pemulihannya. RTO menjawab pertanyaan, Berapa lama kita bisa turun? Ini dapat berkisar dari nol (membutuhkan ketersediaan berkelanjutan) hingga beberapa jam, tergantung pada kebutuhan bisnis.
+ **Tujuan titik pemulihan (RPO)** - Ini mewakili jumlah waktu maksimum yang dapat diterima sejak titik pemulihan data terakhir. RPO menjawab pertanyaan, Berapa banyak data yang bisa kita hilangkan? Misalnya, jika RPO Anda adalah 1 jam, solusi DR Anda harus memastikan Anda dapat memulihkan data ke titik tidak lebih dari 1 jam sebelum insiden dimulai.
Pilihan strategi DynamoDB DR Anda harus didasarkan pada faktor-faktor berikut:
+ Analisis dampak bisnis dari gangguan layanan
+ Penilaian risiko skenario bencana yang berbeda
+ Biaya penerapan setiap opsi DR
+ Persyaratan peraturan untuk perlindungan dan ketersediaan data
## Poin keputusan untuk memilih pendekatan DynamoDB DR
Saat memilih pendekatan DynamoDB DR yang sesuai, Anda harus mengevaluasi persyaratan bisnis spesifik Anda, toleransi risiko, persyaratan peraturan, dan kendala anggaran.
**Untuk persyaratan downtime nol** di mana kerugian pendapatan selama pemadaman secara signifikan melebihi biaya operasional tambahan, [tabel global, termasuk tabel](GlobalTables.md) [Multi-region strong consistency](V2globaltables_HowItWorks.md#V2globaltables_HowItWorks.consistency-modes) (MRSC), arsitektur menyediakan kemampuan pemulihan instan. Meskipun solusi ini membawa biaya operasional yang lebih tinggi, solusi ini memberikan kegagalan langsung dan ketersediaan berkelanjutan, menjadikannya penting untuk aplikasi penting di mana waktu henti secara langsung berdampak pada aliran pendapatan.
**Budget-conscious organisasi dengan persyaratan pemulihan yang fleksibel** dapat menggunakan solusi yang lebih hemat biaya ketika aplikasi dapat mentolerir jam downtime selama skenario pemulihan. [On-demand cadangan](backuprestore_HowItWorks.md), [AWS Backup](backuprestore_HowItWorksAWS.md), atau strategi [ekspor Amazon Simple Storage Service](S3DataExport.HowItWorks.md) menawarkan biaya operasional yang jauh lebih rendah sambil menerima kerangka waktu pemulihan yang lebih lama. Pendekatan ini bekerja dengan baik untuk aplikasi di mana kelangsungan bisnis penting tetapi pemulihan segera tidak dibenarkan secara finansial, memberikan opsi untuk menyeimbangkan perlindungan dengan optimalisasi biaya.
Persyaratan **kepatuhan terhadap peraturan** memerlukan solusi otomatis yang memastikan kesiapan audit dan kebijakan penyimpanan data yang tepat. [AWS Backup dengan replikasi lintas wilayah](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/copy-amazon-dynamodb-tables-across-accounts-using-aws-backup.html) menyediakan otomatisasi kepatuhan yang komprehensif sambil mempertahankan struktur biaya yang lebih tinggi. Pendekatan ini memberikan dokumentasi, kebijakan retensi, dan distribusi geografis yang diperlukan oleh kerangka peraturan sambil mengurangi overhead kepatuhan manual dan membantu memastikan prosedur pencadangan yang konsisten di seluruh organisasi.
**Perlindungan terhadap skenario kesalahan manusia** seperti penghapusan yang tidak disengaja atau korupsi data, [pemulihan point-in-time](PointInTimeRecovery_Howitworks.md) (PITR) yang dikombinasikan dengan perlindungan [penghapusan](WorkingWithTables.Basics.md#WorkingWithTables.Basics.DeletionProtection) menawarkan perlindungan berkelanjutan dalam satu Wilayah. Meskipun solusi ini memberikan perlindungan yang sangat baik terhadap kesalahan operasional dan mempertahankan biaya yang wajar, Anda harus menerima batasan wilayah Tunggal dan merencanakan strategi tambahan untuk skenario DR sejati yang melibatkan pemadaman regional atau kegagalan infrastruktur.
## Opsi pemulihan bencana
DynamoDB menawarkan opsi untuk mencadangkan dan memulihkan data tabel Anda, memberikan ketahanan terhadap berbagai skenario kegagalan. Ada empat solusi DR utama yang melayani kebutuhan yang berbeda:
+ Point-in-time pemulihan (PITR) untuk perlindungan data berkelanjutan
+ On-demand backup dan restore untuk perlindungan yang fleksibel
+ Pencadangan dan pemulihan terjadwal untuk perlindungan reguler otomatis
+ Tabel global untuk pemulihan instan beban kerja kritis misi
- ** Perlindungan data berkelanjutan **
- **Opsi Backup:** PITR
- **Fitur:** Pencadangan berkelanjutan dipertahankan hingga 35 hari, memungkinkan PITR dalam hitungan detik setiap saat di jendela cadangan yang dikonfigurasi
- **RPO:** Detik
- **RTO:** Menit
- **Ketersediaan Backup:** Hanya AWS Wilayah Tunggal
- **Biaya cadangan bulanan:** $0,20 per GB-month
- **One-time biaya restorasi:** $0,15 per GB
- ** On-demand perlindungan **
- **Opsi Backup:** On-demand backup dan restore
- **Fitur:** On-demand proses
- **RPO:** Jam
- **RTO:** Menit
- **Ketersediaan Backup:** AWS Wilayah Tunggal
- **Biaya cadangan bulanan:** $0,10 per GB-month
- **One-time biaya restorasi:** $0,15 per GB
- ** Pencadangan dan pemulihan terjadwal **
- **Opsi Backup:** AWS Backup / **Fitur:** Opsi penjadwalan yang fleksibel (per jam hingga bulanan) / **RPO:** Jam / **RTO:** Menit / **Ketersediaan Backup:** Cross-Region cadangan didukung / **Biaya cadangan bulanan:** $0,10 per GB-month / **One-time biaya restorasi:** $0,15 per GB
- **Opsi Backup:** Ekspor dan impor Amazon S3 (dengan PITR diaktifkan) / **Fitur:** Ekspor data lengkap atau tambahan dalam jendela PITR ke bucket / **RPO:** Menit / **RTO:** Jam / **Ketersediaan Backup:** Cross-Region cadangan ke ember mungkin / **Biaya cadangan bulanan:** $0,10 per GB / **One-time biaya restorasi:** $0,15 per GB
- ** Pemulihan instan untuk beban kerja yang sangat penting **
- **Opsi Backup:** Tabel global / **Fitur:** Solusi yang dikelola sepenuhnya, Multi-wilayah, tabel multi-aktif / **RPO:** Detik / **RTO:** Nol / **Ketersediaan Backup:** Propagasi otomatis perubahan data dari Wilayah primer ke sekunder dalam milidetik / **Biaya cadangan bulanan:** $0,625 per juta unit permintaan tulis yang direplikasi / **One-time biaya restorasi:** 0
- **Opsi Backup:** Tabel MRSC / **Fitur:** Solusi yang dikelola sepenuhnya, Multi-wilayah, tabel multi-aktif dengan konsistensi yang kuat / **RPO:** Nol / **RTO:** Nol / **Ketersediaan Backup:** Penyebaran otomatis perubahan data dari Wilayah primer ke sekunder secara real time / **Biaya cadangan bulanan:** $0,625 per juta unit permintaan tulis yang direplikasi / **One-time biaya restorasi:** 0
**catatan**
Biaya yang ditunjukkan pada tabel di atas didasarkan pada harga Wilayah Virginia N. dari [DynamoDB](https://aws.amazon.com/dynamodb/pricing/) harga untuk kapasitas sesuai permintaan.
### Perlindungan data berkelanjutan menggunakan PITR
Bayangkan pengecer e-commerce yang menggunakan DynamoDB untuk manajemen inventaris, katalog produk, dan pemrosesan pesanan. Saat mempersiapkan acara Black Friday, tim pengembangan secara tidak sengaja menghapus katalog produk mereka. Menggunakan PITR, mereka dapat mengembalikan ribuan catatan ke momen pra-insiden yang tepat dalam 30 menit, mencegah jutaan kerugian pendapatan potensial.
Saat Anda mengaktifkan PITR, DynamoDB secara otomatis mencadangkan data tabel Anda dengan perincian per detik. Anda dapat mengembalikan tabel Anda ke detik tertentu dalam periode pemulihan yang dikonfigurasi, yang berkisar antara 1-35 hari. Khususnya, mengurangi periode retensi tidak mengurangi biaya, membuat periode retensi yang diperpanjang menjadi netral biaya. Fitur PITR menyediakan kemampuan pemulihan granular dengan RPO minimal (detik) dan RTO yang wajar (menit hingga jam), sehingga cocok untuk berbagai persyaratan DR. Real-world skenario menunjukkan bagaimana RPO minimal PITR dan RTO yang masuk akal mengubah potensi bencana bisnis menjadi operasi pemulihan yang dapat dikelola, baik melindungi terhadap kesalahan manusia, kegagalan aplikasi, atau memenuhi persyaratan peraturan yang ketat.
Untuk mempelajari lebih lanjut, lihat [Mengaktifkan pemulihan point-in-time di DynamoDB, yang memberikan petunjuk terperinci tentang cara mengonfigurasi PITR dan memulihkan tabel menggunakan, serta DynamoDB](Point-in-time-recovery.md) API. CloudFormation AWS CLI
### Perlindungan fleksibel menggunakan pencadangan dan pemulihan sesuai permintaan
Pertimbangkan penyedia layanan kesehatan yang merencanakan migrasi sistem catatan kesehatan elektronik (EHR) utama. Menggunakan pencadangan tonggak sejarah selama proses migrasi akan memungkinkan mereka memenuhi persyaratan HIPAA yang ketat sambil memberikan bukti audit yang tidak dapat diubah kepada tim hukum mereka. Jika masalah kepatuhan muncul selama migrasi, mereka dapat menunjukkan prosedur penanganan data yang tepat dan memulihkan ke pos pemeriksaan yang sesuai, memastikan perlindungan data pasien dan kepatuhan terhadap peraturan.
Dengan fitur cadangan berdasarkan permintaan DynamoDB, Anda dapat membuat cadangan dan memulihkan tabel sesuai kebutuhan. On-demand backup beroperasi secara asinkron, menangkap semua perubahan hingga saat permintaan cadangan dibuat. On-demand Kemampuan pencadangan memberi Anda kontrol yang tepat atas strategi perlindungan data Anda sambil mendukung berbagai persyaratan operasional dan kepatuhan.
On-demand pencadangan dan pemulihan menawarkan kemampuan restorasi tabel yang fleksibel di skenario Same-region dan Cross-region, memberi Anda opsi pemulihan serbaguna. Untuk meningkatkan kelangsungan bisnis, DynamoDB memberikan penyelesaian pencadangan seketika terlepas dari ukuran tabel, sementara restorasi di wilayah yang sama memberikan kinerja optimal untuk meminimalkan waktu pemulihan dan memaksimalkan ketersediaan operasional.
Dengan menerapkan strategi pencadangan harian, Anda dapat mencapai RPO 24 jam yang andal, dilengkapi dengan RTO yang dapat diprediksi dari menit hingga jam. Dengan menggunakan pendekatan terstruktur untuk perlindungan data ini, Anda dapat merencanakan dan menjalankan strategi pencadangan dan pemulihan Anda secara efektif sambil mempertahankan operasi bisnis.
Untuk mempelajari lebih lanjut tentang operasi pencadangan dan pemulihan DynamoDB, [lihat Mencadangkan tabel DynamoDB [dan](Restore.Tutorial.md) Memulihkan tabel DynamoDB](backuprestore_HowItWorks.md) dari cadangan.
### Perlindungan reguler otomatis menggunakan pencadangan dan pemulihan terjadwal
DynamoDB menyediakan beberapa mekanisme perlindungan yang dapat diotomatisasi melalui alur kerja terjadwal, AWS termasuk Backup dengan rencana cadangan yang dapat disesuaikan untuk pemulihan operasional dan kemampuan ekspor Amazon S3 untuk arsip jangka panjang, migrasi data lintas wilayah, dan operasi berkelanjutan. Dengan menerapkan jadwal perlindungan reguler otomatis ini, Anda dapat memastikan perlindungan data yang konsisten tanpa intervensi manual sambil menyeimbangkan tujuan pemulihan dengan biaya penyimpanan.
#### Backup dan restore menggunakan AWS Backup dan rencana cadangan
Pertimbangkan bank multinasional dengan operasi yang mencakup 15 negara yang perlu menambahkan perlindungan tingkat perusahaan ke sistem deteksi penipuan berbasis Amazon DynamoDB mereka; perlindungan yang dapat beradaptasi dengan beragam persyaratan peraturan di seluruh yurisdiksi sambil memastikan ketersediaan berkelanjutan.
Menggunakan replikasi Multi-wilayah dan kemampuan lintas akun AWS Backup, bank menerapkan arsitektur perlindungan yang secara otomatis mereplikasi data transaksi penting di seluruh Wilayah sambil mempertahankan kontrol akses yang ketat untuk unit bisnis yang berbeda. Ketika regulator di tiga negara secara bersamaan meminta data transaksi historis untuk audit kepatuhan, kebijakan cadangan standar bank dan jejak audit terperinci memungkinkan mereka untuk memberikan dokumentasi lengkap dalam beberapa jam, bukan minggu.
Dengan AWS Backup Anda dapat mengambil cadangan reguler data Anda dalam akun tertentu AWS . Dengan paket cadangan, Anda dapat menyalin cadangan ini ke Wilayah yang berbeda baik sesuai permintaan atau secara otomatis sebagai bagian dari rencana pencadangan terjadwal. Paket Backup menawarkan opsi penjadwalan yang fleksibel, sehingga Anda dapat memilih frekuensi yang sesuai dengan kebutuhan Anda: setiap jam, setiap 12 jam, harian, mingguan, atau bulanan. Pencadangan DynamoDB akan disalin di seluruh Wilayah berdasarkan frekuensi yang dipilih.
[AWS Backup Vault Lock](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html) memberlakukan pencadangan tulis sekali, baca-banyak (WORM) untuk membantu melindungi cadangan (titik pemulihan) di brankas cadangan Anda dari tindakan yang tidak disengaja atau berbahaya dan memberikan perlindungan terhadap serangan ransomware. Anda dapat mencapai RPO 1 jam dan RTO mulai dari beberapa menit hingga jam, tergantung pada ukuran meja.
[Untuk memahami cara AWS Backup mengintegrasikan dengan DynamoDB dan mempelajari fitur cadangan, serta praktik terbaik, lihat Menggunakan dengan DynamoDB. AWS Backup](backuprestore_HowItWorksAWS.md)
#### Amazon Simple Storage Service (Amazon S3) ekspor dan impor
Bayangkan sebuah perusahaan jasa keuangan global yang perlu memenuhi persyaratan peraturan untuk data transaksi di berbagai yurisdiksi sambil mempertahankan ketersediaan 99,99%. Mereka dapat membangun strategi data perusahaan mereka di sekitar kemampuan ekspor dan impor Amazon S3, menerapkan replikasi data lintas wilayah untuk mematuhi undang-undang kedaulatan data di 12 negara dan menetapkan mekanisme failover Regional. Jika terjadi pemadaman Eropa, sistem ini akan secara otomatis menjalankan prosedur failover, membantu memastikan nol gangguan perdagangan dan operasi berkelanjutan.
Perusahaan menggunakan fitur export/import to Amazon S3 untuk membuat cadangan penuh harian dan ekspor tambahan per jam ke bucket Amazon S3 khusus yurisdiksi di seluruh 12 Wilayah, membantu memastikan kepatuhan dengan persyaratan residensi data lokal. Setiap tabel Regional secara otomatis mengekspor data transaksi ke bucket terenkripsi dalam yurisdiksi yang sama, sementara replikasi lintas wilayah memberikan redundansi tambahan untuk kumpulan data penting. Ekspor tidak mengkonsumsi unit kapasitas baca (RCU) dan tidak berdampak pada kinerja atau ketersediaan tabel. Jika ada penurunan pada salah satu Wilayah tempat perusahaan beroperasi, prosedur pemulihan otomatis dapat mengembalikan ekspor terbaru ke Wilayah alternatif, memungkinkan operasi perdagangan penuh untuk dilanjutkan. export/import Strategi ini memberikan kepatuhan terhadap peraturan melalui jalur audit yang tidak dapat diubah dan kemampuan DR yang kuat, memungkinkan perusahaan untuk mempertahankan operasi berkelanjutan sambil mempertahankan riwayat transaksi lengkap yang dapat dikembalikan ke tabel baru di Wilayah mana pun yang tersedia, membantu memastikan kehilangan data dan waktu henti minimal selama kegagalan infrastruktur regional.
Dengan ekspor DynamoDB ke Amazon S3, Anda dapat mengekspor data dari tabel DynamoDB pada suatu titik dalam jendela PITR Anda. Anda dapat mencapai RPO beberapa menit dan RTO mulai dari beberapa menit hingga jam, tergantung pada ukuran tabel.
Untuk panduan implementasi terperinci tentang mengonfigurasi ekspor, lihat [Meminta ekspor tabel di](S3DataExport.HowItWorks.md) DynamoDB. Untuk memulihkan operasi dan mengimpor data dari, lihat [Meminta impor tabel di DynamoDB](S3DataImport.HowItWorks.md).
### Pemulihan instan beban kerja kritis misi menggunakan tabel global
Tabel global DynamoDB memberikan kemampuan failover yang kuat selama gangguan Wilayah primer; aplikasi dapat segera mengarahkan lalu lintas ke Wilayah yang sehat dan melanjutkan operasi. Tabel global memiliki dua opsi: Konsistensi akhir multi-wilayah (MREC) dan Konsistensi kuat Multi-wilayah (MRSC).
#### Multi-Region konsistensi akhirnya
Bayangkan sebuah layanan e-commerce multinasional yang melayani jutaan pelanggan di seluruh Amerika Utara, Eropa, dan Asia-Pacific yang dapat menghadapi tantangan operasional yang signifikan tanpa infrastruktur global yang tepat. Perusahaan mungkin berjuang dengan waktu checkout yang lambat untuk pelanggan internasional, persyaratan kepatuhan yang kompleks di berbagai yurisdiksi, dan gangguan yang sering terjadi selama pemadaman regional. Dengan menerapkan tabel global DynamoDB, mereka dapat mengubah operasi mereka: pelanggan di Tokyo akan mengalami waktu checkout secepat kilat yang sama dengan yang ada di New York melalui akses data lokal latensi sangat rendah. Jika peristiwa cuaca buruk mengganggu Wilayah utama mereka, aplikasi mereka dapat dengan mulus gagal ke Wilayah lain tanpa memperhatikan pelanggan, mempertahankan ketersediaan tinggi, meningkatkan latensi baca dan tulis global, mendukung kepatuhan peraturan di seluruh Wilayah tempat mereka beroperasi, dan mendapatkan kepercayaan diri untuk memperluas ke pasar baru dengan mengetahui infrastruktur mereka dapat berskala andal di seluruh dunia sambil memenuhi persyaratan lokal.
Tabel global DynamoDB menawarkan solusi database multi-aktif yang dikelola sepenuhnya, Multi-wilayah, yang dirancang untuk memberikan kinerja baca dan tulis yang cepat dan terlokalisasi untuk aplikasi global yang diskalakan secara besar-besaran. Untuk tujuan DR, Anda dapat menentukan Wilayah utama dan Wilayah DR di mana Anda ingin tabel tersedia. DynamoDB secara otomatis menyebarkan perubahan data yang sedang berlangsung dari Region utama ke replika DR. Dengan pengaturan MREC, Anda dapat mencapai RPO beberapa detik dan RTO nol.
Untuk panduan tentang membuat dan mengelola tabel global DynamoDB, [lihat Tabel global - Replikasi multi-wilayah](GlobalTables.md) untuk DynamoDB.
#### Multi-Region konsistensi yang kuat
Bayangkan platform perbankan digital terkemuka yang memproses jutaan transaksi setiap hari di tiga benua yang dapat mengalami pemadaman regional yang signifikan selama jam perdagangan puncak. Alih-alih berebut dengan prosedur DR manual dan menghadapi potensi jutaan kerugian, arsitektur mereka akan mengaktifkan DR dalam hitungan detik, dengan mulus mengarahkan lalu lintas ke Wilayah yang sehat tanpa pelanggan menyadari adanya gangguan. Aplikasi seluler bank dapat terus memproses aplikasi pinjaman secara real-time, platform perdagangan mereka akan mempertahankan waktu respons milidetik untuk transaksi frekuensi tinggi, dan saldo akun pelanggan akan tetap disinkronkan dengan sempurna di semua Wilayah.
Dengan tabel global Multi-region yang sangat konsisten, Anda dapat membangun aplikasi dengan nol RPO. RPO nol berarti aplikasi Anda dapat membaca versi terbaru dari data DynamoDB, bahkan jika gangguan aplikasi mengharuskan Anda untuk mengalihkan lalu lintas ke Wilayah yang berbeda.
**catatan**
Untuk keperluan DR, Anda dapat menggunakan dua replika dan satu Wilayah saksi.
Untuk informasi selengkapnya tentang membuat tabel global MRSC, lihat [Cara kerja tabel global](V2globaltables_HowItWorks.md).