Rutin Uji Restore Backup Terisolasi, Pelajaran dari Insiden Ransomware PDNS

Banyak pemilik server merasa tenang karena di panel ada jadwal backup harian yang statusnya selalu sukses. Masalahnya, file backup itu sering disimpan di disk yang sama, di folder yang bisa ditulis oleh user yang sama, dan belum pernah sekali pun dicoba di-restore. Selama server sehat, kelemahan ini tidak kelihatan. Baru terasa saat data utama rusak atau terenkripsi, dan ternyata backup-nya ikut hilang atau tidak bisa dipakai. Insiden ransomware yang melumpuhkan Pusat Data Nasional Sementara (PDNS) 2 di Surabaya pada Juni 2024 menunjukkan pola ini dalam skala besar. Artikel ini membedahnya dengan format post-mortem, lalu menerjemahkannya ke langkah yang bisa kita terapkan di server sendiri, dari shared hosting sampai VPS.

Dampak awal ketika data utama terenkripsi

Ransomware adalah malware yang mengenkripsi data lalu meminta tebusan untuk kunci dekripsinya. Di kasus PDNS 2, data banyak instansi pemerintah yang menjadi tenant (penyewa layanan) di pusat data itu terenkripsi sekaligus. Menurut ringkasan evaluasi yang beredar, pemerintah menolak membayar tuntutan tebusan yang nilainya disebut sekitar USD 8 juta atau Rp131 miliar. Menolak tebusan itu keputusan yang masuk akal, tapi konsekuensinya jelas: pemulihan harus datang dari backup. Di sinilah temuan paling penting muncul. Sebagian besar tenant ternyata tidak punya backup berkala yang terisolasi, dan tidak ada disaster recovery plan (DRP), yaitu rencana pemulihan bencana yang sudah disiapkan dan siap dijalankan. Temuan kedua adalah single point of failure, atau titik kegagalan tunggal. Data dipusatkan tanpa redundansi kuat di lokasi fisik berbeda, sehingga saat satu pusat data lumpuh, tidak ada failover otomatis yang mengambil alih. Dampaknya terasa luas karena banyak layanan bergantung pada satu tempat. Kalau dilihat dari meja support hosting, dua temuan ini sangat familiar. Bedanya hanya skala. Satu VPS dengan backup di /backup pada disk yang sama punya kelemahan yang persis serupa.

Urutan investigasi yang biasanya terjadi setelah server terenkripsi

Untuk server kita sendiri, investigasi setelah ransomware biasanya berjalan dengan urutan yang mirip. Ini bukan kronologi PDNS, melainkan pola umum yang sering muncul. Pertama, gejala di permukaan: website error, file berubah ekstensi, ada file catatan tebusan di banyak folder, atau database tidak bisa dibuka. Langkah wajar berikutnya adalah mencari tahu seberapa luas kerusakannya. Apakah hanya satu akun, satu direktori, atau seluruh disk? Kedua, mencari backup. Di tahap ini biasanya muncul kejutan. Folder backup lokal ikut terenkripsi karena berada di filesystem yang sama. Storage jaringan yang di-mount permanen juga ikut kena, karena dari sudut pandang malware itu hanya direktori lain yang bisa ditulis. Backup remote yang dikirim pakai kredensial yang tersimpan di server utama bisa dihapus atau ditimpa oleh penyerang yang sudah memegang akses root. Ketiga, kalau masih ada backup yang selamat, muncul pertanyaan yang tidak pernah dijawab sebelumnya. Backup ini dari kapan? Apakah lengkap, termasuk database dan email? Berapa lama proses restore-nya? Restore ke mana, kalau server lama masih terinfeksi?

Titik temuan: backup ada, tapi tidak bisa dipakai

Momen kritis di hampir setiap post-mortem seperti ini sama: tim sadar bahwa punya backup dan bisa pulih dari backup adalah dua hal berbeda. Backup yang benar-benar terisolasi minimal memenuhi beberapa syarat. Lokasinya terpisah secara fisik atau setidaknya berada di sistem berbeda dari server utama. Kredensialnya terpisah, sehingga akses root di server produksi tidak otomatis memberi hak menghapus backup. Storage-nya tidak di-mount permanen ke server produksi. Idealnya ada versi lama yang tidak bisa diubah, misalnya lewat versioning atau fitur immutability di storage yang mendukungnya. Fitur ini berbeda di tiap penyedia, jadi cek dokumentasi storage yang kamu pakai. Aturan praktis yang sering dipakai adalah 3-2-1: tiga salinan data, di dua media berbeda, dan satu di lokasi lain. Ini bukan standar resmi yang kaku, tapi cukup bagus sebagai titik awal untuk mengecek apakah backup kita punya satu titik kegagalan. Satu pola desain yang membantu adalah backup berbasis pull. Server backup yang menarik data dari server produksi, bukan server produksi yang mengirim ke server backup. Dengan begitu, server produksi tidak menyimpan kredensial untuk menulis atau menghapus isi server backup. Kalau produksi dibobol, penyerang tidak langsung punya jalan ke salinan cadangan. Syarat kedua yang sering terlupa: backup harus pernah dites restore. Status sukses di log backup hanya berarti proses pembuatan arsip selesai tanpa error. Itu tidak menjamin arsipnya lengkap, database-nya konsisten, atau kita tahu langkah memulihkannya.

Mitigasi sementara: karantina dulu, baru pulihkan

Dalam penanganan PDNS, salah satu langkah jangka pendek adalah Zona Merah, yaitu mengisolasi total sistem PDNS 2 yang terinfeksi agar ransomware tidak menyebar ke infrastruktur lain seperti PDN 1 di Serpong. Prinsip ini berlaku juga di skala kecil. Urutannya kurang lebih begini:

Putus akses jaringan server yang terinfeksi, atau setidaknya batasi hanya untuk akses investigasi. Jangan langsung dihapus, karena jejaknya mungkin dibutuhkan untuk mencari tahu cara penyerang masuk.
Jangan sambungkan storage backup ke server yang terinfeksi. Ini kesalahan yang cukup umum: panik, lalu me-mount disk backup ke server lama untuk restore, dan backup terakhir yang selamat ikut terenkripsi.
Siapkan server baru yang bersih, lalu restore dari backup ke sana.
Ganti semua kredensial yang pernah ada di server lama: password panel, SSH key, password database, API token.
Tutup celah yang dipakai penyerang sebelum layanan dibuka kembali, supaya tidak terinfeksi ulang.

Peringatan: jangan restore backup ke server yang masih terinfeksi, dan jangan menjalankan perintah penghapusan massal di server itu sebelum bukti yang dibutuhkan diamankan. Keduanya sulit atau tidak mungkin dibalik.

Perbaikan arsitektur: backup terisolasi dan jadwal uji restore

Perbaikan jangka panjang punya dua bagian: memindahkan backup ke tempat yang aman, dan membuktikan secara rutin bahwa backup itu bisa dipulihkan. Untuk bagian pertama, cek backup yang kamu punya sekarang dengan pertanyaan sederhana. Kalau akun root server ini jatuh ke tangan orang lain, apakah dia bisa menghapus semua backup? Kalau jawabannya ya, backup itu belum terisolasi. Untuk bagian kedua, mulai dari cek integritas file. Perintah di bawah ini read-only dan aman dijalankan. Path-nya contoh, sesuaikan dengan lokasi backup kamu.

BASH

# Cek arsip tar.gz bisa dibaca utuh sampai akhir
tar -tzf /path/ke/backup-situs.tar.gz > /dev/null && echo 'arsip terbaca utuh'

# Cek dump database terkompresi tidak korup
gunzip -t /path/ke/database.sql.gz && echo 'file gzip valid'

# Cocokkan checksum yang dicatat saat backup dibuat
sha256sum -c /path/ke/backup.sha256

Cek seperti ini hanya membuktikan file tidak rusak. Ia tidak membuktikan isinya lengkap atau aplikasinya jalan. Karena itu tetap perlu uji restore sungguhan ke lingkungan terpisah, misalnya VPS sementara yang tidak terhubung ke produksi. Sebagai rule of thumb, jadwal yang cukup realistis untuk banyak tim kecil:

Setiap minggu: cek log backup dan integritas file seperti di atas.
Setiap bulan: restore satu situs atau satu akun secara penuh ke server uji, lalu buka website-nya, login ke admin, dan cek data terbaru ada di sana.
Setiap kuartal: latihan pemulihan penuh, seolah server utama hilang. Catat berapa lama prosesnya dan langkah apa yang ternyata tidak terdokumentasi.

Dari latihan itu kamu akan dapat dua angka penting. RPO (Recovery Point Objective) adalah seberapa banyak data yang rela hilang, terlihat dari umur backup terakhir. RTO (Recovery Time Objective) adalah seberapa lama layanan boleh mati sampai pulih. Kalau hasil latihan jauh dari harapan, itu sinyal untuk menambah frekuensi backup atau menyederhanakan proses restore. Kalau server kamu memakai WHM, langkah teknis untuk memeriksa log backup dan mencoba restore akun sudah dibahas di Cara Memastikan Backup WHM Benar-Benar Bisa Di-restore Sebelum Dibutuhkan. Di sisi support, pertanyaan pertama saat pelanggan minta restore darurat biasanya bukan soal teknis, melainkan soal lokasi backup dan kapan terakhir dites. Jawaban untuk dua pertanyaan itu sering menentukan apakah pemulihan butuh beberapa jam atau tidak bisa dilakukan sama sekali. Pelajaran dari PDNS sebenarnya sederhana: backup yang tinggal satu atap dengan data utama akan ikut jatuh bersamanya, dan backup yang tidak pernah dites hanyalah asumsi. Pindahkan minimal satu salinan ke sistem dengan kredensial berbeda, jadwalkan uji restore bulanan di kalender tim, dan tulis langkah pemulihannya selagi semuanya masih tenang.