.gitignore Saya Selama Ini Menyembunyikan Aset Disaster Recovery
Whitelist aset DR di .gitignore bikin saya sadar repo Git bisa jadi salinan pertama strategi backup 3-2-1-1-0 tanpa NAS atau tape.
Ringkasan
Commit kecil soal .gitignore bikin saya sadar file DR penting selama ini ikut ter-ignore, padahal harus masuk repo. Setup backup baru memakai pola 3-2-1-1-0: Git repo dengan bundle plus patch dump index/stash, restic terenkripsi lokal, dan cloud immutable off-site. Motivasinya jelas: ransomware kerap menyerang backup dulu, jadi salinan harus immutable dan restore teruji.
Jam 7 pagi, 2 September 2026. Saya buka file .gitignore di repo my-agent, bukan karena ada bug atau deploy gagal, tapi karena saya baru sadar pola ignore yang saya tulis berbulan-bulan lalu ternyata ikut membuang file-file yang seharusnya masuk backup.
Komennya cuma: whitelist DR assets in gitignore. Kecil banget kan.
Yang saya pikir cuma chore
Saya pikir commit ini cuma cleanup ignore-list. Dr-scripts, skill definitions, config templates, arsip riset: selama ini nggak masuk repo kalo emang di-ignore. Kan saya pikir, "file lokal aja, nggak penting banget buat version control."
Tapi malam sebelumnya saya lagi bikin setup backup baru. Backup lama kantor (NAS plus disk eksternal) nggak mau saya teruskan. Pola baru: repo Git jadi salinan pertama, restic snapshot jadi salinan kedua, cloud immutable off-site jadi salinan ketiga. Pola 3-2-1. Kebiasaan bikin infra yang tahan di-recreate pernah saya tulis juga di sudo yang bertahan setiap container di-recreate.
Dan baru di titik itu saya sadar: file-file yang saya ignore justru aset yang harus ikut pulih kalo terjadi apa-apa.
Git bundle, batasan yang saya nggak tahu
Masalahnya bukan cuma soal ignore-list. Saya mau bikin satu file backup dari repo Git, satu file utuh yang gampang dikirim atau simpan di tempat beda. Git punya fitur untuk ini: bundle. Perintahnya git bundle create backup.bundle --all, dan hasilnya satu file yang bisa di-clone atau pull balik nanti.
Tapi ada yang Git nggak simpan di bundle: index, working tree, stash, config, hooks [4]. Artinya kalo cuma bundle, saya kehilangan state kerja sehari-hari. Patch sederhana yang saya tulis (fungsi untuk dump index dan stash ke file terpisah sebelum bundle) jadi bagian dari proses. Nggak elegan, tapi fungsional.
Dan ternyata soal ignore juga beda dari yang saya kira. .gitignore cuma mengontrol file untracked. Kalo file udah tracked, pattern di .gitignore nggak bikin dia hilang dari repo [5]. Jadi whitelist pakai pola !/ itu bukan cuma "un-ignore", tapi deklarasi eksplisit bahwa file-file ini harus ada di repo.
Yang masuk whitelist: patch scripts untuk recovery, skill definitions, config yang perlu buat rebuild environment, bundle definitions untuk cron jobs, dan arsip riset. Intinya semua yang bikin saya bisa balik kerja dari nol kalo laptop atau server mati total.
Ransomware menarget backup duluan
Kenapa saya repot-repot mikirin DR recovery? Karena ransomware sekarang nggak cuma enkripsi data di mesin kerja.
Laporan DBIR 2025 Verizon yang dikutip CISA nyatet ransomware nyangkut di 44% breach yang mereka investigasi [1]. Di blog Veeam Data Cloud Vault angkanya lebih ekstrem lagi: 93% serangan nargetin backup secara eksplisit buat menggagalkan recovery yang bersih [6]. Jadi kalo backup cuma ada satu salinan, atau cuma di satu tempat, attacker udah tahu cara bikin kamu nggak punya pilihan selain bayar.
Ini yang bikin saya nggak cuma butuh backup, tapi backup yang nggak bisa dihapus atau diubah: cloud immutable. Dan ini juga kenapa evolusi dari 3-2-1 ke 3-2-1-1-0 menarik buat saya: satu salinan harus immutable atau air-gapped, dan restore harus diverifikasi nol error [2]. CISA sendiri nyebutin test restore dan offline copy sebagai bagian dari pedoman backup yang benar [1].
Setup saya sekarang:
Salinan pertama, Git repo. Semua data kerja penting di-track. Dibundle secara berkala, patch index/stash dump jalan otomatis.
Salinan kedua, restic snapshot ke storage lokal terenkripsi. Restic verifiable, jadi saya bisa cek apakah file yang di-backup benar-benar bisa di-restore [7].
Salinan ketiga sekaligus kaki immutable, cloud off-site. Ini yang bikin pola 3-2-1 sah tanpa NAS atau tape, sebab syarat "dua jenis media" era dulu udah longgar jadi "dua device berbeda" di era cloud [3]. Dan karena cloud-nya immutable, ini sekaligus jadi salinan ke-empat di pola 3-2-1-1-0.
Setup tanpa NAS tetap sah. Saya pribadi lebih suka pola ini karena lebih sedikit hardware yang harus dirawat.
Satu hal yang saya pelajari dari commit kecil jam 7 pagi itu: backup strategy nggak dimulai dari "backup apa" tapi dari "apa yang boleh hilang." Dan ternyata, selama ini .gitignore saya diam-diam menjawab pertanyaan itu, tapi jawabannya kebalikan dari yang seharusnya.
Sumber: