Strategi Backup: Cara Memastikan Datamu Tidak Pernah Hilang

Ada gurauan lama di kalangan orang yang sehari-hari mengurus server: di dunia ini cuma ada dua jenis tim — yang sudah mem-backup datanya, dan yang sebentar lagi mulai. Kelompok kedua biasanya baru gabung setelah hard drive-nya mati, database-nya kehapus tak sengaja, atau sebuah deploy yang buruk melenyapkan sesuatu yang penting. Saat itu yang terjadi bukan pemulihan yang tenang, tapi panik mencari-cari. Inti dari sebuah strategi backup justru memastikan hari buruk seperti itu tetap membosankan.

Dan ini bagian yang sering luput dari pemula: sebuah backup belum bisa disebut backup sampai kamu berhasil memulihkan darinya. Salinan yang tidak pernah kamu uji cuma sekadar harapan. Artikel ini membahas seperti apa strategi backup yang sungguhan — bukan satu baris perintah, melainkan sekumpulan kebiasaan yang, kalau digabung, membuatmu bisa menghadapi hari terburuk dengan santai lalu kembali bekerja.

Backup itu sebenarnya apa

Backup adalah salinan terpisah dari datamu, disimpan di tempat lain, yang bisa kamu pakai untuk mengembalikan keadaan kalau yang asli hilang atau rusak. Sudah, itu saja. Kata “terpisah” dan “di tempat lain” itulah yang menanggung seluruh beban kalimat tadi — salinan yang menumpang di disk yang sama dengan aslinya bukan backup, itu cuma cara kedua untuk kehilangan semuanya sekaligus.

Data bisa raib lewat lebih banyak jalan daripada yang orang kira:

Perangkat keras rusak. Disk bisa mati. Mati tanpa peringatan, dan lebih sering daripada yang kamu mau.
Manusia melakukan kesalahan. Ada yang menjalankan perintah yang salah, menghapus folder yang salah, atau men-drop tabel database yang salah. Ini sejauh ini penyebab paling umum.
Software merusak sesuatu. Migrasi yang bermasalah, deploy yang buruk, atau penulisan yang korup bisa diam-diam mengacak data.
Pihak jahat menyerang. Ransomware mengenkripsi berkasmu lalu menuntut tebusan. Backup yang bersih itulah yang membuatmu bisa berkata tidak.
Seluruh lokasi tumbang. Kebakaran, banjir, dan gangguan data center memang terjadi. Jarang, tapi nyata.

Strategi backup yang baik dirancang supaya tidak satu pun dari kejadian-kejadian ini bisa menghabisimu sendirian. Itulah sasaran yang kamu tuju.

Backup vs redundansi — keduanya tidak sama

RAID, replika, dan disk yang di-mirror memberimu redundansi: kalau satu disk mati, yang lain tetap melayani. Itu bagus untuk uptime, tapi itu bukan backup. Kalau seseorang menghapus sebuah berkas, penghapusannya langsung tersalin ke setiap mirror seketika. Redundansi melindungi dari kerusakan perangkat keras; backup melindungi dari kesalahan, korupsi data, dan serangan. Kamu butuh keduanya, dan jangan pernah mengira yang satu bisa menggantikan yang lain.

Aturan 3-2-1

Kalau dari seluruh artikel ini kamu cuma mau mengingat satu hal, jadikan ini. Aturan 3-2-1 adalah bentuk klasik yang sudah teruji untuk setup backup yang waras:

3 salinan datamu (yang asli ditambah dua backup).
2 jenis media penyimpanan yang berbeda (supaya satu jenis kerusakan tidak bisa menjatuhkan semua salinan).
1 salinan disimpan di luar lokasi (di tempat yang secara fisik jauh dari aslinya).

Logikanya sederhana. Tiga salinan berarti satu kerusakan masih menyisakan dua. Dua jenis media berarti cacat yang mengenai satu jenis — sebatch disk yang jelek, bug di sistem penyimpanan — tidak menghantam semuanya. Dan salinan di luar lokasi adalah asuransimu terhadap bencana yang melenyapkan seluruh gedung: kebakaran, banjir, atau server yang dicuri.

   3-2-1 dalam satu gambar

   [ ASLI ]   ← data hidup di server-mu
       │
       ├──► [ SALINAN 1 ]   lokal, cepat untuk dipulihkan
       │      (mis. disk eksternal atau server kedua di dekatnya)
       │
       └──► [ SALINAN 2 ]   di luar lokasi, jauh
              (mis. cloud storage di region lain)

   3 salinan · 2 jenis media · 1 di luar lokasi

Kamu bakal menemui variasi modern seperti 3-2-1-1-0 (tambah satu salinan offline/air-gapped dan nol kesalahan saat uji pemulihan), tapi 3-2-1 adalah fondasinya. Benerin dulu yang ini dan kamu sudah lebih maju daripada kebanyakan setup di luar sana.

Full, incremental, dan differential

Kalau kamu mem-backup data yang sama setiap hari, menyalin semuanya tiap kali itu lambat dan boros. Maka ada cara-cara yang lebih cerdas. Ada tiga pola yang perlu kamu kenal, dan masing-masing menukar kecepatan dengan kesederhanaan.

Backup full — salinan lengkap dari segala sesuatu, setiap kali. Sederhana dan gampang dipulihkan (semuanya ada di satu tempat), tapi lambat dibuat dan berat di penyimpanan. Kamu jarang menjalankan backup full setiap hari pada dataset yang besar.

Backup incremental — setelah satu backup full, tiap putaran cuma menyalin apa yang berubah sejak backup terakhir (full maupun incremental). Ukurannya kecil dan cepat. Kekurangannya: untuk memulihkan, kamu butuh backup full plus setiap increment secara berurutan. Satu mata rantai hilang, pemulihannya jadi bermasalah.

Backup differential — setelah satu backup full, tiap putaran menyalin semua yang berubah sejak backup full terakhir. Ukurannya membesar sedikit tiap hari, tapi memulihkannya cuma butuh dua bagian: backup full ditambah differential paling baru. Jalan tengah yang enak.

   Sen (FULL) ──────────────────────────────►  semuanya

   INCREMENTAL:                                 tiap = perubahan sejak
   Sel [Δ dari Sen]  Rab [Δ dari Sel]  ...       backup SEBELUMNYA
   pulihkan = FULL + Sel + Rab + ... (seluruh rantai)

   DIFFERENTIAL:                                tiap = perubahan sejak
   Sel [Δ dari Sen]  Rab [Δ dari Sen]  ...       FULL terakhir
   pulihkan = FULL + yang paling baru (cukup dua)

Pola yang sangat umum di dunia nyata: backup full mingguan, incremental harian, lalu kamu menyimpan cukup banyak supaya bisa balik ke hari mana pun dalam seminggu. Cara ini menjaga backup harian tetap cepat sambil tetap membuatmu bisa memulihkan ke titik waktu yang persis.

Snapshot adalah ide kerabat yang berguna

Banyak sistem menawarkan snapshot — tampilan beku dari sebuah disk atau database pada satu momen, yang dibuat nyaris seketika. Snapshot luar biasa untuk rollback cepat (membatalkan perubahan buruk dalam hitungan detik) dan untuk mem-backup database dengan aman tanpa menghentikannya. Tapi snapshot biasanya berada di penyimpanan yang sama dengan aslinya, jadi kalau berdiri sendiri ia gagal di syarat “di tempat lain”. Pakai snapshot untuk kecepatan dan kepraktisan, lalu kirim salinannya keluar dari mesin itu supaya jadi backup sungguhan.

Di mana menyimpan backup-mu

Sebuah salinan hanya seaman tempat kamu menaruhnya. Sebarkan salinanmu ke beberapa jenis lokasi supaya tidak ada satu masalah pun yang bisa menjangkau semuanya:

Disk lokal atau mesin di dekatnya — cepat ditulis dan cepat dipulihkan. Cocok untuk salinan pertamamu dan pemulihan sehari-hari. Tidak berguna kalau gedungnya terbakar, dan justru itulah alasan kenapa ini tidak boleh jadi salinan satu-satunya.
Di luar lokasi / cloud object storage — salinan di lokasi fisik berbeda, sering kali di region yang sama sekali lain. Inilah yang bertahan saat bencana menimpa markas utama. Pemulihannya lebih lambat lewat jaringan, tapi keamanan itulah seluruh tujuannya.
Offline / air-gapped — salinan yang sebagian besar waktu tidak tersambung ke apa pun (disk di laci, atau media write-once). Ransomware tidak bisa mengenkripsi apa yang tidak bisa ia jangkau. Inilah salinan yang menyelamatkanmu di serangan paling parah.

Setup sederhana tapi kuat untuk proyek kecil: simpan satu salinan terbaru secara lokal untuk pemulihan cepat, dorong satu salinan ke penyimpanan di luar lokasi di region lain, dan kamu sudah memenuhi 3-2-1 tanpa banyak repot.

Jadwal, retensi, dan penamaan

Strategi backup bukan cuma soal di mana — tapi juga kapan, berapa lama, dan bagaimana kamu menemukan yang tepat nanti.

Jadwal. Backup-lah lewat timer otomatis yang teratur — jangan pernah secara manual, karena tangan manusia lupa. Seberapa sering tergantung berapa banyak data yang sanggup kamu relakan hilang. Toleransi itu punya nama: Recovery Point Objective (RPO). Kalau RPO-mu “satu jam”, kamu mem-backup setidaknya tiap jam. Kalau kehilangan pekerjaan seharian masih oke, harian sudah cukup. Ada juga saudaranya — Recovery Time Objective (RTO) — yaitu berapa lama sebuah pemulihan boleh memakan waktu. Keduanya ikut membentuk rancanganmu.

Retensi. Kamu tidak menyimpan setiap backup selamanya; bisa tenggelam dalam penyimpanan. Skema yang umum dan masuk akal menyimpan backup pada interval yang makin menipis — kadang disebut grandfather-father-son:

   Simpan:  7  backup harian terakhir
            4  backup mingguan terakhir
            12 backup bulanan terakhir
            beberapa backup tahunan

   → pemulihan rinci untuk hari-hari terakhir,
     riwayat kasar sampai bertahun-tahun ke belakang,
     tanpa menyimpan ribuan salinan.

Ini lebih penting daripada kelihatannya. Kalau sebuah masalah mulai diam-diam dua minggu lalu dan kamu cuma menyimpan backup tiga hari, semua salinan yang kamu punya sudah ikut korup. Retensi yang lebih panjang memberimu kemampuan menjangkau ke belakang sebelum kerusakan itu dimulai.

Penamaan. Beri backup nama bertanggal yang konsisten supaya kamu bisa menemukan yang tepat saat sedang tertekan — app-db-2026-11-01T0200.sql.gz langsung memberitahumu persis itu apa dan dibuat kapan. Dirimu di masa depan, pukul 3 dini hari saat insiden, bakal berterima kasih.

Uji pemulihanmu, atau kamu sebenarnya tidak punya backup

Inilah aturan yang paling sering diabaikan dari seluruh urusan backup, dan yang paling pedih gigitannya. Sebuah job backup yang “berhasil” tiap malam tetap bisa memproduksi berkas yang tidak berguna — path-nya salah, database-nya kosong, arsipnya korup, kredensialnya hilang. Kamu tidak akan tahu sampai hari ketika kamu mati-matian membutuhkannya. Jadwalkan latihan pemulihan secara rutin: benar-benar tarik sebuah backup, pulihkan di tempat yang aman, lalu pastikan datanya utuh. Backup yang tidak pernah kamu pulihkan itu cuma teori, bukan jaring pengaman.

Jangan lupakan bagian lain dari gambaran ini

Gampang sekali terlalu fokus pada database lalu lupa bahwa sebuah sistem yang berfungsi itu lebih dari sekadar datanya. Saat kamu merencanakan apa yang harus di-backup, pikirkan segala hal yang kamu butuhkan untuk membangun ulang dari nol:

Data aplikasi — database, berkas unggahan, konten pengguna. Yang sudah jelas.
Konfigurasi — config server, environment variable, dan secret. Bagian ini gampang terlewat dan menyakitkan untuk disusun ulang. (Lihat konfigurasi environment soal kenapa ini layak dapat perhatian yang sama dengan datamu.)
Kode — biasanya sudah aman di version control, tapi pastikan itu benar-benar fakta, bukan sekadar asumsi.
Petunjuk pemulihannya sendiri — sebuah runbook tertulis singkat soal cara memulihkan, disimpan di tempat yang bisa kamu jangkau bahkan kalau sistem utamamu sedang mati. Tengah-tengah gangguan adalah waktu terburuk untuk membongkar-bongkar setup-mu sendiri.

Backup adalah satu bagian dari menjalankan sebuah layanan dengan baik. Dia berdampingan dengan memahami environment deployment-mu dan mengerti apa sebenarnya deployment itu — bersama-sama, itulah yang memisahkan layanan yang bertahan di hari buruk dari yang tidak.

Rencana sederhana yang benar-benar bisa kamu jalankan

Kamu tidak butuh brankas kelas enterprise untuk jadi aman. Ini strategi awal yang sungguh kokoh untuk proyek atau bisnis kecil:

   1. Backup full database + unggahan, otomatis, tiap malam.
   2. Incremental sepanjang hari kalau kehilangan satu hari penuh itu menyakitkan.
   3. Satu salinan disimpan lokal (pemulihan cepat).
   4. Satu salinan didorong ke luar lokasi di region lain (perlindungan bencana).
   5. Retensi: 7 harian, 4 mingguan, beberapa bulanan.
   6. Pulihkan satu backup ke environment uji tiap bulan, lalu verifikasi.

Sudah, itu saja. Tidak mewah, dan justru itu intinya — rutinitas yang membosankan, otomatis, dan teruji mengalahkan rutinitas pintar yang tidak pernah kamu cek.

Penutup

Ini rangkuman semuanya dalam satu tempat:

Backup adalah salinan terpisah dari datamu, disimpan di tempat lain, yang bisa kamu pulihkan. Salinan di disk yang sama tidak dihitung.
Redundansi (RAID, replika) melindungi uptime; backup melindungi dari kesalahan, korupsi, dan serangan. Kamu butuh keduanya — keduanya tidak sama.
Aturan 3-2-1 adalah fondasinya: 3 salinan, 2 jenis media, 1 di luar lokasi.
Full / incremental / differential menukar kecepatan dengan kerumitan pemulihan; full mingguan + incremental harian adalah setup umum yang seimbang.
Simpan salinan di tempat-tempat berbeda — lokal, di luar lokasi, dan idealnya satu offline/air-gapped.
Tentukan RPO dan RTO-mu, susun skema retensi yang masuk akal, beri backup nama dengan tanggal, dan otomatiskan semuanya.
Yang terpenting: uji pemulihanmu. Backup yang tidak diuji itu tebakan, bukan jaring pengaman.

Strategi backup yang kokoh sehari-hari diam saja tanpa terasa berguna — sampai satu hari ketika ia menyelamatkan seluruh proyekmu. Hari itulah yang persis menjadi alasan kamu membangunnya.