3 Pilihan Backup dan Pemulihan Website Startup Setelah Diretas

Jution Candra Kirana · 2026-11-06 · Security

Senin pagi, tim customer success Anda melapor: halaman utama produk berubah jadi iklan judi online, dan form pendaftaran mengarahkan pengguna ke situs asing. Anda punya backup, setidaknya begitu yang dijanjikan paket hosting. Pertanyaannya: backup yang mana yang aman dipulihkan, dan berapa lama produk Anda boleh mati sebelum calon investor dan pelanggan mulai bertanya?

Situasi ini bukan skenario langka. Menurut ringkasan Lanskap Keamanan Siber Indonesia 2024 dari BSSN, sepanjang 2024 tercatat 5.780 kasus web defacement, dan 4.071 di antaranya terkait judi online yang menyasar situs pemerintah. Jika situs dinas saja bisa kebobolan, website startup dengan tim teknis dua orang jelas bukan pengecualian.

Kesalahan terbesar setelah diretas: langsung restore backup terbaru

Refleks pertama kebanyakan founder adalah menekan tombol "restore" di panel hosting. Masalahnya, penyerang jarang masuk dan langsung beraksi di menit yang sama. Mereka sering menanam backdoor lebih dulu, lalu menunggu.

Kasus Pusat Data Nasional Sementara (PDNS) pada Juni 2024 memberi gambaran jelas. Dalam keterangan pers yang dimuat Kominfo, BSSN menyebut ada upaya menonaktifkan Windows Defender sejak 17 Juni 2024 pukul 23.15 WIB, sementara aktivitas berbahaya baru berjalan pada 20 Juni dini hari. Pada tahap itu, layanan terkait storage seperti VSS, Hyper-V Volume, VirtualDisk, dan Veeam vPower NFS ikut dinonaktifkan dan crash. Artinya, penyerang sengaja mengincar infrastruktur pencadangan, dan ada jeda beberapa hari antara masuknya penyerang dan serangan terlihat.

Untuk website Anda, pelajarannya sederhana. Backup dari kemarin bisa saja sudah berisi file berbahaya. Jika Anda memulihkannya tanpa pemeriksaan, Anda hanya memutar ulang insiden yang sama, kadang dalam hitungan jam.

Tiga angka yang menentukan rencana pemulihan Anda

Sebelum memilih alat, tentukan dulu target bisnisnya. Panduan NIST SP 800-34 Rev. 1 tentang contingency planning memakai tiga ukuran yang tetap relevan untuk startup:

MTD (Maximum Tolerable Downtime): total waktu gangguan yang masih bisa diterima pemilik bisnis, dengan memperhitungkan semua dampaknya.
RTO (Recovery Time Objective): batas waktu maksimal sebuah sistem boleh tidak tersedia sebelum dampaknya tidak bisa diterima.
RPO (Recovery Point Objective): titik waktu terakhir data bisa dipulihkan dari backup. Ini mengukur seberapa banyak data yang rela Anda kehilangan.

Contoh konkret: startup SaaS kasir untuk UMKM di Bandung menerima transaksi sepanjang hari. Kehilangan data transaksi enam jam berarti merchant harus merekap manual, jadi RPO-nya sebaiknya di bawah satu jam. Sebaliknya, landing page startup edtech yang isinya jarang berubah bisa hidup dengan RPO satu hari dan RTO setengah hari.

CISA, dalam panduan pencadangan untuk usaha kecil dan menengah, menyarankan uji pemulihan terjadwal untuk memverifikasi integritas backup sekaligus menyempurnakan RPO dan RTO. CISA juga meminta tim memastikan data bisa digulirkan mundur minimal tujuh hari. Angka tujuh hari ini penting justru karena pola seperti kasus PDNS: Anda butuh cukup banyak titik pulih untuk mundur ke masa sebelum penyerang masuk.

Membandingkan tiga pilihan backup dan pemulihan untuk startup

Ada tiga pendekatan yang paling sering kami temui di lapangan. Ketiganya sah, tetapi daya tahannya terhadap peretasan sangat berbeda.

Kriteria	A. Snapshot bawaan hosting/VPS	B. Backup 3-2-1 terpisah	C. Rebuild bersih + restore data
Cara kerja	Panel hosting membuat salinan server atau akun secara otomatis	Salinan database dan file dikirim terjadwal ke penyimpanan lain, termasuk satu salinan off-site atau offline	Server dibangun ulang dari kode di Git dan konfigurasi terdokumentasi, lalu hanya data yang dipulihkan dari backup terverifikasi
Kelebihan	Paling mudah, hampir tanpa setup, restore cepat	Tahan jika akun hosting diambil alih; retensi bisa diatur lebih panjang	Paling kecil risiko backdoor ikut terbawa; sekaligus memperbaiki celah lama
Kekurangan	Satu akun yang sama; jika panel dibobol, snapshot bisa ikut dihapus; retensi sering pendek	Perlu disiplin rotasi kunci, pemantauan, dan uji restore	Butuh kode dan konfigurasi yang rapi; waktu pemulihan awal lebih lama
Perkiraan biaya	Sering sudah termasuk paket atau tambahan kecil per bulan	Umumnya puluhan hingga ratusan ribu rupiah per bulan untuk website kecil, ditambah waktu engineer	Hampir tanpa biaya alat tambahan, tetapi investasi waktu di awal
Kapan cocok	Landing page sederhana, tahap validasi ide	Produk yang sudah punya pengguna dan data transaksi	Setelah insiden nyata, atau produk yang menyimpan data pelanggan sensitif

Pilihan B mengikuti aturan 3-2-1 yang dijelaskan CISA: tiga salinan file penting, dua jenis media penyimpanan berbeda (misalnya hard drive dan cloud), dan satu salinan disimpan di luar lokasi bisnis. CISA juga menganjurkan perlindungan backup berupa keamanan fisik, enkripsi, dan salinan offline. Dalam praktik startup, "offline" bisa berarti salinan mingguan ke bucket di akun cloud terpisah dengan kredensial yang tidak pernah disimpan di server produksi.

Pilihan C sering dianggap terlalu repot, padahal inilah cara paling aman setelah diretas. Anda tidak perlu menebak file mana yang disusupi, karena semua kode berasal dari repositori yang riwayat perubahannya bisa diaudit. Yang dipulihkan dari backup hanyalah isi database dan file unggahan pengguna, dan keduanya tetap perlu diperiksa.

Rekomendasi sesuai tahap startup Anda

Jika Anda masih di tahap validasi dengan website statis atau WordPress sederhana, pilihan A cukup sebagai titik awal. Tambahkan satu kebiasaan: ekspor database dan folder unggahan sebulan sekali ke penyimpanan di luar akun hosting. Kesalahan yang sering kami lihat adalah founder mengira snapshot hosting otomatis bertahan berbulan-bulan, padahal retensinya hanya beberapa hari.

Jika produk Anda sudah menerima pembayaran atau menyimpan data pelanggan, kombinasikan B dan C. Jalankan backup database terjadwal sesuai RPO, simpan salinan di akun terpisah dengan retensi minimal tujuh hari sesuai saran CISA, dan pastikan seluruh kode serta konfigurasi server ada di Git. Untuk tim dua sampai lima engineer, setup awal ini realistis selesai dalam satu sampai dua sprint.

Jika Anda sedang menangani insiden hari ini, langsung pakai pendekatan C. Urutannya kira-kira seperti ini:

Isolasi: putuskan akses publik atau tampilkan halaman pemeliharaan, tetapi jangan hapus server yang terinfeksi. Server itu adalah barang bukti.
Cari titik masuk dan waktunya: periksa log akses, akun admin baru, dan file yang berubah untuk memperkirakan kapan penyerang pertama kali masuk.
Ganti semua kredensial: password panel hosting, database, API key, token CI/CD, dan akun email admin.
Bangun ulang di server baru dari kode Git yang bersih, lalu tambal celah yang dipakai penyerang, misalnya plugin usang.
Pulihkan data dari backup sebelum waktu masuknya penyerang, periksa tabel pengguna dan konten, lalu buka akses bertahap sambil memantau log.
Laporkan dan dokumentasikan: catat kronologi untuk tim, pelanggan yang terdampak, dan bila perlu manfaatkan layanan aduan siber BSSN. Sepanjang 2024 saja, BSSN mencatat 1.814 aduan dari pemangku kepentingan.

Uji restore adalah bagian yang paling sering dilewati

Backup yang belum pernah diuji pada dasarnya hanya asumsi. CISA menyebut bahwa pemulihan tanpa backup bisa memakan waktu berminggu-minggu hingga berbulan-bulan, bahkan mustahil. Kondisinya tidak jauh berbeda jika backup Anda ternyata korup atau tidak lengkap.

Jadwalkan uji restore tiap kuartal. Ambil backup acak, pulihkan ke server staging, lalu ukur waktunya dari awal hingga aplikasi bisa dipakai login. Jika hasilnya empat jam sementara target RTO Anda satu jam, Anda baru saja menemukan masalah dengan biaya nol rupiah, bukan saat pelanggan menunggu.

CISA juga menekankan pelatihan tim: rencana backup hanya berguna jika semua orang tahu cara memakainya. Tulis runbook satu halaman berisi lokasi backup, siapa yang memegang kredensial akun cadangan, dan urutan langkah pemulihan. Simpan juga salinannya di luar sistem yang mungkin ikut lumpuh, misalnya dokumen cetak atau drive pribadi founder.

Langkah berikutnya yang bisa Anda mulai minggu ini

Mulailah dari pertanyaan bisnis, bukan alat. Tetapkan RPO dan RTO untuk setiap bagian produk Anda, misalnya landing page, dashboard pengguna, dan database transaksi. Setelah itu, cek apakah backup Anda saat ini benar-benar memenuhi target tersebut: di mana disimpan, berapa lama retensinya, dan apakah tersimpan di akun yang terpisah dari produksi.

Lalu lakukan satu uji restore ke staging sebelum akhir bulan. Hasilnya akan menunjukkan dengan jujur apakah Anda butuh pilihan A, B, C, atau kombinasinya.

Jika Anda ingin rencana backup dan pemulihan yang disesuaikan dengan arsitektur dan anggaran startup Anda, tim MIPDEVP siap membantu meninjau setup Anda saat ini dan menyusun runbook pemulihan yang bisa langsung dipakai tim.

Sumber

Foto oleh imgix di Unsplash.