Data Hilang di Cloud: Pelajaran dari Kasus 170 Ribu Organisasi dan Cara Melindungi Data

Bayangkan data organisasi lo hilang dalam semalam — ribuan dokumen, database pelanggan, arsip email, semua lenyap. Bukan karena server lo kena ransomware atau hard disk rusak, tapi karena data itu hanya disimpan di cloud dan akunnya dinonaktifkan. Ini bukan skenario fiksi: kasus yang menimpa lebih dari 170 ribu organisasi nonprofit yang kehilangan data mereka menjadi pengingat keras bahwa "disimpan di cloud" tidak sama dengan "aman".

Artikel ini membahas apa yang sebenarnya terjadi dalam kasus tersebut, mengapa data bisa hilang padahal "ada di cloud", dan strategi backup yang benar untuk developer, bisnis kecil, dan organisasi yang tidak boleh kehilangan datanya.

Apa yang Terjadi

Berita tersebut menyoroti situasi di mana lebih dari 170 ribu organisasi nonprofit menghadapi kehilangan data karena ketergantungan pada layanan cloud Microsoft. Akar masalahnya bukan sekadar "server down" — melainkan kombinasi kebijakan akun, masa tenggang yang terlewat, dan asumsi bahwa cloud selalu menyimpan data secara permanen.

Penting untuk dipahami: kasus ini bukan berarti Microsoft secara sembarangan menghapus data. Layanan cloud punya kebijakan tentang apa yang terjadi pada data saat akun nonaktif, lisensi tidak diperpanjang, atau masa tenggang berakhir. Masalah muncul ketika organisasi tidak menyadari atau tidak mempersiapkan kebijakan tersebut — data yang tidak di-backup di tempat lain bisa hilang permanen.

Ini adalah pelajaran klasik tentang shared responsibility di cloud: penyedia bertanggung jawab menjaga infrastruktur, tapi tanggung jawab atas data lo — termasuk backup — ada di tangan lo.

Mitos "Cloud = Aman Otomatis"

Ada mitos yang sangat umum dan berbahaya: "data saya di cloud, jadi pasti aman." Realitanya, cloud melindungi dari kegagalan hardware, bukan dari kesalahan manusia atau kebijakan. Berikut beberapa cara data di cloud bisa hilang:

• Akun dinonaktifkan. Akun yang dianggap tidak aktif, tidak membayar, atau melanggar kebijakan bisa dinonaktifkan. Setelah masa tenggang lewat, data bisa dihapus.
• Lisensi berakhir. Layanan enterprise yang lisensinya tidak diperpanjang bisa membatasi akses, dan dalam beberapa kasus menghapus data tenant.
• Admin menghapus secara tidak sengaja. Kesalahan konfigurasi atau penghapusan massal oleh admin adalah penyebab kehilangan data yang sangat umum.
• Ransomware dan kompromi akun. Akun yang diretas bisa dienkripsi atau dihapus oleh attacker — dan sync cloud menyebarkan kerusakan ke semua perangkat.
• Sinkronisasi yang salah. Perubahan yang salah tersinkronisasi ke semua perangkat, menghapus data yang seharusnya dipertahankan.

Intinya: cloud adalah tempat penyimpanan, bukan sistem backup. Dua hal yang sangat berbeda.

Aturan Backup yang Benar: 3-2-1

Prinsip backup yang paling banyak direkomendasikan oleh praktisi IT adalah aturan 3-2-1:

• 3 salinan data. Data utama plus dua salinan.
• 2 media berbeda. Misalnya cloud + hard disk eksternal, atau NAS + cloud.
• 1 salinan offsite. Satu salinan di lokasi fisik berbeda — supaya bencana lokal (kebakaran, banjir, pencurian) tidak menghancurkan semua salinan.

Contoh penerapan untuk bisnis kecil: data utama di laptop + backup harian ke NAS di kantor + backup mingguan ke cloud (atau sebaliknya: utama di cloud + backup lokal). Yang penting adalah tidak semua telur di satu keranjang, dan setidaknya satu salinan berada di luar lokasi utama.

Untuk developer, aturan ini juga berlaku untuk project code: git remote saja tidak cukup sebagai backup. Push ke dua remote berbeda (misalnya GitHub + GitLab, atau GitHub + server pribadi), dan pastikan database production punya backup terjadwal yang diuji restore-nya.

Backup untuk Developer dan Bisnis Kecil

Beberapa strategi praktis yang bisa langsung diterapkan:

1. Otomatiskan, jangan andalkan ingatan. Backup manual selalu terlewat. Gunakan tool yang terjadwal: cron + restic atau borgbackup untuk server, Time Machine untuk Mac, File History untuk Windows.

2. Backup database production. Database adalah data paling kritis. Jadwalkan dump database harian (misalnya pg_dump untuk PostgreSQL, mysqldump untuk MySQL) dan simpan di lokasi terpisah. Jangan pernah hanya mengandalkan snapshot VM — snapshot bukan backup yang bisa di-restore per-file.

3. Uji restore secara berkala. Backup yang tidak pernah diuji restore bukan backup — itu harapan. Jadwalkan uji restore bulanan: ambil backup terbaru, restore ke mesin kosong, dan pastikan data bisa dibaca. Banyak organisasi baru sadar backupnya rusak justru saat data hilang.

4. Gunakan enkripsi untuk backup offsite. Backup yang disimpan di cloud pihak ketiga sebaiknya dienkripsi. Tool seperti restic, borg, atau rclone dengan enkripsi memastikan data lo tidak bisa dibaca oleh siapa pun kecuali lo.

5. Terapkan retention policy. Simpan beberapa versi backup (misalnya harian 7 hari, mingguan 4 minggu, bulanan 12 bulan). Ini melindungi dari kasus ransomware yang butuh waktu untuk terdeteksi — backup versi lama bisa menyelamatkan data yang sudah terenkripsi.

Pelajaran untuk Organisasi dan Bisnis

Kasus 170 ribu organisasi ini mengajarkan beberapa hal yang berlaku universal:

• Baca kebijakan penyedia. Pahami apa yang terjadi pada data saat akun nonaktif, lisensi berakhir, atau masa tenggang lewat. Tulis ringkasannya dan pastikan tim tahu.
• Jangan bergantung pada satu vendor. Vendor lock-in memperbesar risiko: kalau akun lo bermasalah di satu platform, semua data ikut bermasalah. Ekspor data secara berkala ke format standar.
• Data yang tidak bisa di-restore bukan data lo. Kalau satu-satunya salinan data ada di cloud dan tidak bisa diakses, secara praktis data itu hilang.
• Anggaran backup, bukan anggaran harapan. Backup butuh biaya — storage, tool, waktu. Tapi biaya itu jauh lebih kecil daripada biaya kehilangan data.

Untuk organisasi nonprofit atau komunitas yang sering kekurangan sumber daya, ada banyak tool backup open-source yang gratis: restic, borgbackup, duplicity, rclone, dan lain-lain. Biaya terbesarnya bukan tool-nya, tapi disiplin menjalankan dan menguji backup secara rutin.

Contoh Implementasi Backup Sederhana

Buat yang baru memulai, berikut contoh implementasi backup yang bisa langsung dipakai — kombinasi tool open-source yang umum dan murah:

Backup file + database di server dengan restic. Restic melakukan backup berdeduplikasi dan terenkripsi ke berbagai destination — termasuk S3-compatible storage, Backblaze B2, atau drive lokal. Contoh skrip harian:

#!/bin/bash
# /usr/local/bin/backup-daily.sh
export RESTIC_REPOSITORY="b2:toolkuy-backup:restic"
export RESTIC_PASSWORD_FILE="/etc/restic/pass"

# Backup folder penting
restic backup /srv/www /var/www     --exclude="*/node_modules" --exclude="*.log"

# Backup database PostgreSQL
pg_dump -Fc mydb > /tmp/mydb.dump
restic backup /tmp/mydb.dump --tag db
rm /tmp/mydb.dump

# Bersihkan backup lama (retensi: 7 harian, 4 mingguan, 12 bulanan)
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

Jadwalkan dengan cron atau systemd timer supaya jalan otomatis setiap hari. Yang penting: lokasi repository backup terpisah dari server utama — kalau server kena ransomware, backup di tempat lain tetap aman.

Uji restore secara berkala. Ini langkah yang paling sering dilewati. Jadwalkan uji restore bulanan, misalnya dengan memulihkan backup ke folder kosong dan membandingkan jumlah file:

restic restore latest --target /tmp/restore-test
find /tmp/restore-test -type f | wc -l
find /srv/www -type f | wc -l

Kalau dua angka terakhir tidak mendekati sama, ada yang salah dengan backup lo — dan lebih baik tahu sekarang daripada saat data sudah hilang. Banyak tim membuat script uji restore ini otomatis dan mengirim hasilnya ke monitoring (misalnya status page atau notifikasi).

Ekspor data dari SaaS secara berkala. Untuk layanan cloud yang lo pakai — email, dokumen, spreadsheet, database SaaS — jadwalkan ekspor reguler ke format standar (CSV, JSON, atau file asli) dan simpan di lokasi yang lo kontrol. Banyak layanan menyediakan API atau fitur export; manfaatkan itu. Ekspor bulanan sudah cukup untuk sebagian besar kasus, dan biaya penyimpanannya kecil.

Kesimpulan

Kehilangan data 170 ribu organisasi adalah pengingat yang mahal: cloud adalah tempat penyimpanan, bukan jaminan keamanan data. Penyedia cloud menjaga infrastruktur, tapi tanggung jawab atas data — backup, restore, retention — ada di tangan pemilik data.

Kabarnya, kasus ini pun akhirnya berujung pada respons dari pihak terkait dan diskusi luas tentang kebijakan data organisasi nirlaba. Tapi pelajaran teknisnya jelas dan berlaku untuk semua orang: terapkan aturan 3-2-1, otomatiskan backup, uji restore secara berkala, dan jangan pernah menyimpan satu-satunya salinan data di satu tempat — termasuk di cloud.

Kalau lo belum punya sistem backup yang diuji, hari ini adalah waktu yang tepat untuk memulai. Bukan karena lo akan kehilangan data besok, tapi karena ketika data hilang, tidak ada yang bisa mengembalikan waktu.