Banyak Tim Yakin Bisa Recovery. Masalahnya: Sudah Pernah Dibuktikan?

Executive takeaway: Backup bukan lagi sekadar “ada copy data”. Untuk menghadapi ransomware, perusahaan perlu tahu apakah data bisa dipulihkan, berapa lama prosesnya, dan apakah backup tetap aman saat sistem utama sudah ditembus.

Laporan Veeam Data Trust and Resilience Report 2026 dan rilis resmi Veeam menyoroti pergeseran penting: organisasi tidak cukup hanya merasa yakin bisa pulih; kemampuan recovery perlu dibuktikan lewat data resilience, restore test, dan proses yang bisa dijalankan saat tekanan insiden nyata.

Bagi perusahaan di Indonesia, ini relevan. Banyak bisnis sudah punya backup, tetapi belum tentu punya bukti bahwa backup tersebut siap dipakai saat sistem operasional benar-benar berhenti.

Why this matters now

Ransomware biasanya tidak hanya menyerang server utama. Pelaku juga mencari repository backup, kredensial admin, storage yang terbuka, dan sistem monitoring yang lemah. Kalau backup ikut terenkripsi atau restore belum pernah diuji, tim IT bisa kehilangan waktu paling mahal: jam-jam pertama setelah insiden.

Masalahnya jarang terlihat di dashboard harian. Backup job bisa terlihat hijau, tetapi pertanyaan yang lebih penting adalah:

• Apakah backup copy terpisah dari domain utama?
• Apakah ada immutable atau tamper-resistant copy?
• Apakah restore pernah diuji untuk aplikasi prioritas?
• Apakah manajemen tahu estimasi downtime yang realistis?
• Apakah tim punya runbook saat ransomware terjadi di luar jam kerja?

Kalau jawabannya belum jelas, perusahaan belum benar-benar tahu posisi recovery-nya.

1. “Backup sukses” tidak sama dengan “bisnis bisa jalan lagi”

Banyak tim IT mengukur backup dari status job: sukses, gagal, atau warning. Itu penting, tapi belum cukup.

Yang dibutuhkan bisnis adalah bukti bahwa sistem kritikal bisa kembali digunakan. Misalnya ERP, file server, Microsoft 365, database customer, aplikasi finance, atau sistem operasional cabang.

Kalau perusahaan hanya melihat laporan backup harian, recovery risk masih bisa tersembunyi.

2. Ransomware recovery butuh copy yang sulit dirusak

Salah satu pelajaran penting dari insiden ransomware adalah pelaku sering mencoba menghancurkan jalur pemulihan. Mereka tidak hanya mengenkripsi data produksi. Mereka juga berusaha menghapus snapshot, menonaktifkan backup agent, atau memakai kredensial admin untuk masuk ke storage.

Karena itu, desain backup modern perlu memasukkan lapisan proteksi seperti:

• immutable backup untuk mencegah penghapusan atau perubahan selama periode tertentu;
• akses admin yang dipisah dari domain utama;
• offsite atau cloud copy untuk skenario site failure;
• monitoring anomali pada backup dan repository;
• dokumentasi restore yang bisa dijalankan oleh tim yang berbeda.

Tidak semua perusahaan harus langsung membangun arsitektur kompleks. Tetapi minimal, harus ada satu copy yang tetap aman saat environment utama bermasalah.

3. Restore test harus realistis, bukan sekadar formalitas

Restore test sering dilakukan terlalu ringan: ambil satu file kecil, restore berhasil, lalu dianggap selesai. Untuk audit dasar, itu membantu. Untuk ransomware, kurang.

Restore test yang lebih berguna harus meniru kebutuhan bisnis. Contohnya:

• restore satu VM aplikasi utama;
• restore database dengan dependensinya;
• restore file share dengan permission yang benar;
• restore mailbox atau data Microsoft 365 yang dibutuhkan user;
• simulasi urutan pemulihan: identity, network, server, aplikasi, lalu user access.

Tujuannya bukan membuat tim sibuk. Tujuannya menemukan masalah sebelum hari buruk datang.

Masalah yang sering muncul saat test:

• credential restore tidak tersedia;
• kapasitas sementara tidak cukup;
• dependency aplikasi tidak terdokumentasi;
• DNS atau firewall belum siap;
• tim bisnis tidak tahu prioritas sistem.

Lebih baik menemukan ini saat latihan daripada saat ransomware sudah aktif.

4. AI dan cloud membuat recovery planning makin penting

Banyak perusahaan mulai memakai AI, automation, SaaS, dan hybrid cloud. Itu mempercepat kerja, tetapi juga membuat data tersebar di lebih banyak tempat.

Data tidak lagi hanya berada di satu server lokal. Ada file di Microsoft 365, workload di cloud, endpoint user, database aplikasi, NAS, dan integrasi antar sistem. Kalau tidak dipetakan, tim sulit menjawab pertanyaan sederhana: data mana yang paling penting dan bagaimana cara memulihkannya?

Untuk perusahaan Indonesia yang sedang modernisasi cloud, pertanyaan recovery perlu masuk sejak awal desain. Jangan menunggu setelah migrasi selesai.

• Data kritikal sudah dipetakan per aplikasi?
• Owner bisnis tiap aplikasi sudah jelas?
• RTO dan RPO ditentukan berdasarkan dampak bisnis?
• Backup SaaS seperti Microsoft 365 sudah masuk scope?
• Restore cloud workload sudah pernah diuji?
• Ada prosedur saat kredensial admin dicurigai bocor?

5. Langkah praktis untuk 30 hari ke depan

Perusahaan tidak harus menyelesaikan semuanya sekaligus. Mulai dari langkah yang bisa diuji.

Kalau setelah 30 hari perusahaan punya bukti restore, daftar risiko, dan runbook awal, posisi recovery sudah jauh lebih jelas daripada sekadar mengandalkan status “backup sukses”.

Mulai dari assessment kecil

myBATICloud dapat membantu melakukan review ringan untuk backup dan ransomware recovery readiness, termasuk pengecekan immutable copy, restore test, RTO/RPO, serta opsi proteksi dengan Veeam, Acronis, Fortinet, dan managed IT support.

Untuk tim IT yang ingin mulai tanpa komitmen besar, langkah paling aman adalah assessment singkat: pilih satu sistem kritikal, cek jalur backup-nya, lalu buktikan restore-nya.

• Mulai assessment backup & recovery
• Jadwalkan konsultasi 30 menit
• Lihat layanan cloud, backup, dan security myBATICloud