DynamoDB Backup & Point-in-Time Recovery

DynamoDB melindungi data Anda dengan dua cara. On-demand backup adalah snapshot penuh yang Anda ambil dan simpan tanpa batas. 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 — keduanya adalah alat pemulihan, bukan tombol undo.

Untuk audit log ini tidak bisa ditawar. Ia adalah catatan kepatuhan yang tak terubah; migrasi buruk yang menulis ulang event, atau penghapusan massal yang tidak sengaja, harus dapat dipulihkan ke momen sebelum kesalahan terjadi.

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 yang dapat dikonfigurasi dari 1 hingga 35 hari. On-demand backup adalah snapshot penuh manual yang disimpan tanpa batas. Keduanya memulihkan ke tabel baru, tidak pernah menimpa yang asli, jadi keduanya adalah alat pemulihan, bukan undo di tempat.

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

Masalahnya: kesalahan yang tidak bisa Anda undo di tempat

DynamoDB tidak punya transaction log yang bisa Anda gulung balik dan tidak ada "undo" pada penulisan. Jika sebuah skrip migrasi menulis ulang field action setiap event, atau seseorang menjalankan penghapusan yang lebih luas dari yang dimaksudkan, tabel hanya berada dalam keadaan yang salah. Tanpa backup, datanya hilang.

Untuk audit log — yang seluruh nilainya adalah menjadi catatan yang dapat dipercaya — "kami tidak bisa mendapatkan kembali event Selasa lalu" adalah kegagalan kepatuhan, bukan sekadar ketidaknyamanan.

Cara kerja backup dan PITR

Point-in-time recovery, setelah diaktifkan, mengambil backup otomatis berkelanjutan. Menurut dokumentasi AWS, PITR "menyediakan backup berkelanjutan yang dikelola sepenuhnya dan otomatis dari data tabel dengan hingga 35 hari titik pemulihan pada granularitas per detik." Jendela ini dapat dikonfigurasi dari 1 hingga 35 hari melalui RecoveryPeriodInDays, dan Anda dapat memulihkan ke detik mana pun di dalamnya — termasuk ke region yang berbeda.

Satu hal penting di tepian: mengurangi periode pemulihan langsung mengurangi titik pemulihan paling awal, dan menonaktifkan lalu mengaktifkan kembali PITR mereset waktu awal yang dapat dipulihkan — Anda kehilangan riwayat berkelanjutan sebelumnya.

On-demand backup terpisah: snapshot tabel penuh yang manual, yang Anda buat secara eksplisit dan simpan tanpa batas, berguna untuk checkpoint pra-migrasi atau arsip kepatuhan jangka panjang di luar jendela PITR 35 hari.

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

Contoh terkerjakan: pulih dari migrasi yang buruk

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

Tabel yang rusak tetap tidak tersentuh saat Anda memverifikasi pemulihan — Anda membandingkan event yang dipulihkan terhadap yang langsung, mengonfirmasi nilai action sudah kembali, lalu mengarahkan ulang aplikasi. Tidak ada yang dihancurkan dalam pemulihan itu sendiri.

Jika kehilangannya berupa segelintir Item alih-alih korupsi seluruh tabel, Anda sebaliknya bisa memeriksa data langsung dan salinan yang dipulihkan lalu menyalin hanya baris yang terdampak — lihat menyalin tabel DynamoDB.

Lakukan di DynoTable

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

DynoTable terhubung ke tabel yang dipulihkan seperti tabel lainnya, jadi Anda dapat men-query event tenant yang terdampak, mengonfirmasi nilai action sudah benar, dan membandingkan terhadap tabel langsung sebelum Anda beralih — mengubah sebuah pemulihan dari lompatan iman menjadi pemulihan terverifikasi.

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

Jebakan dan langkah berikutnya

• Aktifkan PITR sebelum Anda membutuhkannya. Ia hanya melindungi sejak saat ia aktif — tidak ada pemulihan retroaktif. Aktifkan untuk tabel apa pun yang datanya tidak mampu Anda kehilangan.
• Menonaktifkan PITR mereset jendela. Mematikan dan menyalakannya kembali menghapus riwayat berkelanjutan; waktu awal yang dapat dipulihkan dimulai lagi dari pengaktifan ulang.
• Pemulihan tidak instan atau gratis. Sebuah pemulihan menyediakan tabel baru seluruhnya dan memakan waktu proporsional dengan ukuran; anggarkan untuk durasi dan tabel ekstra.
• 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. Tinjau kembali ringkasan Operasi & Biaya untuk melihat bagaimana semuanya cocok bersama.

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