Menghitung Penyimpanan CCTV untuk Retensi 30 Hari

Untuk menyimpan rekaman CCTV selama 30 hari, hitung jumlah kamera, laju data video rata-rata (bitrate), dan lama perekaman. Gunakan ukuran data yang benar-benar ditulis, lalu tambah cadangan untuk lonjakan dan ruang kerja perekam. Contoh di artikel ini memakai kapasitas 35 hari; itu asumsi desain yang perlu diuji, bukan aturan untuk semua instalasi.

Selisih antara asumsi dan hasil pengukuran bisa membuat sistem CCTV gagal memenuhi janji retensi. Kekurangan itu mungkin baru terlihat ketika seseorang meminta rekaman dari tiga minggu sebelumnya.

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 lokasi 24 kamera, sensor 4 MP, H.265, 15 fps, rekam terus-menerus. Proposalnya menulis 3 Mbps per kamera dan retensi 30 hari. Berikut perubahan kebutuhan kapasitas setelah asumsi diperiksa:

Kebutuhan dalam proposal dan kapasitas kerja berbeda 72%. Rumus yang digunakan sama, tetapi nilai masukan telah diperiksa kembali.

Mengapa bitrate konfigurasi belum mewakili pemakaian nyata?

Nilai konfigurasi dapat menjadi batas atas, bukan rata-rata. Kamera dengan laju data variabel (variable bitrate) menyesuaikan kompresi dengan isi gambar. Data yang dihasilkan dipengaruhi jumlah detail dan gangguan gambar (noise) yang ditangkap sensor.

Contoh pengukuran Zipstream dari Axis menunjukkan pengurangan laju data yang berbeda-beda: 25% pada gambar terang dengan gerakan sesekali, 50% pada pandangan umum siang hari dengan gerakan kecil yang sering, 90% pada gambar gelap dengan banyak gangguan dan gerakan sesekali, serta 99,7% pada mode malam dengan gerakan sangat jarang (white paper Axis Zipstream, Juli 2026).

Ada dua akibat, dan arahnya berlawanan.

Pertama, menghitung dari angka maksimum membuat belanja disk kelebihan, kadang sampai dua kali lipat. Kedua — ini yang mahal — menghitung dari satu minggu yang sepi membuat 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.

Dokumen teknis yang sama mengingatkan bahwa memakai laju data tetap (constant bitrate, CBR) sebagai strategi penghematan penyimpanan tidak dianjurkan, karena kamera yang dipaksa menahan plafon CBR akan membuang detail forensik justru saat gambar memuat banyak gerakan. CBR memudahkan perkiraan ruang, tetapi hilangnya detail dapat menyulitkan investigasi.

Aturan praktisnya: jangan pernah menghitung dari kolom konfigurasi. Rekam lokasi aslinya tujuh hari penuh — kondisi gambar asli, pencahayaan asli, mode malam yang digunakan di lokasi — lalu ambil angka jumlah bita yang ditulis dari VMS dan bagi.

Berapa penghematan kapasitas dari H.265 atau AV1?

Penghematan bergantung pada codec awal dan kondisi gambar. Hasil uji yang dirujuk menunjukkan perbedaan lebih besar terhadap H.264 daripada terhadap H.265.

Axis mengukur AV1 terhadap keduanya di gambar pemantauan nyata: 18% sampai 33% lebih hemat dari H.264 tergantung kondisi gambar, tetapi hanya 0,04% sampai 5,8% lebih hemat dari H.265 (AV1 codec in video surveillance, Juni 2026). AV1 menawarkan penggunaan tanpa royalti (royalty-free), tetapi tidak otomatis memangkas kapasitas kelompok disk menjadi separuh.

Bedanya penting saat ada vendor menawarkan ganti kamera sebagai solusi storage. Jangan menganggap pindah H.264 ke H.265 selalu membagi kebutuhan disk menjadi dua. Ukur ulang kondisi gambar pada kualitas gambar yang sebanding. Dalam rentang hasil uji Axis tadi, penghematan H.265 ke AV1 relatif kecil; hasil di lokasi Anda tetap perlu diuji sebelum membeli kamera baru. Beli perangkat keras AV1 untuk urusan lisensi dan dukungan penguraian videonya. 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 perlu diperiksa dalam perencanaan pembelian:

Paritas dan satuan kapasitas. Delapan disk 8 TB memberikan 64 TB mentah. RAID 6 menyisakan kapasitas setara enam disk: 48 TB, atau sekitar 43,7 TiB. TB memakai basis desimal, TiB basis biner; perubahan tampilan satuan bukan kehilangan kapasitas karena format. Setelah contoh cadangan 10%, tersedia sekitar 43,2 TB atau 39,3 TiB, sebelum rincian overhead lain yang belum dihitung. Tulis satuannya di proposal agar kebutuhan 40 TB tidak dibandingkan dengan angka TiB.

Ruang tambahan untuk VMS. Basis data rekaman, metadata gerakan, kejadian analisis video, dan indeks gambar pratinjau tinggal di volume yang sama pada kebanyakan NVR kelas menengah. Kebanyakan VMS juga menahan sisa ruang kosong supaya volume tidak pernah ditulis sampai nol. Angka 10% pada contoh di atas merupakan cadangan ilustratif; periksa kebutuhan VMS dan sistem berkas yang dipakai.

Jeda penghapusan. Perekam dapat menghapus per blok dan menahan ruang kosong. Cadangan 15% pada contoh 30 hari memberi 34,5 hari, dibulatkan menjadi 35. Ini titik awal pengujian, bukan syarat universal. Retensi 30 hari berjalan tidak berubah hanya karena bulan kalender punya 31 hari.

Rekam hanya saat ada gerakan. Penghematan mode ini perlu diuji. Hasilnya dapat baik pada tangga darurat, tetapi kecil pada area bongkar muat, lobi, atau kamera yang mencakup 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?

Selain kapasitas, periksa beban kerja disk dan pemulihan setelah kegagalan.

Batas beban kerja tahunan disk. Disk untuk perekaman pemantauan memiliki batas beban kerja tahunan. 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 untuk 16 kamera pada 4 Mbps menulis sekitar 252 TB setahun: sekitar 40% di atas contoh rating 180 TB/tahun. Itu alasan memilih kelas disk lain atau membagi beban, bukan prediksi kapan disk akan mati. Periksa apakah rating model mencakup baca dan tulis. Pada RAID, hitung juga penulisan paritas, pemutaran rekaman, dan beban rekonstruksi data (rebuild); pembagian sederhana ke jumlah disk belum mewakili semua beban tersebut.

Salah satu disk gagal saat rekaman masih harus disimpan. Backblaze Drive Stats Q1 2026 mencatat tingkat kegagalan yang disetahunkan (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). Sebagai ilustrasi saja, bila peluang tahunan setiap disk dianggap 0,85% dan saling independen, peluang minimal satu kegagalan pada delapan disk adalah 1 − (1 − 0,0085)^8, sekitar 6,6%. Annualized failure rate Backblaze bukan peluang yang dapat langsung dipakai untuk semua disk CCTV. Umur, suhu, model, dan kegagalan bersama membuat risiko lokasi Anda berbeda.

Karena itu rekonstruksi data (rebuild) harus ikut dibicarakan waktu menghitung storage, bukan jadi kejutan belakangan. Perekaman tetap jalan selama rekonstruksi data (rebuild), array-nya dapat melambat dan perlindungannya berkurang selama proses. RAID 6 dengan satu disk gagal masih dapat menahan satu kegagalan disk lagi, dan disk kapasitas besar butuh waktu lama untuk pulih sambil menerima tulisan baru. Ini argumen yang sama dengan RAID bukan pencadangan, dipakai pada sistem yang seluruh tujuannya menyimpan data yang tidak bisa dibuat ulang.

Cara menghitung supaya angkanya tidak meleset

Gunakan enam langkah berikut. Pengukuran nyata dan lingkup retensi pada dua langkah awal menjadi dasar perhitungan selanjutnya.

1. Ukur, jangan menebak. Rekam lokasi aslinya tujuh hari melewati siklus siang-malam penuh, lalu baca jumlah bita yang ditulis per kamera dari VMS. Gunakan hari tersibuk sebagai masukan konservatif untuk kapasitas. Periksa apakah minggu itu mewakili lonjakan musiman atau acara.
2. Tulis target retensi sebagai pasal kontrak. Berapa hari, kamera yang mana, dan apakah rekamannya terus-menerus atau berbasis event. Janji "30 hari" tanpa batasan membuat cakupan kamera, mutu gambar, dan mode perekaman tidak jelas.
3. Uji cadangan kapasitas. Contoh retensi × 1,15 menghasilkan 34,5 hari, dibulatkan ke 35. Sesuaikan dengan pola penghapusan, lonjakan bitrate, dan batas ruang VMS yang terukur.
4. Cek beban per disk, termasuk baca, penulisan paritas, dan rekonstruksi data (rebuild). Cocokkan dengan spesifikasi model serta pengendali yang dipakai, dengan sisa kapasitas kerja.
5. Pasang retensi per kamera kalau VMS-nya mendukung. Kamera lobi dan kamera area kasir jarang butuh jendela yang sama. Retensi yang dibedakan dapat menghemat ruang bila kebutuhan bukti dan kebijakan retensinya memang berbeda.
6. Pantau retensi yang terkirim, bukan persentase disk. Pemakaian kelompok disk perekaman dapat tetap di 95%+ karena rekaman lama terus diganti. Persentase itu sendiri belum menunjukkan lama rekaman yang tersedia. Tanya VMS setiap hari: rekaman tertua yang masih ada per kamera, lalu kirim peringatan kalau jendela satu kamera turun di bawah target. Cek ini satu paket dengan pemantauan kesehatan kamera yang saya bahas di SNMP untuk pemantauan banyak kamera CCTV.

Waktu rekaman tertua per kamera menunjukkan retensi yang benar-benar tercapai. Perkiraan kapasitas tetap diperlukan, tetapi periksa hasil nyata ini melalui kueri terjadwal setiap hari.

Perencanaan penyimpanan perlu menghubungkan target kontrak, kapasitas terukur, dan pemantauan retensi. Dengan begitu, petugas dapat menangani kekurangan sebelum rekaman diperlukan.