Hitung Storage CCTV: 30 Hari yang Tidak Genap

Hitung Storage CCTV: 30 Hari yang Tidak Genap

Hitung storage CCTV cuma satu rumus: jumlah kamera × bitrate rata-rata × detik per hari × jumlah hari retensi ÷ 8. Rumusnya gampang. Inputnya yang bikin sistem meleset — bitrate rata-rata bukan angka di halaman konfigurasi kamera, dan janji retensi 30 hari butuh disk seukuran 35 hari supaya benar-benar dapat 30 hari.

Jarak antara dua angka itu tempat sebagian besar proyek CCTV melanggar janjinya sendiri. Tidak ada yang sadar, karena retensi baru diaudit di hari seseorang minta rekaman tiga minggu lalu.

Rumus retensinya seperti apa?

Hitung dalam bit, konversi sekali di akhir:

GB per kamera per hari = bitrate_Mbps × 86.400 ÷ 8 ÷ 1.000 TB untuk satu site = GB/hari × jumlah kamera × hari retensi ÷ 1.000

Kamera yang mengalir stabil di 4 Mbps menulis 43,2 GB setiap hari. Angka itu layak dihafal. Dengan satu angka itu Anda bisa menaksir kebutuhan satu gedung sambil jalan survei: 4 Mbps ≈ 43 GB/hari ≈ 1,3 TB/bulan per kamera.

Ambil contoh site 24 kamera, sensor 4 MP, H.265, 15 fps, rekam terus-menerus. Proposalnya menulis 3 Mbps per kamera dan retensi 30 hari. Ini harga dari tiap lapis kejujuran:

Angka proposal dan angka kerja beda 72%. Rumusnya sama persis. Yang berubah cuma inputnya.

Kenapa bitrate rata-rata bukan angka di konfigurasi kamera?

Karena kolom itu batas atas, bukan rata-rata. Kamera sekarang jalan dengan variable bitrate plus kompresi yang menyesuaikan isi gambar. Keluarannya mengikuti seberapa banyak detail — dan seberapa banyak noise — yang benar-benar ditangkap sensor.

Axis menerbitkan contoh terukur untuk Zipstream yang rentangnya hampir dua orde besaran: scene terang dengan gerakan sesekali turun 25%, overview siang dengan gerakan kecil yang sering turun 50%, scene gelap penuh noise dengan gerakan sesekali turun 90%, dan scene night-mode dengan gerakan sangat jarang turun 99,7% (white paper Axis Zipstream, Juli 2026).

Ada dua akibat, dan arahnya berlawanan.

Pertama, menghitung dari angka maksimum bikin belanja disk kelebihan, kadang sampai dua kali lipat. Kedua — ini yang mahal — menghitung dari satu minggu yang sepi bikin disk yang dibeli kurang, karena minggu sepi bukan minggu yang Anda butuhkan. Noise menaikkan bitrate. Hujan menaikkan bitrate. Parkiran dengan lampu IR dan serangga yang lewat jam dua pagi menaikkan bitrate semalaman, tiap malam, di semua kamera yang menghadap luar.

White paper yang sama tegas soal jalan pintas yang paling menggoda: memakai constant bitrate sebagai strategi hemat storage tidak dianjurkan, karena kamera yang dipaksa menahan plafon CBR akan membuang detail forensik justru saat scene-nya ramai. Dengan CBR, kebutuhan disk memang gampang ditebak — hasil investigasinya yang tidak.

Aturan praktisnya: jangan pernah menghitung dari kolom konfigurasi. Rekam site aslinya tujuh hari penuh — scene asli, pencahayaan asli, night mode asli — lalu ambil angka bytes written dari VMS dan bagi.

Pindah ke H.265 atau AV1 nambah hari?

Kalau masih di H.264, iya, dan untungnya besar. Kalau sudah di H.265, codec berikutnya hampir tidak memberi apa-apa.

Axis mengukur AV1 terhadap keduanya di scene surveillance nyata: 18% sampai 33% lebih hemat dari H.264 tergantung scene, tapi cuma 0,04% sampai 5,8% lebih hemat dari H.265 (AV1 codec in video surveillance, Juni 2026). Nilai jual AV1 di pasar ini royalty-free, bukan array yang tiba-tiba jadi setengahnya.

Bedanya penting saat ada vendor menawarkan ganti kamera sebagai solusi storage. Pindah dari H.264 ke H.265 di 24 kamera memang mengubah kebutuhan 31 TB jadi sekitar 16 TB. Pindah dari H.265 ke AV1 mengubah 31 TB jadi sekitar 30 TB — selisih pembulatan dibanding harga kamera barunya. Beli hardware AV1 untuk urusan lisensi dan dukungan decode-nya. Hitung disknya seolah codec-nya tidak berubah.

Hari-hari yang hilang itu ke mana?

Kapasitas di brosur dan retensi yang benar-benar dikirim dipisahkan empat potongan. Keempatnya tidak kelihatan di purchase order:

Parity dan format. Disk yang dijual 8 TB tampil sekitar 7,28 TiB, dan RAID 6 delapan bay — susunan disk dengan cadangan ganda, dua disk boleh mati tanpa kehilangan data — mengembalikan kapasitas enam disk, bukan delapan. Tidak ada yang aneh di sini. Yang jadi masalah: proposal yang menulis "storage 48 TB" untuk kebutuhan 40 TB sedang menyebut angka mentah, sementara array-nya mengirim sekitar 43 TB sebelum VMS ambil jatahnya.

Overhead VMS. Database rekaman, metadata motion, event analytics, dan index thumbnail tinggal di volume yang sama pada kebanyakan NVR kelas menengah. Kebanyakan VMS juga menahan sisa ruang kosong supaya volume tidak pernah ditulis sampai nol. Anggarkan 10%.

Jeda penghapusan. Recorder menghapus menurut jadwalnya sendiri, per blok, biasanya telat. Sistem yang kapasitasnya pas 30 hari menghabiskan sebagian tiap bulan di angka 29 koma sekian. Desain 35 hari kalau kontraknya bilang 30.

Rekam hanya saat ada gerakan. Penghematan paling dilebih-lebihkan di industri ini. Cocok untuk tangga darurat. Tidak cocok untuk loading bay, lobi, atau kamera mana pun yang scene-nya kena jalan raya. Dan saat penghematan itu tidak terjadi, gagalnya diam-diam: disk penuh lebih cepat, ujung retensi tertimpa tanpa peringatan. Kalau merekam berbasis gerakan, hitung dari hari tersibuk yang masuk akal, bukan dari hari rata-rata.

Apa yang rusak duluan sebelum disk penuh?

Dua hal, dan dua-duanya biasanya tidak masuk desain.

Rating beban tulis disknya. Disk khusus surveillance punya jatah tulis per tahun. Seri Seagate SkyHawk dispesifikasikan 180 TB/tahun pada duty cycle 20% (datasheet SkyHawk). Ubah jadi bitrate, angkanya langsung bisa dipakai di lapangan: 180 TB/tahun setara sekitar 45 Mbps tulis terus-menerus, atau kira-kira sebelas kamera di 4 Mbps.

NVR satu disk yang menanggung 16 kamera di 4 Mbps menulis 252 TB setahun. Itu 40% di atas ratingnya, terus-menerus, seumur hidup kotak itu. Disknya tidak akan mati sesuai jadwal — ia mati lebih cepat, dan matinya di bulan saat scene-nya lagi ramai. Beban yang sama dibagi ke array delapan disk membuat tiap disk menulis sekitar 47 TB/tahun, jauh di dalam spesifikasi. Lebar array itu keputusan keawetan, bukan cuma keputusan kapasitas.

Array kehilangan anggota di tengah masa retensi. Backblaze Drive Stats Q1 2026 mencatat annualized failure rate seluruh disknya di 1,24%, dan disk 20 TB ke atas di 0,85% dari 86.000 unit lebih (Backblaze, Q1 2026). Per disk, itu angka bagus. Digabung di array delapan disk, peluang minimal satu disk mati dalam setahun jadi sekitar 6,6% — kira-kira satu dari lima belas array, tiap tahun, di data center ber-AC dengan staf jaga. Ruang panel di rooftop gedung Jakarta bukan tempat seperti itu.

Karena itu rebuild harus ikut dibicarakan waktu menghitung storage, bukan jadi kejutan belakangan. Perekaman tetap jalan selama rebuild, array-nya lebih lambat dan tanpa proteksi selama proses, dan disk kapasitas besar butuh waktu lama untuk pulih sambil menerima tulisan baru. Ini argumen yang sama dengan RAID bukan backup, dipakai pada sistem yang seluruh tujuannya menyimpan data yang tidak bisa dibuat ulang.

Cara menghitung supaya angkanya tidak meleset

Enam langkah, berurutan. Langkah satu dan dua yang paling sering dilewat, dan justru dua langkah itu yang menentukan sisanya jadi hitungan atau karangan.

1. Ukur, jangan menebak. Rekam site aslinya tujuh hari melewati siklus siang-malam penuh, lalu baca bytes written per kamera dari VMS. Pakai hari tersibuk sebagai rata-rata kerja, bukan nilai tengahnya.
2. Tulis target retensi sebagai pasal kontrak. Berapa hari, kamera yang mana, dan apakah rekamannya terus-menerus atau berbasis event. "30 hari" tanpa batasan berarti semua kamera di frame rate penuh, dan begitulah nanti diauditnya.
3. Desain di retensi × 1,15. Kapasitas 35 hari untuk janji 30 hari. Ini menyerap jeda overwrite, bulan 31 hari, dan kenaikan bitrate musiman tanpa perlu pengajuan pembelian baru.
4. Cek rating beban tulis per disk, bukan per array. Total Mbps ÷ jumlah disk data, dikonversi ke TB/tahun, harus duduk di dalam spesifikasi dengan sisa ruang.
5. Pasang retensi per kamera kalau VMS-nya mendukung. Kamera lobi dan kamera area kasir jarang butuh jendela yang sama. Retensi yang dibedakan itu satu-satunya penghematan storage yang tidak mengurangi nilai forensik.
6. Pantau retensi yang terkirim, bukan persentase disk. Pemakaian disk di array surveillance memang duduk di 95%+ selamanya — angka itu tidak memberi tahu apa pun. Tanya VMS setiap hari: rekaman tertua yang masih ada per kamera, lalu bunyikan alert kalau jendela satu kamera turun di bawah target. Cek ini satu paket dengan pemantauan kesehatan kamera yang saya bahas di SNMP untuk fleet CCTV.

Poin terakhir itu inti seluruh disiplinnya, dan cuma butuh satu metrik. Semua angka lain di artikel ini ramalan; rekaman tertua per kamera itu pengukuran. Dia satu-satunya angka yang menjawab pertanyaan yang jadi alasan sistemnya dibangun, dan biayanya cuma satu query terjadwal sehari.

Menghitung storage dengan benar bukan soal beli disk lebih banyak. Ini soal jarak antara yang dijanjikan sistem dan yang benar-benar dikirimnya jadi angka yang ada penjaganya — sebelum hari rekaman itu dibutuhkan, bukan pada harinya.