English
Deutsch
PolskiStorage and Bandwidth Engineering for Enterprise CCTV Networks
Part 1 of 2 in the series Video surveillance on your own hardware
Contents
Deploying high-density 4K IP camera networks requires rigorous mathematical sizing of bandwidth throughput and disk storage arrays. A single unoptimized 8-megapixel (4K) stream can easily consume 15 to 20 Mbps of continuous network bandwidth, rapidly congesting standard gigabit switches and exhausting enterprise storage arrays within days. Establishing a resilient CCTV infrastructure capable of maintaining redundant 30-day video retention without packet loss mandates advanced video codec tuning, dedicated VLAN isolation, and fault-tolerant RAID topologies engineered specifically for continuous 24/7 sequential write workloads.
1. Codec Optimization: H.265/HEVC & Smart Bitrate Control
Selecting the correct compression codec and bitrate control strategy is critical to reducing network load and storage ingestion rates:
- H.265 (HEVC) vs. H.264: Migrating from H.264 to H.265 reduces bitrate requirements by roughly 40% to 50% at identical perceptual image quality. For 4K streams at 15 frames per second (FPS), H.265 allows target bitrates to be lowered from 12 Mbps down to 6 Mbps.
- Smart Codecs (H.265+ / Zipstream): Vendor-specific dynamic Group of Pictures (GOP) algorithms increase intra-frame intervals during periods of static background scenes, dropping bitrate consumption by up to 70% without sacrificing detail when motion occurs.
- Variable Bitrate (VBR) with Caps: Constant Bitrate (CBR) wastes bandwidth during inactive night hours. Configuring VBR with an upper bitrate cap (e.g., maximum 8 Mbps per 4K stream) prevents sudden network spikes during complex, high-motion events.
2. Mathematical Storage Capacity Sizing
Calculating raw storage requirements requires applying a precise mathematical formula across all active camera feeds:
Storage (Gigabytes) = [Bitrate (Mbps) × 3600 seconds × 24 hours × Days] / (8 bits × 1000)For an enterprise installation of 16 cameras recording in 4K at an average VBR of 6 Mbps over a retention period of 30 days:
- Single Camera Daily Ingestion: (6 Mbps × 3600 × 24) / 8000 = 64.8 GB / day
- 16-Camera 30-Day Raw Demand: 64.8 GB × 16 × 30 = 31,104 GB (~31.10 TB)
- RAID & Formatting Overhead Buffer: Adding a mandatory 20% overhead buffer for filesystem structures and RAID parity requires a usable net capacity of at least 37.3 TB.
3. Step-by-Step Storage Array & Network Infrastructure Setup
To eliminate frame drops, stuttering recordings, and hardware wear, storage arrays and network switching backplanes must be provisioned according to strict engineering standards:
- Surveillance-Grade Hard Drive Selection: Conventional desktop hard drives fail rapidly under continuous 24/7 write cycles. Deploy only dedicated surveillance drives (e.g., WD Purple Pro or Seagate SkyHawk AI) equipped with AllFrame/ImagePerfect firmware and rotational vibration (RV) sensors.
- Fault-Tolerant RAID Topology: For arrays exceeding 24 TB, avoid RAID 5 due to long rebuild times and URE (Unrecoverable Read Error) risks. Implement RAID 6 (dual-drive parity) or RAID 10 (striped mirrors) across six 10 TB surveillance HDDs to ensure zero data loss during disk rebuilding.
- Network VLAN & MTU Optimization: Isolate all IP cameras within a dedicated, non-routed VLAN (e.g.,
VLAN 40 - Surveillance) to block broadcast storms from enterprise office networks. Ensure Power over Ethernet (PoE+) switches feature a non-blocking backplane switching capacity of at least 50 Gbps. - Jumbo Frames Configuration: Enable 9000-byte Jumbo Frames on switch ports connecting the NVR server and primary aggregation switches to reduce CPU packet-processing overhead by up to 80%.
4. Summary & Architectural Value
What this tutorial achieves: The design and deployment of a mathematically verified, high-capacity CCTV storage and bandwidth infrastructure capable of sustaining 30 days of redundant 4K video recording across enterprise camera networks.
Resulting value: Network congestion, dropped frames, and packet loss are eliminated through H.265+ codec tuning and dedicated VLAN isolation. Implementing fault-tolerant RAID 6/10 arrays with surveillance-grade drives guarantees zero data loss during hardware failures, ensures compliance with statutory 30-day evidence retention mandates, and prevents expensive storage over-provisioning.
Questions and answers
Are six 10 TB drives enough for the 37.3 TB, and how do RAID 6 and RAID 10 differ here?
With RAID 6, yes; with RAID 10, no. RAID 6 uses the capacity of two drives for parity and provides 40 TB from six 10 TB drives. RAID 10 mirrors every drive and provides only 30 TB from the same six, 7.3 TB less than the calculation requires; 37.3 TB takes eight drives, which then give 40 TB.
The two also behave differently when a drive fails:
- RAID 6 survives the failure of any two drives. During a rebuild, all remaining drives are read and the missing data is recalculated from the parity.
- RAID 10 survives the failure of one drive per mirror pair, but is lost as soon as both drives of the same pair fail. A rebuild only copies the partner drive, which is faster and puts no load on the other drives.
What matters most for recording is that the rebuild happens during operation: the cameras keep writing while the drives are read on top of that, and every hour of rebuilding is an hour with reduced redundancy. The extra work of dual parity on writes weighs less with the largely sequential writes of a recording than with random access.
Which bitrate belongs in the calculation, the average or the cap?
Both, but in different places. Storage is governed by the average, because the drives fill up with what arrives on average over days; that is why the article calculates with 6 Mbps. The network is governed by the cap, because peaks often come at all cameras at once: rain, snow or the switch to night mode at dusk affect every camera at the same time. Sixteen cameras with a cap of 8 Mbps add up to as much as 128 Mbps on the link to the NVR server, against 96 Mbps on average.
The average, however, is an assumption until it has been measured. If it turns out to be 8 rather than 6 Mbps in operation, the same storage lasts 22.5 days instead of 30. Most recorders then overwrite the oldest footage, and the error only becomes apparent when a recording from the beginning of the month is needed. After the first week of operation it is therefore worth checking how much storage a day actually takes up.
How much does recording only on motion save?
The share of time without motion, and that is hard to predict before operation. The formula assumes 24 hours a day; with motion recording the requirement falls in the same proportion, but foliage, rain or the headlights of passing cars can multiply the share with motion on individual days. The safer course is to size the storage for continuous recording and treat the savings as a reserve.
What needs attention when enabling Jumbo Frames?
That the frame size matches along the whole path: every switch port in between and the network cards at both ends have to accept frames of that size. A port with a smaller MTU drops larger frames without the sender learning about it. The treacherous part is that small packets get through, so connections can be established, and only the large transfers that follow hang.
Whether the whole path fits can be shown by a ping with the DF bit set, which forbids fragmentation, and a matching size, on Linux for example ping -M do -s 8972 to the target: 8972 bytes of payload plus 28 bytes of IP and ICMP headers make 9000. In any case, Jumbo Frames only bring a benefit between devices that send large frames themselves; all others keep sending at their own frame size.
Sources
Video surveillance on your own hardware
- Storage and Bandwidth Engineering for Enterprise CCTV Networks
- Intelligent Alarm Scenarios: Integrating Frigate AI Detection in Home Assistant
Related articles
