Pasangan mongodump dan mongorestore adalah cara backup MongoDB yang paling sering dipakai — sekaligus paling sering dipakai di tempat yang salah. Keduanya melakukan backup logical: membaca document lewat protokol database lalu menuliskannya sebagai berkas BSON, bukan menyalin berkas data mentah. Chapter ini membedah bentuk perintah lengkapnya, struktur direktori hasil dump, opsi restore yang paling penting, dan batas kapan pasangan ini layak dipilih untuk produksi.
Peta materi Chapter ini:
- Sintaks
mongodumpdanmongorestorebeserta opsi inti:--uri,--db,--collection,--out,--archive,--gzip,--oplog,--drop,--nsFrom/--nsTo. - Struktur direktori hasil dump dan arti setiap berkas.
- Simulasi siklus restore dan verifikasi hasilnya lewat mongosh.
Sintaks dan Opsi Dump #
Bentuk umumnya satu pola: mongodump <options> <connection-string>. Pastikan Database Tools terpasang dulu (mongodb-database-tools lewat apt, brew, atau MSI dari Download Center), lalu periksa dengan mongodump --version. Contoh-contoh berikut memakai server lokal kita:
# dump seluruh instance ke direktori (nama default: ./dump)
mongodump --uri="mongodb://127.0.0.1:27017/?directConnection=true" --out=dump_latihan
# dump hanya satu database, atau satu collection saja
mongodump --uri="mongodb://127.0.0.1:27017/?directConnection=true" \
--db=latihan_backup --collection=buku --out=dump_latihan
# dump satu file archive terkompresi (praktis untuk ditransfer)
mongodump --uri="mongodb://127.0.0.1:27017/?directConnection=true" \
--archive=latihan_backup.archive --gzipTiga perintah di atas menghasilkan dua format keluaran yang berbeda. Opsi --out menulis direktori berisi berkas BSON per collection, sedangkan --archive membungkus semuanya menjadi satu berkas — keduanya tidak boleh dipakai bersamaan. Opsi --gzip mengompresi hasilnya (berkas berakhiran .bson.gz dan .metadata.json.gz, atau archive terkompresi).
Untuk replica set, ada opsi ketiga yang penting: --oplog. Selama dump berjalan, tulisan baru bisa masuk dan membuat hasil dump mencerminkan dua momen yang berbeda. Dengan --oplog, mongodump merekam operasi yang terjadi selama proses dump ke berkas oplog.bson, sehingga hasilnya konsisten pada satu titik waktu ketika dipasangkan dengan mongorestore --oplogReplay:
# dump konsisten point-in-time — HANYA untuk full dump replica set
mongodump --uri="mongodb://127.0.0.1:27017/?directConnection=true" \
--out=dump_konsisten --oplogAda tiga syarat yang ketat: dump harus mencakup seluruh anggota replica set (bukan potongan --db/--collection/--query), target harus node yang punya oplog, dan selama dump tidak boleh ada renameCollection atau agregasi $out. Karena itu --oplog tidak bisa dicampur dengan contoh --db=latihan_backup di atas.
Struktur Hasil Dump #
Direktori hasil dump punya pola yang stabil — satu subdirektori per database, satu berkas BSON per collection, plus berkas metadata:
dump_latihan/
├── latihan_backup/
│ ├── buku.bson
│ ├── buku.metadata.json
│ ├── penjualan.bson
│ └── penjualan.metadata.json
└── oplog.bson # hanya ada bila dump memakai --oplogBerkas .bson berisi document apa adanya dalam format biner BSON — tipe data, panjang string, sampai ObjectId tersimpan utuh, tidak seperti JSON biasa. Berkas .metadata.json menyimpan definisi index dan opsi collection (misalnya validator); inilah alasan mongorestore bisa membangun ulang index secara otomatis. View tidak punya berkas .bson, hanya metadata.
Siklus penuhnya ringkas:
Satu arah panah untuk backup, arah sebaliknya untuk restore — dan keduanya bisa menargetkan deployment yang berbeda versi maupun arsitektur, karena sifatnya logical.
Restore dan Verifikasi Hasilnya #
mongorestore membaca hasil dump dan memasukkannya kembali. Opsi yang paling sering kita butuhkan:
| Opsi | Perilaku |
|---|---|
--drop | Menghapus collection target sebelum memasukkan data dari dump |
--nsFrom / --nsTo | Mengganti namespace saat restore, misal ke database lain |
--nsInclude | Menyaring collection mana yang direstore |
--oplogReplay | Memutar ulang oplog.bson setelah data utama masuk |
--gzip, --archive | Membaca dump terkompresi / satu-berkas |
--dryRun | Menjalankan tanpa benar-benar menulis data — uji kelengkapan |
Contoh restore ke namespace baru dengan pembersihan awal:
# restore ke namespace baru, dengan pembersihan collection target dulu
mongorestore --uri="mongodb://127.0.0.1:27017/?directConnection=true" \
--nsFrom="latihan_backup.*" --nsTo="latihan_staging.*" --drop dump_latihanPola --nsFrom/--nsTo memakai wildcard: tanda * pada sumber berpasangan linear dengan * pada target. Perilaku --drop perlu digarisbawahi — collection yang ada di dump dibuang dulu di target, sehingga isinya persis hasil dump; collection yang tidak ada di dump dibiarkan.
Mari kita buktikan dua perilaku tersebut lewat simulasi di mongosh. Pertama, siapkan “isi dump” — tiga document buku pada latihan_backup:
use latihan_backup
db.dropDatabase()
db.buku.insertMany([
{ _id: 1, judul: "Laut Bercerita", harga: 98000, stok: 12 },
{ _id: 2, judul: "Bumi", harga: 89000, stok: 20 },
{ _id: 3, judul: "Atomic Habits", harga: 115000, stok: 8 }
])
db.buku.find({}, { _id: 1, judul: 1, stok: 1 })Output yang Dihasilkan:
switched to db latihan_backup
{ ok: 1, dropped: 'latihan_backup' }
{ acknowledged: true, insertedIds: { '0': 1, '1': 2, '2': 3 } }
[
{ _id: 1, judul: 'Laut Bercerita', stok: 12 },
{ _id: 2, judul: 'Bumi', stok: 20 },
{ _id: 3, judul: 'Atomic Habits', stok: 8 }
]Sekarang simulasikan restore tanpa --drop: database target sudah berisi satu document lama (_id: 1, stok salah), lalu isi dump tiba. Kita pakai insertMany sebagai pengganti mongorestore — document _id: 1 bentrok:
use latihan_backup_pulih
db.dropDatabase()
db.buku.insertOne({ _id: 1, judul: "Laut Bercerita", harga: 98000, stok: 999 })
db.buku.insertMany([
{ _id: 1, judul: "Laut Bercerita", harga: 98000, stok: 12 },
{ _id: 2, judul: "Bumi", harga: 89000, stok: 20 },
{ _id: 3, judul: "Atomic Habits", harga: 115000, stok: 8 }
])Output yang Dihasilkan:
switched to db latihan_backup_pulih
{ ok: 1, dropped: 'latihan_backup_pulih' }
{ acknowledged: true, insertedId: 1 }
Uncaught:
MongoBulkWriteError: E11000 duplicate key error collection: latihan_backup_pulih.buku index: _id_ dup key: { _id: 1 }
Result: BulkWriteResult {
insertedCount: 0,
...
}
Write Errors: [
WriteError {
err: {
index: 0,
code: 11000,
errmsg: 'E11000 duplicate key error collection: latihan_backup_pulih.buku index: _id_ dup key: { _id: 1 }',
...
}
}
]Rincian BulkWriteResult dipadatkan — poin pentingnya satu baris: galat E11000 pada _id: 1 karena document dengan kunci itu sudah ada lebih dulu. Inilah konflik yang sama dihadapi mongorestore — bedanya, mongorestore mencatat galat lalu melanjutkan document berikutnya, sementara insertMany berhenti. Ulangi sekarang dengan pola --drop: buang collection-nya dulu, baru masukkan isi dump, lalu verifikasi:
db.buku.drop()
db.buku.insertMany([
{ _id: 1, judul: "Laut Bercerita", harga: 98000, stok: 12 },
{ _id: 2, judul: "Bumi", harga: 89000, stok: 20 },
{ _id: 3, judul: "Atomic Habits", harga: 115000, stok: 8 }
])
db.buku.find({ _id: 1 })
db.buku.countDocuments({})
db.buku.aggregate([{ $group: { _id: null, totalStok: { $sum: "$stok" } } }])Output yang Dihasilkan:
true
{ acknowledged: true, insertedIds: { '0': 1, '1': 2, '2': 3 } }
[ { _id: 1, judul: 'Laut Bercerita', harga: 98000, stok: 12 } ]
3
[ { _id: null, totalStok: 40 } ]Stok kembali ke 12 — data lama yang salah tertimpa isi dump, dan tiga lapis verifikasi lolos: jumlah document (3), query sampel (find), dan agregat ringkas (totalStok: 40). Prosedur tiga lapis inilah yang wajib dijalankan setelah setiap restore sungguhan, bukan hanya sekadar memastikan perintah selesai tanpa galat.
Kapan Mongodump Cocok dan Tidak #
Dokumentasi resmi menyebut pasangan ini sebagai tool untuk small MongoDB deployments — dan itu bukan basa-basi:
| Kondisi | Kelayakan | Alasan |
|---|---|---|
| Database dev / staging (< beberapa GB) | Cocok | Cepat cukup, hasil kecil, portabel lintas versi |
| Migrasi antar-edisi atau ke Atlas | Cocok | Sifat logical tidak peduli storage engine maupun arsitektur |
| Menyalin satu collection ke lingkungan lain | Cocok | --db + --collection ringkas |
| Produksi besar (puluhan GB ke atas) | Kurang cocok | Dump dan restore berjalan lama, membebani CPU dan I/O sumber |
| Kebutuhan RPO kecil | Kurang cocok | Dump berkala tetap meninggalkan celah antar-jadwal |
| Collection ber-Queryable Encryption | Tidak bisa | mongodump tidak mendukungnya |
Untuk produksi besar, filesystem snapshot atau layanan backup terkelola mengambil alih — keduanya dibahas di chapter berikutnya. Yang tak tergantikan dari mongodump adalah fleksibilitasnya: hasil dump bisa dibuka di versi MongoDB mana pun, dipindah ke cloud, atau diarsipkan bertahun-tahun tanpa bergantung pada konfigurasi hardware asal.
Rangkuman #
mongodumpmenulis backup logical: direktori.bsonper collection plus.metadata.jsonberisi definisi index, atau satu berkas--archive(boleh--gzip).--oplogmenjadikan dump replica set konsisten pada satu titik waktu — syaratnya full dump tanpa filter--db/--collection, lalu dipasangkanmongorestore --oplogReplay.--dropmembuang collection target sebelum restore; tanpa opsi ini, document dengan_idsama dilewati dan hasilnya campuran data lama-baru.--nsFrom/--nsTomemindahkan namespace saat restore; verifikasi hasil dengan jumlah document, query sampel, dan agregat ringkas.- Cocok untuk dev, staging, dan migrasi; kurang cocok untuk produksi besar atau RPO kecil.