Data RME Hilang? Mulai Sekarang Jangan Anggap Remeh Backup

Sobat IT RS, pernah gak sih ngalamin momen paling horor di dunia SIMRS: tiba-tiba server rekam medis elektronik (RME) ngadat, terus pas dicek sama vendor, ternyata disk-nya bad sector dan data gak bisa di-recover? Atau lebih serem lagi, kena ransomware yang ngunci seluruh database pasien dan minta tebusan puluhan juta? Kalau belum pernah, alhamdulillah. Tapi kalau sudah pernah, kamu pasti paham betul kenapa topik backup itu bukan sekadar "nanti-nanti deh" alias pekerjaan yang bisa ditunda.

Di artikel ini gue mau bahas tuntas strategi backup 3-2-1 yang sebenernya simpel banget, tapi jarang banget diterapkan bener-bener di rumah sakit. Bukan teori muluk-muluk, tapi praktik yang bisa langsung kamu terapin minggu ini juga. Karena percaya deh, data RME itu bukan cuma catatan medis, tapi dokumen legal yang dilindungi undang-undang, dan kalau hilang, yang repot bukan cuma IT, tapi seluruh rumah sakit.

Kenapa Data RME Lebih Kritis dari Data Keuangan?

Banyak manajemen RS yang masih mikir kalau backup itu buat data keuangan aja. Padahal data rekam medis itu jauh lebih krusial. Coba bayangin: pasien kontrol ke poli, dokter butuh riwayat diagnosis dan hasil lab sebelumnya buat nentuin terapi. Kalau data itu hilang, dokter harus ngulang pemeriksaan dari nol, pasien komplain, dan yang paling bahaya, ada potensi salah terapi karena informasi yang gak lengkap.

Belum lagi dari sisi legal. Rekam medis itu alat bukti di pengadilan. Kalau ada sengketa malpraktik dan data RME-nya hilang, rumah sakit bakal kerepotan banget di meja hijau. Terus ada juga regulasi akreditasi yang makin ketat soal manajemen data, termasuk kewajiban punya backup yang bisa diuji (restore test). Jadi bukan lebay kalau gue bilang: data RME adalah nyawa digital rumah sakit.

Apa Itu Strategi Backup 3-2-1?

Aturan 3-2-1 ini sebenernya udah jadi standar industri di dunia IT sejak lama, tapi masih jarang dipraktekkin di RS. Prinsipnya gampang diinget:

  • 3 salinan data — satu data produksi, plus minimal dua salinan backup.
  • 2 media yang berbeda — misalnya satu di NAS/disk internal, satu di tape atau cloud. Jangan dua-duanya di harddisk eksternal yang ditaruh di samping server, karena sama-sama satu bencana.
  • 1 salinan offsite — disimpan di lokasi fisik yang beda dari server utama. Kalau gedung kebakaran, data masih aman di tempat lain.

Simpel kan? Nah, masalahnya banyak RS yang udah "rasa-rasanya" nerapin 3-2-1, tapi pas dicek, ternyata semua backup ada di satu rak yang sama dengan server. Itu namanya bukan 3-2-1, tapi 3-1-0. Satu bencana, semua lenyap.

Langkah Praktis Nerapin Backup di RS

1. Backup Database, Bukan Cuma File Aplikasi

Kesalahan klasik: backup cuma folder aplikasi SIMRS, padahal datanya ada di database server (SQL Server atau PostgreSQL). Backup database itu wajib pakai tools bawaan yang bener, bukan sekadar copy file .mdf pas server nyala, karena hasilnya bakal korup.

Contoh backup SQL Server pake script SQL Agent job:

BACKUP DATABASE [SIMRS]
TO DISK = N'E:\Backup\SIMRS\SIMRS_FULL_20260826.bak'
WITH COMPRESSION, INIT, STATS = 10;

Sedangkan buat PostgreSQL, bisa pake pg_dump atau pg_basebackup kalau mau continuous archiving:

pg_dump -h localhost -U simrs -Fc simrs_db > /backup/simrs_$(date +%Y%m%d).dump

2. File RME (Scan, PDF, Citra) Jangan Dilupain

RME jaman sekarang gak cuma teks. Ada hasil scan surat rujukan, PDF hasil lab, foto luka, sampai file DICOM kalau terintegrasi dengan PACS. File-file ini sering kebagian di luar jadwal backup database. Padahal justru yang gede-gede ini yang paling sering ilang. Pakai tool rsync atau robocopy buat sinkronisasi file ke NAS secara terjadwal, plus versi history biar bisa balik ke kondisi kemarin kalau ada file ke-overwrite.

3. Jadwalkan dengan Pola yang Masuk Akal

Gak perlu backup full tiap jam, itu boros storage. Pola yang umum dipakai:

  • Full backup tiap hari (misal jam 02.00 WIB pas beban pelayanan sepi).
  • Transaction log / WAL tiap 15-30 menit buat SQL Server / PostgreSQL, biar data hilang maksimal cuma hitungan menit.
  • Arsip bulanan yang disimpen lebih lama, misal 3-6 bulan atau sesuai regulasi penyimpanan rekam medis (minimal 5 tahun secara umum!).

Offsite Itu Bukan Opsional, Ini Bagian dari 3-2-1

Banyak alasan klasik: "cloud mahal", "internet lemot", "nanti aja lah". Gue paham banget. Tapi offsite itu bisa dimulai dari yang murah dulu: backup harian ke NAS di gedung lain (kalau RS kamu punya kampus beda), atau pake storage cloud murah kayak Backblaze B2, Wasabi, atau bucket S3 dengan lifecycle policy. Yang penting ada satu salinan yang secara fisik terpisah dari server produksi.

Kalau mau lebih hemat lagi, bisa kombinasi: harian ke NAS lokal, terus tiap minggu NAS lokal di-replikasi ke cloud pake Rclone. Contoh konfigurasi Rclone yang gampang di-cron:

rclone sync /backup/simrs backupb2:simrs-backup \
  --transfers 4 --fast-list --log-file=/var/log/rclone.log

Backup Tanpa Restore Test Itu Cuma Ilusi Keamanan

Ini bagian yang paling sering gue tekankan ke Sobat AITI: backup yang gak pernah di-restore itu bukan backup, itu cuma koleksi file. Bayangin, kamu backup tiap hari selama 2 tahun, terus pas bencana dateng, ternyata file backup-nya korup karena ternyata disk NAS-nya udah rusak pelan-pelan. Gimana rasanya? Mending jangan dibayangin, mending langsung dicek.

Bikin jadwal restore test bulanan atau minimal 3 bulan sekali:

  • Restore database ke server uji (bukan server produksi!)
  • Jalankan integrity check: DBCC CHECKDB buat SQL Server, atau pg_dump | pg_restore di PostgreSQL
  • Sampein hasil test ke manajemen dalam bentuk laporan singkat, biar mereka paham backup itu kerjaan nyata
  • Dokumentasikan berapa lama restore-nya, biar tahu estimasi RTO (Recovery Time Objective) yang realistis

Ransomware: Kenapa Backup Biasa Kadang Gak Cukup

Serangan ransomware di RS Indonesia bukan cuma isu global, udah ada kasus nyata. Modusnya gak cuma ngunci data, tapi sekarang mereka juga nyuri data dulu, baru minta tebusan. Nah, kalau cuma backup biasa yang tersambung terus ke server, ransomware bisa ikut menginfeksi dan mengenkripsi backup-nya juga.

Solusinya: immutable backup atau air gap. Immutable artinya file backup gak bisa diubah/dihapus dalam periode tertentu, bahkan oleh admin sekalipun. Layanan cloud kayak Wasabi atau S3 Object Lock bisa dikonfigurasi immutable. Buat yang on-premise, bisa pake tape yang dilepas dari mesin setelah backup selesai, atau NAS dengan snapshot read-only yang dipisah dari jaringan produksi.

Monitoring Backup Itu Wajib, Bukan Cuma Pasang Jadwal

Backup job gagal itu hal yang wajar terjadi: disk penuh, kredensial kedaluwarsa, jaringan mati. Yang gak wajar adalah kalau gagal terus tapi gak ada yang tahu selama berminggu-minggu. Makanya wajib ada monitoring yang proaktif.

Paling gampang: email notifikasi otomatis dari SQL Agent job atau cron, plus script yang ngecek umur file backup terakhir:

#!/bin/bash
# cek backup terakhir
LATEST=$(ls -t /backup/simrs/*.dump | head -1)
AGE=$(( ($(date +%s) - $(stat -c %Y "$LATEST")) / 3600 ))
if [ $AGE -gt 26 ]; then
  echo "BACKUP LAMA! $LATEST umur ${AGE} jam" | mail -s "ALERT Backup SIMRS" it@rs.example
fi

Bikin Kebijakan Backup yang Disetujui Manajemen

Terakhir, semua teknis ini harus dibungkus dalam dokumen kebijakan (SOP) yang ditandatangani manajemen. Isinya minimal: apa yang di-backup, seberapa sering, berapa lama disimpan (retensi), siapa penanggung jawab, gimana prosedur restore, dan target RPO/RTO. Dengan ada SOP, kamu punya pegangan buat minta budget storage atau cloud ke direksi, dan ada alasan kuat kalau suatu saat ada insiden.

Mulai dari yang kecil dulu, Sob. Cek dulu: apakah backup database RME kamu jalan tadi malam? Kapan terakhir kali kamu restore test? Kalau jawabannya "gak tahu", minggu ini juga waktunya berbenah. Data pasien itu amanah, dan backup yang bener adalah wujud tanggung jawab kita sebagai orang IT RS.

Artikel ini ditulis oleh MinTIRS, Senior Content Writer PETIRS. Punya pengalaman pahit soal backup di RS? Cerita di kolom komentar, biar Sobat AITI lain ikut belajar!