Backup dan Point-in-Time Recovery DynamoDB: Panduan Lengkap

DynamoDB melindungi data Anda dengan dua cara. On-demand backup adalah snapshot penuh yang Anda ambil dan simpan tanpa batas waktu. Point-in-time recovery (PITR) adalah backup berkelanjutan dan otomatis yang memungkinkan Anda memulihkan tabel ke detik mana pun dalam jendela bergulir. Keduanya memulihkan ke tabel baru — mereka alat pemulihan, bukan tombol undo.

Untuk audit log ini tak bisa ditawar. Ia catatan kepatuhan yang tak bisa diubah; migrasi buruk yang menulis ulang peristiwa, atau penghapusan massal tak sengaja, harus dapat dipulihkan ke saat sebelum kesalahan.

Bagaimana cara kerja backup dan point-in-time recovery DynamoDB?

DynamoDB menawarkan dua jenis backup. Point-in-time recovery (PITR) mengambil backup otomatis berkelanjutan, memungkinkan Anda memulihkan ke detik mana pun dalam jendela 1-sampai-35-hari yang dapat dikonfigurasi. On-demand backup adalah snapshot penuh manual yang disimpan tanpa batas waktu. Keduanya memulihkan ke tabel baru, tak pernah menimpa yang asli, sehingga mereka alat pemulihan alih-alih undo di tempat.

• PITR = backup berkelanjutan, pulihkan ke detik mana pun dalam jendela yang dapat dikonfigurasi 1 sampai 35 hari (dulunya tetap 35).
• On-demand backup = snapshot penuh manual disimpan selama Anda mau, independen dari jendela PITR.
• Pemulihan menciptakan tabel baru. Anda memulihkan ke nama baru, lalu cut over — yang asli tak tersentuh.
• PITR diharga berdasarkan ukuran tabel, bukan jumlah titik pemulihan — perkirakan dengan Kalkulator Harga DynamoDB.

Masalahnya: kesalahan yang tak bisa Anda undo di tempat

DynamoDB tak punya transaction log yang bisa Anda roll back dan tak ada "undo" pada penulisan. Jika skrip migrasi menulis ulang field action setiap peristiwa, atau seseorang menjalankan penghapusan yang lebih luas dari yang dimaksud, tabelnya sekadar berada dalam keadaan yang salah. Tanpa backup, datanya lenyap.

Untuk audit log — yang seluruh nilainya adalah menjadi catatan yang tepercaya — "kita tak bisa mengembalikan peristiwa Selasa lalu" adalah kegagalan kepatuhan, bukan sekadar ketidaknyamanan.

Bagaimana backup dan PITR bekerja

Point-in-time recovery, setelah diaktifkan, mengambil backup otomatis berkelanjutan. Sesuai dokumen AWS, PITR memberi Anda backup berkelanjutan terkelola penuh atas data tabel dengan granularitas pemulihan per-detik. Jendelanya dapat dikonfigurasi dari 1 sampai 35 hari via RecoveryPeriodInDays, dan Anda bisa memulihkan ke detik mana pun di dalamnya — hingga kira-kira lima menit di belakang waktu nyata (LatestRestorableDateTime) — termasuk ke region berbeda.

Satu tepi penting: mengurangi periode pemulihan segera memangkas titik pemulihan terawal, dan menonaktifkan lalu mengaktifkan kembali PITR mereset waktu mulai yang dapat dipulihkan — Anda kehilangan riwayat berkelanjutan sebelumnya.

PITR juga menjadi gerbang bagi ekspor ke S3 terkelola: ekspor itu membaca dari backup berkelanjutan yang sama, jadi dengan PITR mati, ExportTableToPointInTime gagal dengan PointInTimeRecoveryUnavailableException.

On-demand backup terpisah: snapshot seluruh-tabel manual yang Anda buat secara eksplisit dan simpan tanpa batas waktu, berguna untuk checkpoint pra-migrasi atau arsip kepatuhan jangka panjang di luar jendela PITR 35-hari. Request-nya diproses seketika dan backup-nya bisa dipulihkan dalam hitungan menit, tidak memakai throughput tabel sama sekali, dan tak ada batasan berapa banyak yang Anda simpan. Satu catatan jujur dari dokumentasinya: on-demand backup tidak menjamin konsistensi kausal antar Item — selisih antar pembaruan "usually much less than a second", tetapi backup yang diambil di tengah ledakan penulisan bukanlah satu momen beku tunggal.

Yang tidak dikembalikan oleh sebuah pemulihan

Sebuah pemulihan membuat ulang data tabel beserta index-nya — bukan wiring operasionalnya. Menurut dokumentasi AWS, Anda harus mengonfigurasi ulang secara manual pada tabel hasil pemulihan: kebijakan auto scaling, kebijakan IAM, metrik dan alarm CloudWatch, tag, pengaturan stream, TTL, deletion protection, dan PITR itu sendiri. Memulihkan dari backup lalu lupa mengaktifkan kembali PITR adalah cara insiden berikutnya menjadi tak terpulihkan.

Saat pemulihan Anda bisa sengaja mengubah sebagian pengaturan — mode penagihan, kapasitas provisioned, kunci enkripsi — dan Anda bisa mengecualikan sebagian atau seluruh secondary index, yang membuat pemulihan lebih cepat dan lebih murah kalau Anda bisa membangunnya ulang belakangan. Pemulihan juga bisa menyasar Region berbeda, dan sebuah pemulihan tak pernah menimpa tabel yang sudah ada.

Backup terjadwal dengan AWS Backup

On-demand backup milik DynamoDB sendiri tidak punya penjadwal. Untuk backup berulang dengan retensi, DynamoDB terintegrasi secara native dengan AWS Backup (dokumentasi AWS): backup plan memberi Anda backup terjadwal dengan aturan siklus hidup (termasuk tiering ke cold storage), salinan lintas-akun dan lintas-Region otomatis untuk DR, kunci KMS independen lewat backup vault, dan Vault Lock untuk postur kepatuhan WORM yang tak bisa dihapus diam-diam oleh siapa pun. Dua jebakan operasional: AWS Backup adalah opt-in eksplisit per akun per Region, dan backup yang dibuatnya (tipe AWS_BACKUP) tidak bisa dihapus dari konsol DynamoDB — kelolalah di AWS Backup.

Keduanya memulihkan ke tabel baru, bukan menimpa yang sudah ada:

Contoh yang dikerjakan: pulih dari migrasi buruk

Sebuah migrasi yang dimaksudkan untuk menambah atribut expiresAt malah menimpa action pada setiap peristiwa dengan string kosong. PITR aktif dengan jendela 35-hari, jadi Anda memulihkan ke detik sebelum migrasi berjalan:

Tabel yang rusak tetap tak tersentuh sementara Anda memverifikasi pemulihan — Anda membandingkan peristiwa yang dipulihkan terhadap yang langsung, memastikan nilai action kembali, lalu mengarahkan ulang aplikasi. Tak ada yang dihancurkan dalam pemulihan itu sendiri.

Jika kehilangannya segelintir Item ketimbang kerusakan seluruh-tabel, Anda bisa alih-alih memeriksa data langsung dan salinan yang dipulihkan lalu menyalin hanya baris yang terkena — lihat menyalin tabel DynamoDB.

Lakukan di DynoTable

Sebuah pemulihan hanya sebagus verifikasi Anda atasnya. Setelah memulihkan ke audit-log-restored, Anda perlu benar-benar melihat peristiwa yang dipulihkan dan memastikan mereka cocok dengan yang seharusnya sebelum kesalahan.

DynoTable terhubung ke tabel yang dipulihkan seperti tabel lainnya, jadi Anda bisa meng-query peristiwa tenant yang terkena, memastikan nilai action benar, dan membandingkan terhadap tabel langsung sebelum Anda cut over — mengubah pemulihan dari lompatan iman menjadi pemulihan terverifikasi.

Anda juga bisa mengekspor peristiwa yang dipulihkan untuk catatan kepatuhan offline — lihat ekspor DynamoDB ke CSV.

Jebakan dan langkah selanjutnya

• Aktifkan PITR sebelum Anda membutuhkannya. Ia hanya melindungi sejak saat ia aktif — tak ada pemulihan retroaktif. Nyalakan untuk tabel apa pun yang datanya tak mampu Anda hilangkan.
• Menonaktifkan PITR mereset jendela. Mematikan lalu menyalakannya kembali menghapus riwayat berkelanjutan; waktu mulai yang dapat dipulihkan dimulai lagi sejak pengaktifan ulang.
• Pemulihan tak instan atau gratis. Sebuah pemulihan memprovisikan seluruh tabel baru dan memakan waktu sebanding ukuran; anggarkan untuk durasi dan tabel ekstranya.
• 35 hari bukan arsip. Untuk retensi di luar jendela PITR, ambil on-demand backup atau ekspor ke S3 — PITR adalah jendela pemulihan, bukan penyimpanan jangka panjang.

Itu menutup loop operasi audit-log: transaksi untuk konsistensi, Streams untuk reaksi, TTL untuk kedaluwarsa, mode kapasitas yang tepat untuk biaya, global tables untuk ketahanan region, dan PITR untuk pemulihan data. Kunjungi kembali ikhtisar Operations & Cost untuk melihat bagaimana mereka bersatu.

Unduh DynoTable untuk terhubung ke tabel yang dipulihkan dan memverifikasi pemulihan Anda sebelum Anda memercayainya.