CCTV Storage Calculator: How Many TB for N Cameras x 45 Days (India)
Storage is just bitrate x time, and the arithmetic is fixed: 1 Mbps of continuous video = 10.8 GB per day per camera. A realistic Indian factory floor at 4MP H.265, ~4 Mbps continuous, needs roughly 43 GB per camera per day — so 16 cameras for 45 days is about 31 TB of raw disk, and 32 cameras for 90 days about 124 TB. This page gives you the formula, a GB/day table by resolution and codec, ready TB tables for 8/16/32 cameras, and the assumptions that make or break the estimate.
Most CCTV projects are sized by a vendor typing camera count into a web calculator and reading off a number. That number is right for exactly one set of assumptions — a bitrate, a codec, a frame rate, a retention window — and wrong the moment any of them change on your floor. Below is the same math done in the open, so you can size disk from your own numbers instead of a guess, and see where the estimate quietly runs low.
Key points
- The core constant is fixed: 1 Mbps of continuous recording = 10.8 GB/day per camera (1 Mbps x 86,400 s/day / 8 bits/byte / 1,000 MB/GB). Every honest calculator uses it (bitrate-to-storage math).
- Resolution and codec set the bitrate. 2MP H.265 ~2 Mbps (~22 GB/day); 4MP H.265 ~3–5 Mbps (~32–54 GB/day); 4K/8MP H.265 ~6–10 Mbps (~65–108 GB/day). H.264 roughly doubles all of these.
- Then it is pure multiplication: GB/day per camera x number of cameras x retention days / 1000 = raw TB.
- A mid-size default: 16 cameras, 4MP H.265, 45-day continuous retention lands near 31 TB raw; scale linearly for your count and window.
- Add real-world headroom: ~10–20% for busy scenes and bitrate spikes, RAID parity costs a whole drive, and an "8 TB" drive shows only ~7.3 TB usable (TB-vs-TiB).
- Fix your retention window before your camera count — it is the multiplier the retention rules and your customer audits actually decide.
The formula, in three steps
Every storage estimate is the same chain. Do it once and you never need a black-box calculator again.
Step 1 — Bitrate to GB per day. A stream's bitrate (in Mbps) is the only input that matters for size. Convert it to disk per day:
GB/day = bitrate (Mbps) x 10.8
The 10.8 is not a fudge factor. One megabit per second, running for all 86,400 seconds in a day, is 86,400 megabits; divide by 8 to get megabytes, then by 1,000 to get gigabytes, and you land on 10.8 GB. So a camera holding a steady 4 Mbps writes ~43.2 GB every day.
Step 2 — One camera to the whole fleet, over the whole window. Storage is linear in both camera count and retention days, so:
Raw TB = (GB/day per camera x number of cameras x retention days) / 1000
Step 3 — Raw to disk you actually buy. Raw TB is the footage. The disk you purchase is larger, for three separate reasons covered in assumptions below: scene headroom, RAID parity, and the TB-vs-TiB gap. A practical rule: buy ~15–25% more than your raw number, then round up to whole drives.
That is the entire method. The only judgement call is Step 1 — what bitrate your cameras actually hold — and that is set by resolution and codec.
GB per day per camera, by resolution and codec
This is the lookup table for Step 1. Figures are for continuous 24/7 recording at ~15 fps on a moderately busy scene, the common factory baseline. H.265 (HEVC) delivers roughly the same picture as H.264 at about half the bitrate, which is why it is the default for storage. Bitrate bands align with vendor recommended-bitrate guidance (Hikvision recommended bit rates, PDF).
| Resolution | Codec | Typical bitrate | GB/day per camera |
|---|---|---|---|
| 2MP / 1080p | H.265 | ~2 Mbps | ~22 GB |
| 2MP / 1080p | H.264 | ~4 Mbps | ~43 GB |
| 4MP | H.265 | ~3–5 Mbps | ~32–54 GB |
| 4MP | H.264 | ~6–8 Mbps | ~65–86 GB |
| 5MP | H.265 | ~4–6 Mbps | ~43–65 GB |
| 5MP | H.264 | ~8–10 Mbps | ~86–108 GB |
| 8MP / 4K | H.265 | ~6–10 Mbps | ~65–108 GB |
| 8MP / 4K | H.264 | ~12–16 Mbps | ~130–173 GB |
Full frame rate (25–30 fps) can run 1.5–2x these numbers, so a full-rate fleet lands at the top of each band or above. A quick sanity path: read the actual bitrate off one of your own cameras' recorder page and multiply by 10.8 — it beats any table.
The single biggest lever here is the codec. Switching a 4MP fleet from H.264 to H.265 roughly halves the disk bill for the same picture — confirm both your cameras and your recorder support H.265/H.265+, because a mismatch silently falls back to H.264 and doubles your estimate.
TB tables: 8, 16 and 32 cameras x 30 / 45 / 90 days
Now Step 2, worked out. These are raw TB (footage only) — add headroom from Step 3 before buying. Two profiles bracket most Indian factory builds; if your fleet sits between them, interpolate, or just run your own per-camera GB/day through the formula.
Profile A — 2MP / 1080p, H.265, ~2 Mbps (~22 GB/day/cam). Overview and general-area cameras.
| Cameras | 30 days | 45 days | 90 days |
|---|---|---|---|
| 8 | ~5 TB | ~8 TB | ~16 TB |
| 16 | ~10 TB | ~16 TB | ~31 TB |
| 32 | ~21 TB | ~31 TB | ~62 TB |
Profile B — 4MP, H.265, ~4 Mbps (~43 GB/day/cam). The common "want to read a face or a label" default.
| Cameras | 30 days | 45 days | 90 days |
|---|---|---|---|
| 8 | ~10 TB | ~16 TB | ~31 TB |
| 16 | ~21 TB | ~31 TB | ~62 TB |
| 32 | ~41 TB | ~62 TB | ~124 TB |
Two things fall straight out of the tables. First, doubling the resolution roughly doubles the disk — Profile B is 2x Profile A across the board, because bitrate doubled. Choosing H.264 instead of H.265 has the same doubling effect. Second, retention is a straight multiplier: 90 days is exactly 3x thirty days, 45 days exactly 1.5x. There is no efficiency to be found in a longer window — every extra day costs the same GB it did on day one.
A worked read of one cell: 16 cameras, Profile B, 45 days = 43.2 GB/day x 16 x 45 / 1000 ≈ 31 TB raw. Add ~20% headroom and RAID and you are buying on the order of 40 TB of drives — say six 8 TB surveillance disks with parity, which also clears the drive-bay question before you spec the recorder.
The retention window decides more than the camera count
Notice that moving one 8-camera 4MP build from 30 to 90 days (10 TB → 31 TB) adds more disk than adding eight more cameras at 30 days would. The retention window, not the camera count, is usually the number that turns a camera project into a storage project — so fix it first.
There is no single legal retention figure for general factory CCTV in India, so 30 days is the common default; but sector norms and customers override it — pharma and food audits often want 90 days, and some security norms cite 180. Balance that against data-protection expectations not to keep worker video longer than needed. The full picture is in how long a factory must keep CCTV footage in India. Because a 90- or 180-day all-local build multiplies your drive count, this is also exactly where the NVR-vs-cloud VMS decision gets made: keep 30 days hot on the local recorder and push the long tail to cheaper cold storage.
The assumptions generic calculators hide
A calculator gives one number with total confidence. Here is what that number quietly assumes, and where a real factory floor breaks it.
- VBR, not CBR. Almost all modern cameras record variable bitrate — the figure you set is a ceiling, and the average sits below it on quiet scenes and pins to it on busy ones. Sizing on the peak over-provisions; sizing on the brochure average under-provisions. Size on a realistic continuous average with headroom, and monitor the recorder's actual disk-fill rate in the first week.
- The scene is the variable nobody quotes. Bitrate tracks motion and detail. A still storeroom holds well under its ceiling; a conveyor line, a busy gate, forklifts and flashing stack-lights keep most of the frame changing and push toward the top of the band. Welding arcs spike bitrate outright. A "busy" factory floor is a high-bitrate scene — budget accordingly.
- Smart codec (H.265+) saves less here than the brochure says. Scene-adaptive encoding is quoted as a 30–40% saving because it spends bytes only on changing pixels. On a factory floor most of the frame is moving, so that saving largely collapses. Budget close to the raw H.265 bitrate, not the smart-codec number.
- Frame rate is a hidden 2x. The tables assume ~15 fps. Recording everything at full 25–30 fps can 1.5–2x the disk. Most floors do not need full rate for general coverage; reserve it for the few cameras that count discrete parts (see why counting needs full-rate feeds).
- RAID parity costs a whole drive. Redundancy is not free: RAID-5 sacrifices one drive's worth of capacity to parity, so 3x8 TB in RAID-5 gives ~16 TB usable, not 24. Single-disk/JBOD recorders keep all the capacity but lose everything on that disk if it fails.
- TB on the box is not TB on the label. Operating systems count in binary (TiB) while drives are sold in decimal (TB), so an "8 TB" drive reports ~7.3 TB usable — a ~7–8% haircut across the whole array before any footage lands.
Stack these and the honest rule is: take your raw TB from the tables, add ~15–25% for scene and headroom, add for RAID if you want redundancy, then round up to whole drives. That is the number to actually buy.
Where this fits: disk is downstream of placement
Storage math assumes you already know how many cameras go where, at what resolution — and that placement question is where projects most often go wrong, both on coverage and on the PoE power budget the same install needs. Get the camera count and resolution mix wrong and every number on this page is wrong with it.
This is the gap Mama closes: record a short phone walkthrough of the floor, and it reads the space — zones, sightlines, the hazards that need coverage — then returns a floor plan plus a camera-placement plan. From that you get the exact channel count and resolution mix, so your storage math starts from real numbers instead of a guess. For a full interactive calculator with per-camera profiles, a reference like cctvcalculator.net is a reasonable cross-check against the arithmetic above.
FAQ
How many TB do I need for 16 cameras for 45 days? At 4MP H.265, ~4 Mbps continuous (~43 GB/day per camera), 16 cameras for 45 days is about 31 TB raw. Drop to 2MP H.265 and it roughly halves to ~16 TB; record at full 25–30 fps or in H.264 and it roughly doubles. Add ~15–25% headroom plus any RAID parity before you buy drives.
What is the CCTV storage formula? Two steps. GB/day per camera = bitrate in Mbps x 10.8. Then raw TB = GB/day x number of cameras x retention days / 1000. The 10.8 comes from one megabit per second running for a full day (86,400 s), converted to bytes and gigabytes.
How much storage per camera per day? It depends entirely on bitrate. As a rule of thumb: 2MP H.265 ~22 GB/day, 4MP H.265 ~32–54 GB/day, 4K H.265 ~65–108 GB/day. H.264 roughly doubles each. Full frame rate and busy scenes push toward the top of every band.
Does H.265 really halve my storage versus H.264? Roughly, for the same picture quality — that is the whole point of HEVC, and it is the single biggest lever on your disk bill. But both your cameras and your recorder must support H.265; a mismatch silently falls back to H.264 and doubles your estimate. Don't over-count the extra H.265+ "smart" saving on a busy floor, where moving machinery erodes it.
Why is the vendor's storage number always lower than mine? Because calculators default to optimistic assumptions: a low CBR-style bitrate, a static scene, full smart-codec savings, no RAID and no TB-vs-TiB haircut. A busy factory floor at variable bitrate with redundancy needs more. Size on a realistic average with headroom, then verify against the recorder's actual disk-fill rate in the first week.
Should I store locally (NVR) or in the cloud for this much footage? For a single site, a local NVR with surveillance-rated drives is almost always cheaper over 3–5 years, and it needs no upload bandwidth. Cloud adds off-site safety but needs sustained upload most Indian plants lack. Most mid-size plants run hybrid — the full trade-off is in NVR vs cloud VMS for factory video storage.