Backup dan Disaster Recovery buat Solo Developer: Yang Saya Terapkan

Sebagai solo developer yang ngurus beberapa VPS buat proyek sendiri dan proyek client, saya nggak punya tim ops yang siaga 24 jam. Kalau server down jam 2 pagi, yang bangunin cuma alarm monitoring, dan yang benerin cuma saya. Jadi backup dan disaster recovery bukan “nice to have” — itu jaring pengaman satu-satunya yang saya punya.

Backup harus otomatis, titik

Kalau backup-nya masih model “inget-inget sendiri tiap minggu”, cepat atau lambat bakal kelewat — biasanya pas lagi sibuk-sibuknya dengan deadline client, yang justru saat paling riskan buat kehilangan progress. Saya jadwalin cron job yang jalan otomatis tiap malam buat tiap VPS, jadi saya nggak perlu andelin ingatan sendiri buat hal sepenting ini.

Simpan di luar server sumbernya

Backup yang cuma disimpan di VPS yang sama itu nggak ada gunanya kalau VPS-nya mati total atau disk-nya korup — kamu kehilangan data dan backup-nya bareng-bareng. Saya push backup ke object storage terpisah, jadi beneran independen dari server sumbernya. Ini juga kepake pas saya sempet migrasi provider VPS — tinggal restore dari object storage ke server baru, nggak perlu mikirin cara mindahin data dari server lama yang mau saya matiin.

Test restore-nya, jangan cuma percaya backup-nya jalan

Ini bagian yang paling sering dilewatin orang, termasuk saya di awal-awal. Backup yang nggak pernah dites restore itu backup yang cuma “kelihatan aman” — kamu nggak beneran tau file-nya utuh atau prosesnya jalan sampai kamu butuh dan ternyata gagal. Saya sisihin waktu tiap beberapa bulan buat coba restore ke environment baru (VPS murah sekali pakai, bukan production), biar tau prosesnya beneran jalan waktu dibutuhkan, bukan cuma pas kondisi ideal.

Dokumentasikan proses recovery-nya

Waktu panik karena server down itu bukan waktu terbaik buat mikir jernih atau inget urutan command yang bener. Saya simpan langkah-langkah recovery secara tertulis — bukan cuma “restore dari backup”, tapi urutan konkret: command apa, di mana kredensialnya, apa yang harus dicek setelah restore selesai. Jadi saya tinggal ikutin checklist, bukan improvisasi di tengah tekanan sambil jantung berdebar.

Pisahkan backup database dan backup file/config

Keduanya punya frekuensi dan kebutuhan retensi yang beda. Database biasanya berubah tiap menit kalau ada traffic, jadi perlu backup lebih sering — beberapa kali sehari buat project yang aktif. File statis atau config server jarang berubah, jadi backup harian atau bahkan mingguan udah cukup. Nyampur keduanya jadi satu strategi bikin kamu boros storage buat yang jarang berubah, atau kurang sering buat yang sering berubah.

Nggak ada setup yang sempurna anti-gagal — saya masih bisa kena kasus yang nggak saya antisipasi. Tapi dengan lima hal di atas, worst-case scenario saya berubah dari “proyek hilang total, mulai dari nol” jadi “downtime beberapa jam buat restore”. Bedanya jauh banget kalau kamu satu-satunya orang yang bisa benerin.