Thirty days of CCTV footage is a storage requirement, not a camera-count specification. To size it, define which streams will actually be recorded, their average recorded bitrate, the recording schedule and the capacity available to those recordings. Then verify the result against the exact NVR and drive configuration.
A recorder described as “16-channel” can accept a particular number of camera inputs; that label does not establish how many days of footage its hard disk will hold. In the example below, sixteen streams averaging 4Mbps need 20.736TB for 30 days of continuous video alone. A one-bay recorder with a documented 14TB-per-drive ceiling cannot meet that particular requirement with its internal disk.
This guide separates manufacturer specifications, our calculations and proposed acceptance checks. The 30-day target and all example bitrates are assumptions for planning, not legal advice, measured Hector Weyl performance or a universal recommended setting.
1. Write a retention requirement that can be checked
Start with the footage the operator needs to retrieve. “Keep everything for a month” leaves important questions open: does every camera record continuously, does audio count, and must each camera retain the same period? Resolve those questions before selecting disk capacity.
Use calendar days consistently. Thirty days is 720 hours; a calendar month can contain a different number of days. If the requirement varies by area, calculate each camera group separately and add the resulting storage demands.
| Input | What to specify | Evidence to retain |
|---|---|---|
| Recorded streams | Camera count, stream selection and audio | Channel list and recording configuration |
| Recorded rate | Expected average bitrate for each group | Assumption initially; measured bytes later |
| Schedule | Continuous, timed or event-triggered | Schedule and trigger/pre/post settings |
| Retention and pool | Required days and usable recording capacity | Approved requirement and recorder storage view |
A mixed project might require continuous entrance recording and event-triggered recording elsewhere. Keep those groups separate in the worksheet. A single average for the whole building can conceal a camera that reaches its overwrite point much earlier than the others.
2. Calculate 30-day storage from bitrate
For continuous recording, using decimal units:
Video storage (TB) = total average video bitrate (Mbps) × days × 0.0108.
The conversion is direct: 1Mbps equals 1,000,000 bits per second. Divide by eight to obtain bytes, multiply by 86,400 seconds per day, then divide by 1,000,000,000,000 bytes per TB. One continuous 1Mbps stream therefore generates 0.0108TB, or 10.8GB, per day.
For sixteen cameras each averaging 4Mbps, the total is 64Mbps. That produces 691.2GB per day and 64 × 30 × 0.0108 = 20.736TB over 30 days. These figures cover the assumed video payload only.
| Assumed cameras | Average video rate each | Total rate | Video for 30 days, 24/7 |
|---|---|---|---|
| 4 | 4Mbps | 16Mbps | 5.184TB |
| 8 | 4Mbps | 32Mbps | 10.368TB |
| 16 | 4Mbps | 64Mbps | 20.736TB |
| 16 | 8Mbps | 128Mbps | 41.472TB |
No row specifies the bitrate a particular resolution must use. Choose image quality for the actual task, then measure the resulting recording load. Audio, additional recorded streams and other stored data require their own allowance; the table is not a complete bill of storage.
For mixed groups, add the rates before applying the conversion when their schedules match. Eight streams averaging 4Mbps plus eight averaging 2Mbps total 48Mbps, giving 15.552TB of continuous video for 30 days. This is another hypothetical example. If their schedules differ, calculate each group with its own recording duration instead; averaging together unlike schedules can hide the actual requirement.
3. Use the recorded rate, not a convenient label
Confirm which stream the NVR stores. A low-bandwidth preview on a phone is not evidence that the recorder saves that same stream. Equally, recording an additional stream adds another data source to the storage calculation. Inspect the recording settings rather than inferring them from live-view appearance.
Axis explains in its March 2023 Bitrate control for IP video white paper that VBR storage demand can change with scene activity. Its section 6.2, page 11, describes a bitrate increase when scene complexity rises; section 6.3 also distinguishes actual consumption from a maximum limit. These are explanations of Axis behavior, not proof of identical controls in a Hector Weyl model. Read the manufacturer source.
For your project, label each estimate: a configured ceiling, an assumed planning average or a measured recording average. Those values serve different purposes. A quiet daytime sample may omit conditions the project specifically needs to capture, so include representative busy periods and night recordings in the proposed measurement plan.
A codec name is also insufficient. H.265 support does not establish a fixed percentage saving for your scenes. Recheck image usefulness and recorded bytes after changing encoding settings. Do not reduce the bitrate solely to make a spreadsheet fit if the resulting recording fails the agreed viewing task.
4. A real 16-channel NVR shows the storage constraint
The Hector Weyl HW-NVR-N2116H-4K provides a concrete example. Its technical specification identifies 16 camera inputs on page 2. The HDD table on page 3 lists one SATA interface and a maximum capacity of 14TB for each drive. The current product description agrees on those storage entries, checked on 11 November 2026.
| Documented item | Specification | What it establishes |
|---|---|---|
| Camera inputs, page 2 | 16CH | Input count, not retention duration |
| SATA, page 3 | 1 | One internal SATA drive position |
| Maximum capacity, page 3 | 14TB for each drive | Documented nominal per-drive ceiling |
| Our assumed video demand | 20.736TB | Exceeds that ceiling before other demands |
This is a sizing decision, not a claim that the recorder is unsuitable for every 16-camera installation. Different recording rates, schedules or retention requirements produce different results. However, for the stated sixteen-camera, 4Mbps, continuous 30-day example, a compliant storage design needs to change.
Revisit the recording requirement or select a recorder/storage arrangement with sufficient verified capacity. Confirm the exact drive model, firmware support and complete recording configuration before ordering. A multi-bay label alone does not prove that the intended disks, storage mode or workload are supported. The 14TB limit is not a promise that a disk is included or currently available.
5. Compare demand with the usable recording pool
A drive label describes nominal capacity. The recorder's usable recording pool can differ because of formatting, system allocation, storage configuration and space reserved for other data. On systems that support redundancy, the selected layout also matters. Do not assume a RAID mode exists merely because a recorder has several bays.
Keep the units aligned. Decimal TB uses 1012 bytes; binary TiB uses 240 bytes. A different displayed number may reflect a different unit rather than missing bytes. Formatting and other allocations are separate issues. Seagate's storage calculator notes both the decimal capacity convention and the effect of formatting and other functions. See its inputs and capacity notes.
As a separate hypothetical calculation, if 12TB is actually available to the example video, 64Mbps consumes 0.6912TB daily. Estimated retention is 12 ÷ 0.6912 = 17.36 days. The 12TB value is an illustration, not a measurement of the reference NVR.
Avoid treating any universal “add 20%” rule as a manufacturer requirement. Document the project's allowance for rate uncertainty, additional data and planned cameras, then check that allowance against the actual available pool.
6. Treat event recording as a measured schedule
If a stream records for exactly eight hours each day, its continuous-recording video demand scales by 8/24. Under the sixteen-camera, 4Mbps assumption, that gives 6.912TB over 30 calendar days. It also leaves sixteen hours each day outside that recording schedule; the lower storage figure does not preserve the same coverage.
Event recording needs more care. A count of motion alerts is not a recorded-time percentage. Triggers can overlap, and pre-event or post-event intervals can extend stored footage. Continuous recording may also remain enabled alongside event tagging, so an “event” marker does not necessarily mean an event-only file.
Read the actual schedule and supported trigger settings for the chosen equipment. Collect recorded bytes over a representative interval and inspect the saved clips. Treat any assumed activity fraction as provisional until that evidence exists. If continuous evidence is required, obtain approval before replacing it with event-only coverage.
7. Verify bytes, playback and the oldest required footage
Use commissioning to test the assumptions. Save the stream configuration, schedule, disk allocation and timestamps with the calculation. Measure recording growth over a known interval; network traffic alone may include data that is never stored. If the system has begun overwriting, remaining free space alone cannot show how many bytes have been written.
| Check | Normal evidence | Exception | Next action |
|---|---|---|---|
| Recording load | Bytes and interval identified | Only a brief live-rate reading | Measure representative recording growth |
| Image usefulness | Required task visible in saved clips | Quality lost after rate reduction | Revise encoding or storage design |
| Capacity | Allocated pool and units recorded | Only the drive label is known | Read actual recorder allocation |
| Retention | Required oldest footage plays per camera | Gaps or early overwrite | Investigate schedule, rate and allocation |
An early measurement supports a forecast; it cannot prove that 30 days of footage already exist. Once the retention window has elapsed, check the oldest required recordings on every required channel and play representative clips. A date visible on a timeline is weaker evidence than usable recorded footage.
Record the verification time, recorder time zone and the oldest successfully played clip for each channel. Distinguish an intentionally unrecorded interval from a fault or an overwrite. Also note any protected footage or separate allocation that affects the available pool, if the configuration uses it. This makes the acceptance record specific enough to investigate later, rather than reducing it to a screenshot of one disk-capacity number.
Repeat the review after adding cameras or changing stream, schedule or storage settings. Keep the original assumptions and the revised measurements together so that a retention shortfall can be traced to a changed input.
8. Put the retention decision into the purchase brief
Give the supplier a recording requirement that can be evaluated: exact camera and NVR models, channel groups, selected streams, provisional or measured rates, schedules, retention days and required usable capacity. Request written confirmation of the drive configuration and any unresolved limits.
Keep the acceptance criteria beside that equipment list. The proposed tests should cover saved-image usefulness, recording load and eventual retention, with a named decision owner for any exception. This prevents a storage estimate from becoming an unsupported promise when it moves from design notes into a quotation.
For a Hector Weyl procurement discussion, send the recording brief with the model list. Hector Weyl MOQ is 100 units. Capacity estimates in this article do not confirm prices, disk inclusion, inventory or compatibility for an unreviewed configuration.
9. Frequently asked questions
How much storage do 16 CCTV cameras need for 30 days?
At an assumed average of 4Mbps each, recording continuously, video alone requires 20.736TB. Change the bitrate, schedule or camera count and the answer changes.
How long does 1TB of CCTV storage last?
For one continuous 4Mbps video stream, a hypothetical 1TB allocated entirely to that video gives about 23.15 days. Additional data and capacity allocations reduce that example's available pool.
Does H.265 guarantee twice the retention?
No fixed multiplier is established here. Compare actual recorded bytes and useful image quality in the intended configuration before relying on a saving.
Can a 16-channel NVR hold 30 days automatically?
No. Channel count describes inputs. Retention depends on recording load and usable storage, subject to the exact recorder's limits.
Can motion recording guarantee a particular saving?
Not from an alert count alone. Verify the schedule, stored intervals and actual bytes, including pre-event and post-event recording where configured.
Is a 14TB drive enough for eight cameras?
Eight continuous 4Mbps streams need 10.368TB of video for 30 days. Check the available recording pool, additional data and supported drive configuration before accepting the design.
Does this guide set a legal retention period?
No. Thirty days is an example project target. Establish the applicable requirement separately and use that period in the calculation.
10. Sources and calculation scope
Hector Weyl: HW-NVR-N2116H-4K technical specification, page 2 (16CH input) and page 3 (HDD table: one SATA, 14TB per drive), Rev 001.001, copyright 2024. Cross-checked with the current model page on 11 November 2026. Other performance entries are outside this example.
Axis Communications: Bitrate control for IP video, March 2023, sections 4 and 6.2–6.3, pages 7–8 and 11. Used for rate-control context; Axis-specific features are not attributed to Hector Weyl.
Seagate: Video Storage Calculator for Surveillance, accessed 11 November 2026, camera requirements and capacity notes. Its assumptions and product recommendations are not adopted as specifications for this system.
Author calculations: decimal units, explicitly assumed average video rates and schedules. Figures exclude unquantified audio, extra streams and storage overhead. No field measurements or completed installation results are represented.
Share:
2.8mm vs 3.6mm CCTV Lens: Start with Target Width