Camera Bandwidth, Storage and Retention Design
Video retention cannot be sized reliably from camera count alone. Resolution, frame rate, codec, scene activity, recording schedule, analytics, multiple streams and redundancy all affect network and storage requirements.
Select the complete system, not one headline feature
Match devices, software, licensing, infrastructure, retention, integrations and support to the operating requirement before finalizing the design.
Build the camera-stream inventory
For each camera record resolution, codec, frame rate, quality, expected bitrate, primary and secondary streams, audio, analytics and schedule. Classify scenes by activity, lighting and noise. Confirm whether policy requires continuous recording or permits event-based operation.
The stream inventory becomes the requirements document for this project. Retention policy, who reviews footage, which scenes carry evidentiary weight and who administers the recorders all need owners before bitrate math starts. A camera count alone does not tell you what capacity, availability or review access the client actually needs.
- Resolution, codec and frame rate
- Scene activity and lighting
- Continuous/event schedule
- Primary and secondary streams
Calculate network and storage load
Calculate average and peak aggregate bitrate by switch, uplink, recorder and WAN path. Convert recording load into retention storage, then account for RAID, reserve, database and spare growth. Include playback, export, mobile and failover traffic rather than treating recording as the only network use.
Carry those numbers into the physical build: switch and uplink capacity, PoE budget per closet, recorder drive bays, rack power and cooling, and the WAN path that export traffic will cross. Confirm that the recorder model, drive support and license tier match the calculated load before purchase orders go out.
- Average and peak bitrate
- Switch/uplink headroom
- Raw versus usable storage
- Playback and export traffic
| Input | Affects | Validate with |
|---|---|---|
| Stream bitrate | Network and storage | Camera/VMS measurement |
| Recording schedule | Retention and evidence gaps | Policy and event tests |
| Usable storage | Achievable retention | Array and VMS status |
| Failure design | Availability and recovery | Planned scenario test |
Design resilience and evidence access
Define what happens when a drive, recorder, uplink or site connection fails. RAID, edge storage, secondary recording and server failover protect different conditions. Establish export format, watermark or hash needs, time accuracy, investigator access and legal-hold handling with the client.
Failover only helps when someone is watching for it. Assign named accounts for investigator export, restrict who can change retention or delete clips, and name the person who receives drive and recording-gap alerts. Schedule recorder updates against release notes and a tested recovery path so a firmware change does not cost archived video.
- RAID, edge and failover roles
- Time and audit controls
- Export and investigation workflow
- Failure notification
Measure and adjust after commissioning
After installation, measure representative day/night bitrates and storage forecasts. Verify oldest available video, event recording, gaps, health alerts and export time. Adjust only through approved policy and document the final assumptions so future camera additions can be evaluated consistently.
Close the project with measured numbers rather than design estimates: retention depth per camera group, observed peak bitrate, export timing, alert delivery and the behavior seen during a simulated network or drive loss. Hand over the storage worksheet, license records, credential handling instructions and any camera left as a documented exception.
- Measured bitrate sample
- Oldest-video verification
- Health and gap testing
- Growth and addition model
How we plan and deliver the work
The final design depends on site conditions, existing systems, client policies and the selected manufacturer or platform.
Inventory streams
List every camera with its resolution, frame rate, codec and recording schedule, including secondary streams sent to other systems.
Model bit rates
Estimate per-camera bit rates from scene activity and compression behavior, then total them by switch, uplink and recorder.
Size retention
Convert the modeled bit rates into daily and full-retention capacity, adding headroom for growth, redundancy and archive exports.
Measure and tune
Once recording begins, compare actual bit rates and disk consumption against the model and adjust quality or schedules.
Information to gather before design
Retention math depends on how each camera actually records, so stream settings and scene conditions collected up front reduce the risk of undersized disks and uplinks that run out of headroom.
- Camera count by resolution and codec
- Frame rate and recording schedule per zone
- Required retention days by area
- Scene activity and lighting conditions
- Switch uplink and recorder network paths
Frequently asked questions
These are common planning questions. A site-specific answer should be confirmed during discovery and design.
Can storage be sized only from megapixels?
No. Codec, frame rate, quality, activity and recording mode also change bitrate.
Does motion recording always meet evidence requirements?
Only if policy allows it and event detection is validated for the scene.
Is RAID a backup?
No. RAID helps with certain drive failures but does not protect every loss scenario.
When should capacity be recalculated?
After commissioning and whenever streams, retention, analytics or camera counts change.
Manufacturer software, firmware and technical files remain on the manufacturer’s official website. We do not mirror firmware files locally.
Size video storage and bandwidth for your site
The first pass is a bit-rate model, not a quote: camera list with resolutions, frame rates and codecs, retention days by area, and the switch and recorder paths those streams travel. Hardware gets selected after the numbers are on paper.