Pada deployment self-managed, backup adalah proyek infrastruktur tersendiri: menyiapkan volume snapshot, menjadwalkan dump, mengelola retensi, dan menguji restore. MongoDB Atlas memindahkan hampir seluruh pekerjaan operasional itu ke sisi layanan — tetapi satu tanggung jawab tetap milik kita: menetapkan kebijakan. Jadwal seberapa sering, retensi berapa lama, dan kapan restore dijalankan adalah keputusan yang tidak bisa didelegasikan. Chapter ini memetakan cara Atlas menyimpan backup, kebijakan defaultnya, dan mekanisme point-in-time restore — semua disajikan sebagai naratif tanpa keluaran rekayasa, mengikuti dokumentasi Atlas resmi.
Peta materi Chapter ini:
- Cloud backup: snapshot native penyedia cloud, tersimpan berdampingan dengan cluster.
- Kebijakan jadwal dan retensi default beserta snapshot sesuai permintaan.
- Continuous Cloud Backup dan prosedur point-in-time restore.
- Lapisan tambahan: Multi-Region Snapshot Distribution, Backup Compliance Policy, dan ekspor ke bucket sendiri.
Snapshot Cloud yang Berdampingan dengan Cluster #
Atlas Cloud Backup tersedia untuk cluster dedicated M10+ di AWS, Azure, maupun Google Cloud, dan dapat diaktifkan saat pembuatan cluster atau kemudian lewat halaman konfigurasi. Alih-alih menyalin data ke sistem file terpisah, Atlas memakai teknologi snapshot native penyedia cloud tempat cluster berjalan — dan menyimpan hasilnya di region yang sama dengan cluster. Pendekatan co-located ini punya dua konsekuensi yang perlu kita pahami:
| Aspek | Perilaku |
|---|---|
| Lokasi penyimpanan | Region yang sama dengan cluster (atau region prioritas tertinggi pada cluster multi-region) |
| Redundansi | Mewarisi redundansi native penyimpanan penyedia cloud — misalnya AWS menyimpan objek di minimal tiga Availability Zone |
| Kecepatan restore | Tinggi, karena data tidak menempuh perjalanan lintas region |
| Titik lemah | Kegagalan satu region ikut menjangkau snapshot di region itu |
Pada cluster sharded, Atlas membuat backup terpisah untuk setiap shard di region utama shard tersebut — konsistensi antar-shard tetap dikoordinasikan oleh layanan. Untuk cluster yang menerima beban tulisan, Atlas mengutamakan snapshot dari node secondary sehingga primary tidak ikut terbebani.
Jadwal dan Retensi #
Kebijakan backup diatur lewat Backup Policy Editor, yang memuat baris-baris policy item — masing-masing menentukan frekuensi dan masa retensi. Kebijakan default Atlas mengambil snapshot pada pukul 18:00 UTC dengan komposisi berikut:
| Policy item | Jadwal | Retensi |
|---|---|---|
| Hourly | Setiap 6 jam (12 jam pada penyimpanan NVMe) | 7 hari |
| Daily | Setiap hari | 7 hari |
| Weekly | Setiap Sabtu | 4 minggu |
| Monthly | Akhir bulan | 12 bulan |
| Yearly | Setiap 1 Desember | 1 tahun |
Dua hal praktis mengikuti tabel ini. Pertama, restore window untuk continuous backup tidak boleh melebihi retensi snapshot hourly — memperpanjang jendela PIT berarti ikut memperpanjang retensi hourly. Kedua, di luar jadwal, kita bisa mengambil on-demand snapshot kapan saja dan menetapkan retensinya sendiri. Antarmuka Atlas menampilkan estimasi jumlah snapshot (dan biayanya) sebelum perubahan kebijakan disimpan, sehingga dampak storage cost terlihat lebih dulu.
Continuous Backup dan Point-in-Time Restore #
Snapshot berkala selalu meninggalkan celah RPO selebar jarak antar-jadwal. Untuk menutupnya, Atlas menyediakan Continuous Cloud Backup: oplog cluster di-streaming terus-menerus ke object storage penyedia cloud (S3 untuk AWS, Blob Storage untuk Azure, Cloud Storage untuk Google) di region yang sama dengan snapshot. Dengan oplog tersimpan, kita bisa memulihkan cluster ke titik waktu mana pun di dalam jendela restore — bukan hanya ke momen snapshot terakhir.
Alur pemulihannya di antarmuka Atlas berjalan sebagai berikut:
- Buka halaman Backup di project, lalu pilih cluster.
- Klik Point in Time Restore.
- Pilih tab Date & Time (granularitas satu menit) atau Oplog Timestamp (granularitas satu detik), lalu masukkan titik waktu tujuan.
- Pilih project dan cluster target, lalu konfirmasi Restore.
Satu peringatan penting dari dokumentasi: titik waktu yang bisa dituju adalah kapan saja di dalam jendela continuous backup, kecuali rentang antara restore yang sedang berjalan hingga snapshot pertama selepasnya. Untuk cluster-level restore, Atlas menghapus seluruh data lama di cluster target lebih dulu dan cluster tidak tersedia selama proses — berbeda dengan restore level database/collection yang lebih selektif.
Perintah Atlas CLI memberi jalur otomasi untuk proses yang sama (dijalankan dari terminal yang sudah login ke Atlas, bukan dari mongosh):
// mdtest: skip — Atlas CLI, bukan mongosh
// daftar snapshot sebuah cluster:
// atlas backups snapshots list <clusterName>
// mulai restore — automated (snapshot), download, atau pointInTime:
// atlas backups restores start <automated|download|pointInTime> [options]
// pantau satu pekerjaan restore sampai selesai:
// atlas backups restores watch <restoreJobId>
Lapisan Perlindungan Tambahan #
Ketiga mekanisme di atas adalah inti layanannya. Atlas menambahkan beberapa lapisan untuk kebutuhan yang lebih ketat:
| Fitur | Yang dilakukan | Kapan dipakai |
|---|---|---|
| Multi-Region Snapshot Distribution | Menyalin snapshot dan oplog ke region Atlas lain secara otomatis | Melindungi backup dari kegagalan satu region |
| Backup Compliance Policy | Mengunci kebijakan minimum di seluruh project; snapshot tak bisa dihapus oleh siapa pun selama periode proteksi | Kewajiban hukum dan audit (retensi tak bisa diloloskan) |
| Cloud Backup Export | Mengekspor snapshot ke bucket S3, Azure Blob, atau Google Cloud Storage milik sendiri | Memindahkan salinan keluar dari kendali penuh Atlas |
Perhatikan pembagian perannya: distribution melindungi dari kegagalan region, sedangkan export memindahkan kepemilikan data sepenuhnya ke infrastruktur kita. Hak akses pun berlapis — menjalankan dan memantau restore memerlukan peran Project Backup Manager, Project Backup Recovery Operator, atau Project Owner di project terkait.
Rangkuman #
- Atlas Cloud Backup (
M10+) memakai snapshot native penyedia cloud dan menyimpannya di region yang sama dengan cluster — cepat dipulihkan, tetapi rentan terhadap kegagalan region. - Kebijakan default menggabungkan snapshot hourly (6 jam, 7 hari), daily, weekly, monthly, hingga yearly; restore window PIT dibatasi retensi hourly.
- Continuous Cloud Backup men-streaming oplog ke object storage sehingga restore bisa menuju titik waktu mana pun — lewat tab Date & Time (presisi menit) atau Oplog Timestamp (presisi detik).
- Multi-Region Snapshot Distribution, Backup Compliance Policy, dan Cloud Backup Export menutup kebutuhan yang lebih ketat: tahan kegagalan region, patuh hukum, dan lepas dari platform.