How to Size Recording Storage for a 128-Camera Deployment

For a 128-camera site on 1080p H.265 at moderate bitrate with 90-day retention on RAID 6, expect to provision somewhere between 550 TB and 700 TB of physical disk, depending on scene complexity and the headroom you build in. That range is wide enough to be useless on its own, which is exactly why this calculation has to be done camera-by-camera and not estimated from a rule of thumb. The rest of this article walks the arithmetic an installer actually uses, and the working can be reproduced directly at /tools/nvr-storage-calculator . The base formula Every storage calculation for continuous recording reduces to the same conversion, whatever units the vendor datasheet uses: bitrate in megabits per second, converted to gigabytes per day, multiplied by camera count and retention days, then corrected for RAID overhead and filesystem reserve. The shortcut worth memorising: Daily GB per camera = Bitrate (Mbps) × 10.8 . This falls out of converting 1 Mbps into bytes over 24 hours: 1 Mbps × 86,400 seconds is 86,400 megabits, which is 10,800 megabytes at 8 bits to the byte, or 10.8 GB counting a gigabyte as 1,000 megabytes. Once you have daily GB per camera, the rest is multiplication: Raw TB = (Daily GB × Number of Cameras × Retention Days) ÷ 1,000 Physical disk capacity = (Raw TB ÷ RAID Efficiency) × 1.10, where the 1.10 accounts for filesystem overhead The one input that actually varies between sites is bitrate, and that is where most sizing errors originate, not in the arithmetic itself. Step 1: Get the bitrate right, per camera, not per resolution label Resolution alone tells you almost nothing about storage load. Codec and scene complexity matter more. Where possible, pull the actual configured bitrate from the camera or NVR menu rather than assuming a figure from a spec sheet — this is the single most accurate input available and it is sitting right there in the configuration screen. Typical ranges, for reference: 1080p H.264: 4–6 Mbps, roughly 43–65 GB/day, 1.3–2 TB/month per camera 1080p H.265: 2–3 Mbps, roughly 22–32 GB/day, 660 GB–1 TB/month per camera 4K H.264: 12–16 Mbps, roughly 130–170 GB/day, 4–5 TB/month per camera 4K H.265: 6–8 Mbps, roughly 65–86 GB/day, 2–2.6 TB/month per camera 4K H.265+ (smart encoding): 3–5 Mbps, roughly 32–54 GB/day, 1–1.6 TB/month per camera The codec jump from H.264 to H.265 roughly halves the storage requirement for the same visual quality, which is the single biggest lever available before you touch drive count or RAID level. Smart-encoding variants that recognise static background and reduce bitrate accordingly can cut another 30–50% on top of that, though the saving depends heavily on scene activity — a busy road junction will not behave like a quiet warehouse aisle. Motion-only recording is the other obvious lever: a camera recording only when motion is detected, at say 20% duty cycle, uses roughly a fifth of the storage of continuous recording. It is worth flagging early, though, because several of the retention mandates covered below require continuous recording specifically, which removes this option regardless of what the budget wants. Step 2: Choose the retention period against the actual mandate, not a guess Retention days is the second governing input, and for an Indian deployment it is rarely a free choice — it is usually set by whichever sector the site falls under. There is no single national CCTV retention law in India. Instead there is a patchwork of sector rules, court directions and institutional guidelines, and the applicable one has to be identified before the arithmetic means anything. Police stations and custodial premises The Supreme Court, in Paramvir Singh Saini v. Baljit Singh (2020), directed that CCTV recording at police stations and premises of central investigating agencies with the power of arrest and interrogation be preserved for 18 months, and specified that where available equipment cannot support 18 months, states and the central government must purchase the maximum retention capacity achievable, with a hard floor of not less than 1 year. Subsequent High Court orders, including from the Madras High Court in 2022, have reiterated this floor and criticised installations where footage is erased within 15 or 30 days. This direction is scoped specifically to police stations and interrogation-capable central agency offices — it should not be read as a blanket retention law for every CCTV installation in the country. Banking premises RBI guidance is commonly cited in the 90–180 day range depending on premises type, with figures for branches, ATMs, currency chests and cash-handling areas varying by source. Given the inconsistency between publicly cited figures, treat this as a working range to be confirmed against the current RBI master circular for the specific project rather than a single fixed number to design against. As a sizing reference point, a 16-channel 4MP H.265 setup recording continuously for 90 days works out to roughly 45–55 TB of raw storage before RAID and filesystem overhead — useful as a sanity check on your own numbers at similar channel counts. Other commonly cited sector minimums Standard commercial and retail premises: often sized to 30 days Hospitals and large commercial establishments: 60 days is a reasonable safe minimum Government, PSU and infrastructure sites: 90–180 days is common, and continuous recording (not motion-triggered) is frequently mandated, which matters directly for the arithmetic since it removes the motion-saving lever discussed earlier Jewellery and high-value retail: 60–90 days is recommended by industry bodies such as the Jewellers Vigilance Committee of India and the All India Gem and Jewellery Domestic Council, though this is a trade recommendation rather than a statutory mandate, and is nonetheless routinely written into tender BOQs for that sector For a 128-camera job, confirm the retention figure against the tender document or client mandate before running the calculator — it is the one input that cannot be estimated. Step 3: Account for RAID overhead honestly This is where installers most commonly lose 20–25% of capacity they thought they had, because the calculated "usable storage required" figure and the "drives to order" figure are not the same number. RAID efficiency is straightforward: RAID 5 gives you (N-1)/N of raw drive capacity, RAID 6 gives you (N-2)/N. A common and costly mistake is ordering drives to match the usable storage figure directly. Ordering 30 TB of drives against a 30 TB usable requirement on RAID 5 across a 4-bay NVR yields only 22.5 TB usable once parity overhead is applied — a shortfall of 25% against the target, discovered only after the array is built and the retention window starts clipping early. At 128 cameras, this is enterprise storage array territory, not a single desktop NVR, and the RAID level choice deserves more thought than it gets on smaller jobs: RAID 6 tolerates two simultaneous drive failures rather than one, which matters at scale because rebuild times on large-capacity surveillance drives run long, and a second failure during a RAID 5 rebuild is a real risk with many bays in the array. RAID 10 earns its place where write throughput from 128 simultaneous streams is the bottleneck rather than raw capacity, at the cost of a lower capacity yield than RAID 6. Whichever level is chosen, remember that usable drive capacity is always somewhat lower than the label figure once filesystem overhead and reserved space are accounted for, separate from whatever RAID takes. Step 4: Add headroom, deliberately, not as an afterthought Two separate buffers belong in the final number, and it is worth keeping them distinct rather than folding them into one vague margin: Filesystem and OS overhead: commonly 10–25% depending on how conservatively you want to size it. The three-step formula referenced earlier uses a 1.10 multiplier as a baseline. Event/burst headroom: unusual activity — an incident, a weather event, construction nearby — pushes bitrate well above baseline for the duration. Adding a 20% buffer across the whole calculation is common practice so the NVR does not quietly drop recording quality to stay within disk budget exactly when footage matters most. At 128 cameras, skipping this step is not a rounding error — it is tens of terabytes of missing headroom exactly when an incident review needs the footage to exist at full quality. Step 5: Match drive workload rating to the actual write load, not just capacity 128 cameras recording continuously is a sustained, 24/7 sequential write load, and the drive's workload rating — the TB per year it is warrantied to write continuously — is the spec that governs selection here, not raw capacity per drive. Mainstream surveillance drives are typically rated around 180 TB/year of continuous write. Higher-capacity tiers (8 TB and above, in some product lines) carry a 360 TB/year rating. Where analytics workloads add continuous read alongside the write (AI-based VMS analytics running against live streams), drives rated at 550 TB/year are the appropriate tier. Surveillance-tier drives also run at 5400 RPM deliberately, since this generates less heat under 24/7 operation, and firmware on these drives is tuned for sustained sequential writes rather than the mixed read/write pattern a desktop drive expects. A desktop drive is rated for 8–10 hours of daily operation; pressed into 24/7 surveillance duty it commonly develops bad sectors and fails within 6–18 months. At 128-camera scale, in a multi-bay rack array, rotational vibration sensors on the drives themselves become relevant too — a large populated array vibrates as a system, and drives without RV sensing degrade faster under that condition. Compliance layers that sit on top of the arithmetic Government and GeM tenders add a certification layer that is separate from the storage calculation and should not be confused with it. STQC test reports are routinely mandatory line items in GeM tender specifications for IP cameras and NVRs, alongside detailed BOQ fields for resolution, channel count, streaming capacity, IR range, storage capacity, port configuration and redundant power. This is a device certification and security-testing requirement, not a retention-days requirement — the two are governed by different clauses and should be tracked separately when preparing a tender response. Legacy integration also shows up in real tenders: it is not unusual for a VMS server specification to require compatibility with both the new cameras being proposed and an existing installed base, which a purely greenfield storage calculation will not account for. Running the numbers for your own site The arithmetic above scales cleanly from a handful of cameras to 128 and beyond, but every input — bitrate, retention days, RAID level, drive tier — is site-specific enough that a worked example in an article is illustrative at best. The NVR storage calculator runs this exact sequence — bitrate to daily footprint, retention multiplier, RAID efficiency, filesystem and burst headroom — against your actual camera count and mix, and is the faster way to get to a bill of quantities you can defend against a tender BOQ. For guidance on matching drive tiers and array configurations to a specific deployment, the products and solutions pages cover the surveillance server and storage array options this sizing feeds into, and our team can review a BOQ before it goes out the door.