HIK NVR Storage & Bandwidth Calculator Guide (2026)

A surveillance system is a data system. Cameras produce a continuous stream, the recorder writes it to disk, and the network carries it between the two. When a project fails, it usually fails on one of those three links: the disk fills faster than expected, the network saturates at shift change, or the recorder runs out of PoE budget two cameras short of the plan. This guide explains how to size a HIK NVR system from first principles, with working formulas, planning tables and a procurement checklist you can take to a project meeting.

The approach is deliberately conservative. Manufacturer datasheets list maximum and typical bitrates, but real scenes vary: a busy loading bay at noon is not the same as an empty corridor at 3 a.m. The goal here is not to predict the exact byte count of a Tuesday afternoon. It is to choose numbers with enough margin that the system behaves predictably across seasons, firmware updates and camera replacements.

1. Why storage and bandwidth planning decides project success

Most buyers start with the camera list. That is natural — cameras are the visible part of the system — but it puts the decision in the wrong order. The recorder, the drives and the network are sized by the cameras, and the cameras are constrained by the site. A 64-channel 8 MP design and a 8-channel 4 MP design can both be "correct", but only one of them fits the available rack space, the PoE switch and the retention policy.

Storage failures are slow and quiet. A drive that is too small does not fail on day one; it triggers overwrite earlier than planned, and the operator discovers the problem only when an incident from three weeks ago cannot be retrieved. Bandwidth failures are fast and loud: remote viewing stutters, recordings drop frames, and the client calls within hours. Both are avoidable with a short planning exercise before purchase.

There is also a commercial dimension. Surveillance projects are often quoted against a fixed budget, and storage is one of the few line items that can be adjusted without changing the camera count. That flexibility is useful, but it is also where projects get squeezed. The right sequence is to fix the retention requirement first, then compute storage, then choose the recorder and drives that meet it.

It helps to separate two questions that are often blended together. The first is capability: can the system capture the scenes the client needs at a usable quality? The second is endurance: can it keep doing so for the agreed retention period without operator intervention? A design that answers only the first question may look excellent on the day of commissioning and disappointing three months later. Storage and bandwidth planning is how the second question gets answered before the purchase order is signed.

2. How a HIK NVR handles incoming streams

An NVR receives one encoded stream per camera channel, decodes a subset for local display, and writes the encoded stream to disk. The crucial point is that the recorder usually stores the compressed stream, not a decoded frame sequence. That is why storage planning is really a bitrate exercise: the disk sees roughly the same number of bytes per second that the camera sends over the network, plus container and indexing overhead.

Many HIK cameras can send more than one stream. A main stream is used for recording at full resolution; a sub-stream is used for live preview on mobile devices or for low-bandwidth remote access. Some models add a third stream for specific analytics. Recording the main stream and viewing the sub-stream is a common configuration because it keeps both storage and remote bandwidth under control.

The recorder also affects what can be decoded locally. A 16-channel NVR may accept 16 incoming channels but only decode a smaller number simultaneously for HDMI output. This is a display limitation, not a recording limitation, but it matters for control rooms where operators expect a full wall of live images. Ask for the decoding capability separately from the channel count.

Codec support is the other major factor. H.265 (and its variants) reduces bitrate substantially compared with H.264 by analysing larger blocks and predicting motion more efficiently. The trade-off is compatibility: older clients, browsers and third-party VMS platforms may need H.264. Modern HIK recorders generally accept both, so the practical rule is to record H.265 where the whole chain supports it and fall back to H.264 where it does not.

Recording mode is the next decision. Continuous recording captures everything but consumes the full bitrate budget. Motion-triggered recording writes only when the camera detects activity, which can cut storage dramatically on quiet sites. The trade-off is pre-event context: a motion clip that starts at the moment of detection may miss the approach. Many recorders support pre-recording buffers, which keep a few seconds before the trigger in memory and write them with the clip. For evidence-critical installations, continuous recording remains the simplest and most defensible choice.

Some recorders also support dual recording or redundant recording, where the same stream is written to two drives or two recorders. This is not the same as RAID. RAID protects against a drive failure inside one recorder; dual recording protects against the loss of an entire recorder. For critical sites, the two approaches can be combined, but the storage cost doubles and should be included in the plan.

3. Bitrate fundamentals: resolution, codec, frame rate and scene

Bitrate is the number of bits per second used to represent the video. It rises with resolution, frame rate, scene complexity and motion, and it falls when a more efficient codec is used. For planning, it is enough to work with a typical value per resolution and codec, then add a safety margin.

The table below gives planning ranges for common surveillance resolutions under H.265 at 25 frames per second. These are engineering estimates for sizing exercises, not datasheet guarantees. Use the camera's actual configured bitrate where it is known, and treat these ranges as a starting point when the camera list is still being finalised.

Frame rate is often over-specified. A 25 fps stream is useful for fast motion and for capturing readable plates, but a warehouse aisle with slow forklift traffic may be adequately covered at 15 fps. Reducing frame rate from 25 to 15 fps typically cuts bitrate by 25–40% with little practical loss for many indoor scenes. The decision should come from the operational requirement, not from a default setting.

Scene complexity matters as much as resolution. A camera pointed at a static wall produces a very low bitrate because most blocks do not change. A camera covering a busy street produces a much higher bitrate because motion is constant. When you compare two sites with the same camera model, compare the scenes as well. This is why a pilot camera on the actual site is worth more than a spreadsheet full of datasheets.

Bitrate control mode changes how the stream behaves. Constant bitrate (CBR) holds the rate close to a target and is predictable for planning, but quality may drop in complex scenes. Variable bitrate (VBR) allows the rate to rise and fall with scene complexity, which usually improves quality at the same average but makes peak bandwidth harder to predict. For storage and network sizing, CBR is easier to model; for image quality, VBR is often preferred. A common compromise is VBR with a maximum bitrate cap, which bounds the peak while keeping the average efficient.

Key frames matter too. Compressed video is built from key frames (I-frames) and predicted frames. A longer group of pictures (GOP) reduces bitrate because fewer full frames are stored, but it makes seeking and recovery after packet loss slower. Surveillance systems often use a GOP of one to four seconds. When comparing cameras, check the GOP setting as well as the resolution and codec, because two cameras with the same nominal bitrate can produce noticeably different storage if their GOP policies differ.

Smart codecs add another layer. Some HIK cameras offer region-of-interest encoding, which allocates more bits to a selected area and fewer to the background, or adaptive bitrate control, which adjusts to network conditions. These features can reduce average storage, but they also make planning less predictable. For a fixed-retention project, it is safer to size on a constant bitrate assumption and treat smart-codec savings as headroom rather than as the plan.

4. Storage math: from bitrate to terabytes

The core formula is simple. Storage in bytes equals bitrate in bits per second multiplied by seconds, multiplied by the number of cameras, multiplied by retention days, divided by eight to convert bits to bytes. Convert to terabytes by dividing by one trillion for decimal terabytes, or by 1.0995 trillion for binary tebibytes. Recorders and drive vendors usually quote decimal capacities, so use decimal terabytes for planning and expect the operating system to report slightly less.

As a compact formula: TB = (Mbps × 86,400 × days × cameras) ÷ 8,000,000. The 86,400 is the number of seconds in a day. The 8,000,000 combines the bit-to-byte division by eight with the byte-to-decimal-terabyte division by one million.

Worked example: eight 4 MP cameras at 6 Mbps, retained for 30 days. Multiply 6 × 86,400 × 30 × 8 = 124,416,000. Divide by 8,000,000 to get 15.6 TB. Add 10% for container overhead and indexing, and plan for roughly 17 TB of usable capacity.

The same site at 60 days retention needs roughly 31 TB, and at 90 days roughly 47 TB. This linear relationship is the reason retention policy is the most powerful lever in the design. Doubling retention doubles storage; reducing camera bitrate by a third reduces storage by a third. Neither change requires buying different cameras.

Two practical notes. First, the numbers above assume continuous recording. Motion-triggered recording can reduce storage sharply on quiet sites, but it also means the system may miss the minutes before an event. For evidence-critical sites, continuous recording is usually the safer choice. Second, NVRs often reserve space for snapshots, logs and RAID parity. A RAID 5 array with four drives loses the capacity of one drive to parity; a RAID 6 array with six drives loses two. Include that in the usable-capacity calculation.

File system and recorder overhead are small but real. Indexing, thumbnails, logs and the recorder's own operating system consume space that is not available for video. A five to ten percent allowance is reasonable for most systems. On very large arrays, the file system may also reserve space for metadata. These percentages look trivial on a 4 TB system and become tens of terabytes on a 200 TB campus design, so apply them consistently at every scale.

Finally, plan for growth. A recorder purchased for 16 cameras today may be asked to handle 24 cameras in two years. If the chassis has spare bays and the drives can be added without rebuilding the array, expansion is straightforward. If not, the only option is a second recorder. Document the growth path at design time, because it is much cheaper to buy a slightly larger chassis than to replace a recorder mid-project.

5. Bandwidth math: the other half of the plan

Bandwidth is the aggregate bitrate that must move from the cameras to the recorder, and optionally from the recorder to remote clients. For the camera-to-recorder path, the load is the sum of the main-stream bitrates of all recording cameras, plus protocol overhead. A 32-camera system at 6 Mbps each needs about 192 Mbps of inbound capacity, and with 20% headroom the switch and recorder uplink should handle roughly 230 Mbps.

Many projects fail here because the PoE switch is chosen for port count and PoE budget, not for backplane capacity. A 24-port PoE switch may have a 1 Gbps uplink, which is shared with all camera traffic leaving the switch. If the recorder is on that uplink, the aggregate camera stream must fit within it. In practice, a 1 Gbps uplink is comfortable for most 32-camera 4 MP systems but tight for a 64-camera 8 MP system. In the latter case, use multiple uplinks, a higher-capacity switch, or distribute recorders closer to camera groups.

Remote viewing is a separate calculation. If operators view six sub-streams at 1 Mbps each, the outbound requirement from the recorder is about 6 Mbps plus overhead, which is usually within a business broadband connection. The risk is not the average; it is the peak when several users open high-resolution playback at once. For remote access, prefer sub-stream live view and restrict full-resolution export to scheduled sessions.

Quality of service helps. If the network carries voice, point-of-sale or building systems alongside video, put camera traffic on a dedicated VLAN and prioritise it. Video is tolerant of some delay but not of sustained loss; a congested uplink produces the familiar mosaic artefacts and dropped recordings. A modest managed switch with VLAN support is a better investment than a larger unmanaged switch without it.

Multicast is worth understanding for larger systems. When several clients view the same camera, unicast sends a separate copy to each viewer, multiplying bandwidth. Multicast sends one copy that multiple viewers can join. It requires switch support and careful configuration, but it can substantially reduce load on the recorder and uplink in control-room environments. For small systems, unicast is simpler and usually sufficient.

Remote access also has a security dimension. Exposing a recorder directly to the internet is poor practice. Prefer a VPN, a secured remote-access service, or a platform that brokers the connection without opening inbound ports. Use strong passwords, disable default accounts, keep firmware current and restrict remote viewing to the sub-stream where possible. These measures do not change the bandwidth math, but they determine whether the system remains available and trustworthy.

6. Drives, RAID and retention

Surveillance recorders write continuously. That workload is different from desktop use, where drives spend most of their time idle. Surveillance-grade drives such as WD Purple and Seagate SkyHawk are designed for 24/7 write cycles and are rated for a total workload in terabytes per year. Desktop drives may work initially, but their error recovery behaviour and endurance are not matched to continuous recording, and they are more likely to drop out of a RAID array.

RAID is common on larger NVRs. RAID 5 tolerates one drive failure and costs the capacity of one drive; RAID 6 tolerates two and costs two. For a 32-channel system with 60-day retention, the difference between RAID 5 and RAID 6 is a few drives and a meaningful amount of usable capacity. The decision should reflect how quickly a failed drive can be replaced and how critical the footage is. For a single-site retail system, RAID 5 on a four-bay recorder is often sufficient. For a campus or critical infrastructure, RAID 6 or a mirrored recorder is more appropriate.

Drive count has a physical limit. A four-bay NVR with 16 TB drives gives about 64 TB raw, minus parity. If the plan calls for 134 TB of usable capacity, a single four-bay recorder is not enough; the design needs a larger chassis or multiple recorders. Check the recorder's maximum supported drive size before ordering, because some models cap at 8 TB or 10 TB per bay even when larger drives exist.

Retention is also a policy question. Thirty days is common for retail and commercial sites. Sixty to ninety days is common where investigations may be delayed, such as logistics, healthcare and public infrastructure. Some regulated environments require longer. The practical approach is to agree retention in writing before the storage calculation, then size to that number and document the assumption.

Drive monitoring is part of the design. Most NVRs expose S.M.A.R.T. data and send alerts when a drive reports reallocated sectors or rising temperature. Enable notifications to email or a management platform so a failing drive is replaced before it drops out of the array. In RAID 5, a second failure during rebuild can lose the array; prompt replacement is not optional on critical systems.

Mixing drive models or capacities in one array is possible but usually unwise. The array is limited by the smallest drive and by the slowest member, and mixed firmware behaviour can complicate support. Buy identical drives from the same batch where possible, keep one cold spare on site, and record the installation date so warranty and replacement cycles are predictable.

7. PoE and power budget

PoE simplifies installation by carrying power and data on one cable, but it is a budget that must be added up. Each camera has a power draw that depends on its features: IR illumination, heater, motorised zoom and PTZ movement all increase consumption. A fixed 4 MP dome may draw 6–8 W, while a PTZ with IR and a heater may draw 20–30 W or more.

The switch or NVR PoE budget must exceed the sum of connected camera draws with margin. A 16-port PoE switch with a 120 W budget cannot power 16 PTZ cameras at 20 W each, even though it has 16 ports. Check both the per-port limit and the total budget. For PTZ-heavy designs, an external PoE injector or a higher-budget switch is often necessary.

Power also interacts with storage indirectly. A camera that restarts because of insufficient power may renegotiate its stream and produce gaps in the recording. Stable power is part of reliable storage. Use UPS protection on the recorder and core switch, and consider surge protection on outdoor runs.

Cable length and quality matter as well. PoE has a practical distance limit, and long outdoor runs are exposed to voltage drop and surge. Use the correct cable category, keep runs within the standard limit, and protect outdoor segments. A camera that browns out during a storm may not die immediately, but it can produce weeks of intermittent recordings that are difficult to diagnose after the fact.

8. Scenario planning: four common designs

Small retail. Eight 4 MP cameras, 30 days, continuous recording. Storage lands around 17 TB usable. A 16-channel NVR with four 8 TB surveillance drives in RAID 5 covers it with room to add cameras. A single 1 Gbps switch uplink is ample. This is the most common starter design and the easiest to get right.

Warehouse and logistics. Thirty-two 4 MP cameras, 30–60 days. Storage ranges from roughly 67 TB to 134 TB depending on retention. Expect a larger chassis, RAID 6, and careful attention to the switch uplink. Loading bays and yards are high-motion scenes, so bitrate assumptions should sit at the upper end of the range. A second recorder for redundancy is worth discussing.

Campus and multi-building. Sixty-four 8 MP cameras, 30 days. This is a network design as much as a camera design. Aggregate bitrate approaches 600 Mbps with headroom, so use multiple uplinks or fibre between buildings, and distribute recorders to keep traffic local. Storage exceeds 200 TB, which usually means a dedicated storage chassis or several recorders.

Remote and solar sites. Four cameras, 14 days, limited power. Storage is small, around 3 TB, and the constraint is energy rather than disk. Use low-power cameras, schedule recording around activity, and prefer local storage with periodic uploads where connectivity is intermittent. For solar deployments, confirm the panel and battery budget against the camera and recorder consumption before committing.

Mixed sites deserve a note. A single project may combine a warehouse, an office and a remote gate. Rather than forcing one design across all three, size each area independently and then decide whether they share a recorder. Sharing reduces equipment cost but concentrates risk and complicates bandwidth. Separate recorders per area often produce a simpler, more resilient design even when the total channel count would fit on one chassis.

9. Common mistakes and how to avoid them

Undersizing storage is the most common error. It usually comes from using a vendor's rough "one terabyte per camera per month" rule without checking bitrate. That rule is reasonable for 2 MP H.264 at low frame rates and badly wrong for 8 MP H.265 at 25 fps. Always compute from bitrate.

Ignoring peak bitrate is the second. Average bitrate may be 6 Mbps, but a windy day with moving foliage or a busy event can push a camera to twice that. Plan on the high side, or enable a bitrate cap on the camera and accept slightly lower quality during peaks.

Using desktop drives is the third. They are cheaper, and they may work for months, but they are not rated for continuous write and are more likely to fail under RAID rebuild stress. The cost difference is small relative to the recorder and the labour to replace a drive.

Forgetting the PoE budget is the fourth. A switch chosen for port count alone may leave the last four cameras unpowered. Add up watts, not ports.

Mismatching codec and client is the fifth. H.265 saves storage but may not play in an older browser or third-party platform. Confirm the playback chain before standardising on H.265.

Forgetting firmware and configuration drift is the sixth. A recorder installed with default settings may record at a higher bitrate than planned, or may not have retention set as expected. Commission with the planned bitrate, codec, frame rate and retention explicitly configured, and record the settings in the handover document.

Ignoring time synchronisation is the seventh. If cameras and the recorder disagree on time, incident review becomes difficult and exported clips may carry inconsistent timestamps. Use NTP on the recorder and let cameras sync from it. This costs nothing and prevents a surprising number of disputes.

10. Procurement checklist

The checklist below turns the calculations into a buying decision. Work through it in order, because each item constrains the next: the retention target drives storage, storage drives the drive count, drive count drives the chassis, and the chassis drives the network and power requirements.

• Agree retention days in writing before any storage calculation.
• List every camera with resolution, codec and planned bitrate.
• Compute storage with the formula, then add 10–20% overhead.
• Choose the NVR for channel count, decoding capability and maximum drive size.
• Select surveillance-grade drives and decide RAID level.
• Confirm PoE per-port and total budget against camera draw.
• Check the switch uplink against aggregate bitrate plus headroom.
• Plan remote viewing on sub-streams, not main streams.
• Include UPS protection for the recorder and core switch.
• Confirm time synchronisation (NTP) across recorder and cameras.
• Record the final bitrate, codec and retention settings in the handover document.
• Document assumptions so a future expansion can be sized consistently.

11. Project timeline

1. Site survey. Confirm camera positions, cable routes, power and network points.
2. Camera schedule. Fix models, resolution, codec and frame rate per position.
3. Bitrate assumptions. Use datasheet values where available, planning ranges otherwise.
4. Storage calculation. Apply the formula and add overhead.
5. Recorder selection. Match channels, decoding, drive bays and RAID support.
6. Network design. Size switches, uplinks, VLANs and PoE budgets.
7. Procurement. Order recorders, drives, cameras and network equipment together.
8. Installation and commissioning. Verify bitrates, retention and failover behaviour on site.
9. Post-installation review. Compare actual storage consumption with the plan and adjust.

12. FAQ

How much storage do I need per camera? It depends on bitrate and retention. At 6 Mbps and 30 days, one camera needs about 1.9 TB. At 10 Mbps, about 3.2 TB. Use the formula rather than a fixed rule.

Is H.265 always better than H.264? For storage and bandwidth, usually yes. For compatibility with older clients and third-party platforms, H.264 may still be necessary. Many recorders support both, so the choice can be made per camera.

Can I use desktop hard drives? They may work, but they are not rated for 24/7 write workloads. Surveillance-grade drives are the appropriate choice for continuous recording.

Do I need RAID? Not always. RAID protects against a single drive failure and is worthwhile on larger systems where downtime matters. Small systems with good backups of critical clips may not need it.

How many cameras can one NVR handle? Channel count is only one limit. Check decoding capability, incoming bandwidth and drive bays as well. A 32-channel recorder may accept 32 streams but decode far fewer for display.

What is the difference between main stream and sub-stream? The main stream is the full-quality recording stream. The sub-stream is a lower-bitrate copy used for live preview and remote viewing, which saves bandwidth.

How much bandwidth do remote viewers need? Plan on sub-stream bitrate per viewer, typically 0.5–1 Mbps, plus overhead. Avoid multiple simultaneous full-resolution playback sessions over a shared connection.

Should I record continuously or on motion? Continuous recording is simpler and captures context before and after an event. Motion recording saves storage on quiet sites but can miss the approach. Pre-recording buffers reduce that risk. Many projects use continuous recording for critical areas and motion for low-risk areas.

How do I estimate bandwidth for a new site? Multiply the planned main-stream bitrate by the number of recording cameras, add 20% headroom, and compare with the switch uplink and recorder inbound capacity. Treat remote viewers separately using sub-stream bitrates.

What retention should I choose? Thirty days suits most retail and commercial sites. Logistics, healthcare and public infrastructure often prefer 60–90 days. Agree the number with the client in writing before sizing storage.

Can I expand storage later? Often yes, if the recorder has free bays and supports larger drives. Confirm the maximum drive size and RAID expansion behaviour before purchase.

13. Glossary

• Bitrate: the number of bits per second used to encode a video stream.
• CBR / VBR: constant bitrate and variable bitrate; two ways of controlling stream size.
• Codec: the algorithm that compresses and decompresses video, such as H.264 or H.265.
• GOP: group of pictures; the interval between key frames in a compressed stream.
• I-frame: a complete key frame used as a reference by predicted frames.
• Multicast: one stream delivered to multiple viewers without duplication.
• NTP: network time protocol; keeps devices synchronised to a common clock.
• PoE: Power over Ethernet; carries power and data on one cable.
• RAID: redundant array of independent disks; protects data across multiple drives.
• Retention: how long recorded footage is kept before being overwritten.
• Sub-stream: a lower-resolution or lower-bitrate stream used for preview.
• TBW: terabytes written; a drive endurance rating.
• VLAN: a logically separated network segment used to isolate traffic.
• VMS: video management software used to view and manage recordings.
• ONVIF: an interoperability standard for IP-based security products.

14. Sources

• HIK official website — product documentation and technical specifications.
• ONVIF — interoperability profiles for IP video products.
• Western Digital — surveillance drive workload and endurance guidance.
• Seagate — surveillance drive specifications and workload ratings.