Strategi Backup

Disk yang rusak, migrasi schema yang salah sasaran, atau satu dropDatabase yang diketik pada database produksi — ketiganya hanya punya satu penawar: backup yang siap dipulihkan. Tetapi “punya backup” bukan satu keputusan tunggal; kita harus memutuskan seberapa sering backup diambil, seberapa cepat data bisa kembali, dan seberapa besar biaya penyimpanan yang sanggup ditanggung. Chapter ini membangun kerangka berpikirnya — RPO, RTO, jenis backup, dan kaitannya dengan arsitektur deployment — sebelum kita menyentuh tool konkret di chapter-chapter berikutnya.

Peta materi Chapter ini:

• Definisi RPO (Recovery Point Objective) dan RTO (Recovery Time Objective).
• Mengukur ukuran data dengan db.stats() sebagai titik awal setiap keputusan.
• Empat jenis backup: logical dump, filesystem snapshot, incremental oplog, continuous backup.
• Perbedaan kebutuhan backup untuk standalone, replica set, dan sharded cluster.

RPO dan RTO Dua Angka Penentu #

RPO (Recovery Point Objective) menjawab: berapa banyak data yang boleh hilang saat insiden terjadi? Jawabannya berupa jarak waktu sejak backup terakhir — backup tengah malam pada server yang menerima tulisan setiap detik berarti RPO hingga 24 jam. RTO (Recovery Time Objective) menjawab pertanyaan kedua: berapa lama layanan boleh mati sampai data kembali tersedia? Keduanya adalah keputusan bisnis, bukan keputusan teknis; tugas kita adalah menerjemahkannya menjadi strategi backup yang paling murah namun tetap memenuhi kedua angka tersebut.

Semakin kecil RPO dan RTO, semakin mahal harganya — mulai dari storage cadangan, lisensi layanan, sampai latensi tulisan yang ikut terbebani. Menetapkan RPO 5 menit untuk blog pribadi sama salahnya dengan menetapkan RPO 24 jam untuk aplikasi pembayaran.

Mulai dari Ukuran Data #

Ukuran data adalah faktor pertama yang menentukan metode backup. Database 500 MB bisa di-dump penuh dalam hitungan menit; database 500 GB akan memakan berjam-jam jika dibaca document demi document, tetapi hanya beberapa menit bila cukup menyalin blok disk. Mari siapkan data latihan toko buku dan lihat metriknya:

use latihan_backup
db.dropDatabase()
db.buku.insertMany([
  { _id: 1, judul: "Laut Bercerita", harga: 98000, stok: 12, penulis: "Leila S. Chudori" },
  { _id: 2, judul: "Bumi", harga: 89000, stok: 20, penulis: "Tere Liye" },
  { _id: 3, judul: "Atomic Habits", harga: 115000, stok: 8, penulis: "James Clear" }
])
db.penjualan.insertMany([
  { _id: 101, bukuId: 1, jumlah: 1, tanggal: ISODate("2026-03-02T09:15:00Z") },
  { _id: 102, bukuId: 2, jumlah: 2, tanggal: ISODate("2026-03-03T10:05:00Z") }
])
db.stats()

Output yang Dihasilkan:

switched to db latihan_backup
{ ok: 1, dropped: 'latihan_backup' }
{ acknowledged: true, insertedIds: { '0': 1, '1': 2, '2': 3 } }
{ acknowledged: true, insertedIds: { '0': 101, '1': 102 } }
{
  db: 'latihan_backup',
  collections: Long('2'),
  views: Long('0'),
  objects: Long('5'),
  avgObjSize: 72,
  dataSize: 360,
  storageSize: 8192,
  indexes: Long('2'),
  indexSize: 8192,
  totalSize: 16384,
  scaleFactor: Long('1'),
  fsUsedSize: 2654208000,
  fsTotalSize: 10531131392,
  ok: 1
}

Respons di atas dipadatkan dari metadata waktu replikasi ($clusterTime, operationTime) seperti biasa. Tiga angka di respons db.stats() paling relevan untuk perencanaan backup:

• dataSize — ukuran logis seluruh document tanpa kompresi; ini perkiraan kasar ukuran hasil mongodump.
• storageSize — ukuran fisik di disk setelah kompresi WiredTiger; ini perkiraan ukuran filesystem snapshot.
• totalSize — storageSize plus indexSize; snapshot ikut menyalin index, sedangkan mongodump tidak (index dibangun ulang saat restore).

Database latihan kita hanya 16 KB, sehingga semua metode backup sama-sama cepat. Pada ukuran ratusan gigabyte, perbedaan “menyalin blok disk” versus “membaca dan menulis ulang setiap document” menjadi pemisah antara RTO beberapa menit dan berjam-jam.

Empat Jenis Backup #

Jenis-jenis ini tidak saling meniadakan melainkan bersusun: snapshot penuh sebagai fondasi, oplog sebagai tambalan untuk mengecilkan RPO. Kombinasi snapshot + replay oplog sampai titik waktu tertentu juga adalah mekanisme di balik point-in-time recovery yang kita bahas di chapter khusus.

Kaitan dengan Arsitektur Deployment #

Arsitektur menentukan opsi yang tersedia. Oplog — sumber data untuk RPO kecil — hanya ada pada replica set dan sharded cluster, bukan standalone:

Dokumentasi resmi MongoDB merangkum perbandingannya: untuk RTO, snapshot dan layanan terkelola tergolong rendah (cepat pulih) sedangkan dump tinggi; untuk RPO, hanya continuous backup yang rendah. Pada sharded cluster, kompleksitas snapshot dan dump naik drastis — di titik ini layanan seperti Atlas Backup biasanya lebih hemat tenaga daripada merakit sendiri.

Rangkuman #

• RPO = batas data yang boleh hilang; RTO = batas waktu layanan boleh mati. Keduanya keputusan bisnis yang diterjemahkan menjadi strategi teknis.
• db.stats() memberi dataSize (perkiraan ukuran dump), storageSize, dan totalSize (perkiraan ukuran snapshot) — angka awal sebelum memilih metode.
• Empat jenis backup menumpuk: dump untuk data kecil, snapshot untuk produksi besar, oplog incremental untuk mengecilkan RPO, continuous backup untuk RPO mendekati nol.
• Standalone tidak punya oplog; replica set memberi opsi paling seimbang; sharded cluster paling rumit dan sering paling cocok ditangani layanan terkelola.