Kalkulator Kebutuhan Storage Database & Backup

Mengapa perlu dihitung sejak awal

Disk penuh adalah salah satu penyebab downtime yang paling bisa dicegah. Ketika disk server database habis, aplikasi berhenti menyimpan transaksi, backup gagal, dan pemulihannya sering memakan waktu berjam-jam. Menghitung kebutuhan storage sejak tahap perencanaan membantu Anda memilih spesifikasi server dan menyusun anggaran yang realistis bersama klien.

Rumus yang dipakai

Database per tahun = baris per hari × ukuran per baris × hari operasional × (1 + overhead)
Lampiran per tahun = MB per hari × hari operasional
Ruang backup = jumlah salinan × ukuran data × (1 − kompresi)

Overhead mewakili ruang untuk indeks, log transaksi, dan ruang kosong di dalam file database. Angka 20–50% cukup umum, tergantung jumlah indeks dan mesin databasenya.

Contoh: aplikasi klinik dengan hasil lab PDF

Sebuah aplikasi mencatat sekitar 20.000 baris data baru per hari dari pendaftaran, rekam medis, resep, dan billing, dengan rata-rata 1 KB per baris dan overhead 30%. Selain itu ada 200 MB file lampiran per hari, berupa hasil lab dan scan dokumen.

• Database: 20.000 × 1 KB × 365 × 1,3 ≈ 9,1 GB per tahun
• Lampiran: 200 MB × 365 ≈ 71,3 GB per tahun
• Setelah 5 tahun: database ≈ 45,3 GB, lampiran ≈ 356,4 GB, total ≈ 401,7 GB

Terlihat bahwa file lampiran jauh lebih besar daripada database. Ini pola yang sangat umum di aplikasi kesehatan, dan sering terlupakan saat memilih ukuran disk.

Skema retensi backup

Skema yang umum dipakai adalah menyimpan backup harian selama seminggu, mingguan selama sebulan, dan bulanan selama setahun. Totalnya 7 + 4 + 12 = 23 salinan. Jika semuanya berupa backup penuh, kebutuhan ruangnya besar sekali:

• Semua ikut backup penuh: 23 × 401,7 GB × 40% ≈ 3,6 TB.
• Database penuh, lampiran inkremental: 23 × 45,3 GB × 40% + 356,4 GB ≈ 772,8 GB.

File lampiran jarang berubah setelah disimpan, dan format seperti JPG atau PDF sudah terkompresi. Karena itu lampiran lebih efisien di-backup secara inkremental (hanya file baru yang disalin) menggunakan alat seperti rsync, restic, atau fitur versioning di object storage.

Aturan 3-2-1

Simpan minimal 3 salinan data, di 2 media berbeda, dan 1 salinan di lokasi lain (off-site atau cloud). Backup yang berada di server yang sama dengan database tidak akan menolong ketika server itu rusak atau terkena ransomware. Yang tidak kalah penting, uji pemulihan (restore) secara berkala. Backup yang tidak pernah diuji belum bisa disebut backup.

Khusus rekam medis elektronik

Permenkes No. 24 Tahun 2022 tentang Rekam Medis mengatur bahwa rekam medis elektronik disimpan paling singkat 25 tahun sejak tanggal kunjungan terakhir pasien. Artinya, perencanaan storage untuk sistem rekam medis sebaiknya memikirkan arsip jangka panjang, bukan hanya 5 tahun ke depan.

Praktik backup dan monitoring lainnya dibahas di artikel DevOps untuk tim kecil.

Terakhir diperbarui 24 September 2026