How to calculate video surveillance storage for 60 days

Storage for 60 days is calculated from each camera's bitrate and actual recording time, not from the megapixel count on the box. Resolution, codec, and frame rate help produce an initial assumption, but you should approve the estimate only after measuring streams in comparable daytime and nighttime scenes.

This job commonly goes wrong twice. First, someone multiplies the camera count by a generic "Full HD" storage figure, even though an entrance, a parking lot, and an empty corridor compress differently. Then they call the result the array capacity, forgetting RAID, system overhead, free-space headroom, and higher nighttime bitrate. The spreadsheet promises exactly 60 days, while the recorder starts deleting footage after 43 or 51 days.

A proper calculation produces three separate results: how many terabytes of video will accumulate in 60 days, what aggregate and peak bandwidth the recording server must accept, and how much physical capacity must be installed after losses and reserves. These figures are related, but they are not interchangeable. A disk can fit the archive yet fail to handle many concurrent write streams, while the network can accept the cameras by day and drop packets when nighttime noise or widespread motion raises their output.

Calculate from measured bitrate, not megapixels

Bitrate shows how much data a camera actually produces each second, so it belongs in both the capacity and bandwidth calculations. Two 1920x1080 cameras running at the same 25 frames per second can differ severalfold in average throughput: one watches a quiet warehouse under steady light, while the other sees foliage, rain, headlights, and a stream of people.

Resolution, frame rate, shutter speed, noise level, scene complexity, wide dynamic range, codec, compression profile, GOP length, and bitrate-control mode all affect throughput. A table that says "2 MP equals 2 Mbit/s" is acceptable for an early estimate, but not for buying disks. It conceals the deviations that consume your headroom.

Every camera in the design schedule needs at least two figures: average bitrate over a representative period and the observed peak. Use the average for capacity and the peak for the network, controller, disk interfaces, and recording server. If the VMS shows only a current rate, capture it automatically at least once per minute and retain a daily series. Better still, obtain the 95th or 99th percentile alongside the maximum. A random one-second spike should not size the whole system, but you cannot ignore a sustained evening peak.

Measure the primary recording stream, not the stream an operator opens in a viewing grid. A camera may have separate profiles for the archive, live view, mobile clients, and analytics. Add only the streams that actually cross each network segment instead of summing every profile indiscriminately. Count all transmitted streams on the camera-to-server path, but count only those written by the VMS in the disk path.

Check the units. If an interface reports 4 Mbit/s, that is megabits, while disk capacity is stated in bytes. Dividing by eight converts bits to bytes. Missing this conversion creates an eightfold error, and I have seen it in otherwise meticulous specifications.

One formula connects bitrate, retention, and capacity

For a continuous stream, capacity is simply bitrate multiplied by time. In the decimal units used on disk labels, one camera creates about 10.8 GB per day for every 1 Mbit/s:

ГБ/сутки = битрейт_Мбит_с × 86 400 / 8 / 1 000
ТБ/60_суток = битрейт_Мбит_с × 86 400 × 60 / 8 / 1 000 000
ТБ/60_суток = битрейт_Мбит_с × 0,648

A camera averaging 4 Mbit/s will record about 2.592 TB in 60 days. Ten such cameras will produce 25.92 TB of raw video. That is not yet the array size because it excludes audio, metadata, file overhead, RAID, and free space.

For cameras with different profiles, calculate each group first and then add the results:

V60 = Σ(число_камер_i × средний_битрейт_i × доля_записи_i × 0,648)

доля_записи equals 1 for round-the-clock recording. It equals 0.5 for a schedule that records 12 hours per day. For event recording, it is the fraction of time during which the VMS actually writes the primary stream, including pre-recording and post-recording. A value of 0.2 means roughly 4.8 recorded hours on an average day, not that motion occupied exactly 20 percent of every hour.

Add other data streams to the raw video. Audio at 64 Kbit/s is barely visible beside one 8 Mbit/s video stream, but across hundreds of channels and a long retention period it can occupy terabytes. Analytics metadata, search indexes, the event database, and thumbnails depend on the VMS. If the supplier has no documented allowance, assign a measured percentage after the pilot or use a separate fixed volume. Do not hide these items inside a vague "reliability factor."

I keep the calculation in separate stages that anyone can audit: raw video, additional data, capacity reserve, usable RAID capacity, and physical capacity. When every adjustment is folded into a single 1.4 multiplier, nobody remembers six months later what it contained. Separate rows let you revise one assumption without reconstructing the whole design from guesses.

Resolution and codec only provide a starting point

Resolution does not directly set bitrate, and a codec does not promise the same saving on every scene. H.265 generally carries a comparable image at a lower rate than H.264, but the outcome depends on the encoder implementation, settings, and frame content. An older decoder, mobile client, or analytics module may limit H.265 support, so you cannot count the saving until the complete playback and export path has been tested.

Axis's AV1 codec paper gives a useful but non-universal set of scenes. In simultaneous tests from the same camera, AV1 bitrate was close to H.265 and H.264 was higher, while the results still varied noticeably between daytime city, nighttime city, and traffic scenes. The practical conclusion is straightforward: compare codecs on the same device, with the same scene and the same required level of detail. Do not carry a promotional percentage from someone else's clip into your estimate.

Ranges are acceptable in the initial schedule if they are clearly labeled as assumptions. For example, a quiet 1080p camera at 15 frames per second using H.265 might begin with an estimate of 1.5 to 3 Mbit/s, a busy 4 MP camera at 20 frames per second with 3 to 6 Mbit/s, and a detailed 4K scene with 12 to 16 Mbit/s. These are not standards. They only establish an order of magnitude before the pilot and identify the parts of the design that need especially careful measurement.

Frame rate must follow the surveillance task. A calm corridor often works at 12 to 15 frames per second, while a checkout, fast traffic, or an industrial operation may require 25. Cutting the rate everywhere to save disks is dangerous because the required action can disappear between frames. Define what the operator must distinguish, then choose the lowest rate that preserves it.

GOP length affects compression efficiency as well as seeking, packet-loss behavior, and export. A long GOP reduces the share of complete I-frames but makes later frames depend on the reference frame for longer. Axis guidance explicitly lists a longer GOP as one way to lower throughput while also requiring verification that the image still serves the surveillance purpose. I would not accept a long GOP solely because it produces an attractive average bitrate. Scrub the recording, export a segment, and check recovery after a brief network interruption.

Nighttime noise often breaks a daytime estimate. Automatic gain turns dark areas into constantly changing grain that the codec has to describe. Correct lighting, shutter settings, noise reduction, and masks over irrelevant areas can help, but test every change against faces, license plates, and any other required detail. An archive that lasts 60 days but cannot answer the investigation's question is wasting storage.

Continuous and motion recording require different calculations

Continuous recording gives predictable retention, while event recording saves space only where the activity ratio has been measured. You cannot apply "30 percent motion" to every camera. A staffed entrance, an always-busy road, trees in the wind, and a locked server room produce very different event timelines.

For event recording, measure the actual duration of retained clips rather than the time a person is present in the image. Pre-recording adds seconds before each event, post-recording extends every clip, and nearby events can merge into an uninterrupted file. Five brief passages in one minute with 20 seconds of post-recording can turn that minute into almost continuous footage. The detector's trigger count will not reveal this.

Use a VMS report covering two ordinary weeks and separate periods of unusual demand, such as the beginning of a school term, a goods delivery, snowfall, a lighting change, maintenance, or a public event. For each camera, divide the total duration of saved clips by calendar time. If the archive is already running, you can compare the daily increase in occupied capacity, but first exclude exports, manually locked footage, and unrelated data on the volume.

A hybrid mode is often better than pure motion recording. The primary stream is retained on an event, while a low-bitrate or low-frame-rate stream records continuously. This keeps context when the detector misses the start of an event and still preserves much of the saving. Calculate the two parts separately:

V = V_фоновый_поток × 100% времени + V_основной_поток × доля событий

Do not apply an activity multiplier to a stream whose bitrate already responds to the scene without checking what the metric means. VBR itself lowers the average on an empty view and raises it when motion occurs. If the average bitrate covers a full day, it already contains the real activity pattern. Multiplying by 0.3 again is valid only if the camera sends that stream to the VMS continuously but the VMS writes it 30 percent of the time. Otherwise you count the saving twice.

For mandatory retention and disputed incidents, I size capacity with the highest observed recording ratio rather than the average from a quiet week. If the site must guarantee 60 days, one unusually busy month must not shorten the archive. Check the deletion policy as well. Some VMS products delete the oldest video at a free-space threshold, others reserve capacity by camera, and others hold marked footage outside the normal cycle.

Peak bandwidth matters more than the daily average

Choose the server and network for concurrent demand because a daily average hides short periods when every camera increases its output. A lighting transition, rain, snow, a crowd, moving foliage, or infrared illumination can affect a whole camera group at once.

The recording server's incoming bandwidth is the sum of all streams it receives. Add protocol overhead and headroom:

B_ingest = Σ(пиковый_битрейт_камеры × число_камер) × 1,2

The 1.2 multiplier is not a law. It is an explicit 20 percent design reserve. If the network has separate segments, repeat the calculation for every uplink, switch, and server interface. You cannot take the site-wide total and assume that each link can automatically carry it. One gigabit uplink from a remote building is a common bottleneck.

Calculate outbound bandwidth separately. Simultaneous live viewing, archive playback, export, replication, and backup all read from the server. Four operators viewing grids of 16 cameras do not always create 64 new streams. The VMS may distribute secondary streams or multicast, or it may open a separate unicast stream for each client. Confirm this behavior in the actual architecture.

Divide megabits by eight to convert stream rate into sequential disk writes. An aggregate 600 Mbit/s is about 75 MB/s before overhead. That sounds modest for a modern array, but video recording consists of many simultaneous streams while playback, RAID rebuild, array scrubbing, and export create competing work. The maximum transfer rate of one empty disk does not describe that condition.

Axis bitrate-control documentation distinguishes VBR from MBR. VBR retains quality by letting the stream rise on a complex scene. MBR caps the rate, but an aggressive cap can reduce quality at the exact moment an active event occurs. Do not choose the limit from available bandwidth alone. Record a test scene with motion, rain, or generated visual noise and inspect the detail at the capped rate.

A useful acceptance criterion is simple: during an hour of the agreed peak scene, no network interface, controller, or disk volume should remain at its sustained ceiling, and the VMS should report no dropped frames or write queues. A 30 percent daily average does not excuse one-minute gaps when the needed incident happens during that minute.

RAID does not replace a usable-capacity calculation

RAID improves availability after a disk failure, but it is not a backup and does not preserve all nominal capacity. Usable space depends on RAID level, disk count and size, the file system, controller reserves, and VMS rules.

For equal-sized disks, a rough estimate is:

RAID 5: полезно ≈ (N - 1) × размер диска
RAID 6: полезно ≈ (N - 2) × размер диска
RAID 10: полезно ≈ N × размер диска / 2

These formulas provide an upper bound before formatting and system overhead. An eight-drive set with 12 TB disks leaves about 72 TB in RAID 6 and about 48 TB in RAID 10. The operating system may report a smaller number in TiB because one TiB is 2^40 bytes while a disk vendor defines one TB as 10^12 bytes. That is a unit difference, not missing data.

Do not design a volume to remain 100 percent full. The VMS, file system, and maintenance operations need free space, and actual bitrate never matches the estimate perfectly. An operating limit of 80 to 85 percent of usable capacity is often sensible, but take the exact value from the VMS and storage documentation. If the system starts deleting old video at 90 percent, then 90 percent, not the complete volume, determines retention.

Read the physical-capacity formula from right to left:

требуемая_полезная_емкость = (видео + аудио + метаданные) × резерв_роста / допустимое_заполнение

Suppose 60 days of data consume 70 TB, the design allows 20 percent for growth and uncertainty, and the volume may be filled to 85 percent. You need 70 × 1.2 / 0.85 = 98.82 TB of usable capacity. Only then do you select a RAID configuration. Eight 16 TB drives in RAID 6 yield about 96 TB before formatting, so they do not qualify even though the labels total 128 TB.

Decide separately what happens during a failure. While rebuilding, the array reads every surviving disk and continues to accept video. Test write performance and retention in degraded mode. A hot spare starts recovery sooner but adds no usable capacity. A second server or an off-room replica protects against enclosure or controller failure, administrator error, and a physical incident, none of which a single RAID can handle.

Select disks by annual workload, bays, and recovery

For a continuous archive, choose disks designed for constant multi-stream recording and the actual annual workload. A "surveillance" label is not enough. Open the data sheet for the exact model and check its workload limit, supported bay count, recording technology, and operating conditions.

Western Digital defines annualized workload as user data transferred to or from a disk, normalized to 8,760 operating hours. Its current standard WD Purple data sheet specifies up to 180 TB per year, while some higher-capacity models and the Pro line carry higher figures. Seagate likewise specifies 180 TB per year for SkyHawk and 550 TB per year for SkyHawk AI. These figures apply to particular families and models, so do not transfer them to every disk carrying the same brand.

Compare the limit with actual writes and reads. If an array receives 500 TB of video per year and distributes writes evenly across eight disks, the rough write share is 62.5 TB per disk. Rebuilds, playback, scrubbing, export, and RAID behavior add more reads and writes. The manufacturer counts workload in both directions, not only the useful archive. Leave headroom, especially when analytics shares the system.

Choose CMR for an array unless the storage documentation explicitly permits something else. Shingled-recording disks can slow sharply during sustained rewrites and array recovery. The model, bay count, and firmware must appear on the server or controller compatibility list. A common SATA connector does not guarantee correct error handling, vibration tolerance, or power management.

A supported-stream count in a data sheet is not a performance calculation either. A claim of "up to 64 cameras" assumes certain conditions and does not prove that 64 streams at 20 Mbit/s with concurrent export suit your array. Evaluate aggregate bitrate, the operation mix, and a load test. Several predictable storage groups are preferable in a large system to one enormous volume whose failure or rebuild affects the whole site.

Temperature and power are part of storage design. Drives run hotter in a dense chassis and during RAID recovery, and a controller may throttle or remove a disk outside its operating range. Provide controlled airflow, SMART monitoring, alerts, a UPS, and orderly shutdown. The UPS does not need to run the site for hours, but it must bridge a power transfer or give the server enough time to stop recording cleanly.

A spare disk on a shelf helps only when the replacement procedure has been tested. Record who receives the alert, where a compatible model is kept, how long delivery takes to a remote site, and who can enter the rack room. Sixty-day retention depends on more than capacity. It also depends on how long the system remains degraded.

A live-scene test changes the estimate

A pilot is for measuring inputs, not for giving an attractive camera demonstration. Configure the real profiles, place cameras in representative locations, and record at least several complete days covering daylight, darkness, and lighting transitions. For a seasonal site, add an artificially difficult scene or data from a comparable location.

For each camera, record resolution, frames per second, codec, bitrate control, target quality, stream limit, GOP, day-night mode, audio, recording mode, pre-recording, and post-recording. Beside them, record the average, 95th percentile, and maximum bitrate along with the actual recorded-time ratio. A screenshot of settings without measured results is not a calculation.

Test quality against the task, not against a general impression. At an entrance, play back a moving face against backlight. In a parking area, check a plate at the required distance at night. At a checkout, confirm that hands and objects remain distinguishable at the required frame rate. If reducing bitrate removes required detail, restore the quality and enlarge the storage design.

After the pilot, perform four checks:

1. Calculated daily archive growth matches the measured growth within explainable overhead.
2. Peak streams cross every network segment without losses or queues.
3. The archive plays and exports while all cameras continue recording.
4. The system retains recording during an array check or a single-disk failure as required by the chosen RAID.

Then test retention without waiting two months. Measure growth over seven days, multiply by 60/7, and compare it with the capacity the VMS actually permits the archive to occupy. Model elevated activity separately. This forecast does not replace the final check on day 60, but it quickly reveals an error in units, stream profile, or retention policy.

Do not accept a system based on the number of installed terabytes. The acceptance record should contain measured bitrate by group, available usable capacity, deletion threshold, retention forecast, peak load, and playback results. You can then recalculate a changed camera group instead of debating from memory.

A complete calculation for 48 cameras

Consider a site with 48 cameras and a mandatory 60-day archive. The design has 24 indoor 1080p cameras averaging 2 Mbit/s, 16 outdoor 4 MP cameras at 5 Mbit/s, and eight 4K cameras at 12 Mbit/s. All record continuously, and the figures come from a pilot that included daytime and nighttime conditions.

The aggregate average stream is:

24 × 2 + 16 × 5 + 8 × 12 = 224 Мбит/с

Raw capacity for 60 days is:

224 × 0,648 = 145,152 ТБ

Add 3 TB for audio, indexes, thumbnails, and system data measured in the pilot VMS. The calculation base becomes 148.152 TB. Allow 20 percent for scene growth, the replacement of several cameras, and differences between the pilot and a long period:

148,152 × 1,2 = 177,7824 ТБ

If the volume can be filled to 85 percent, the required usable array capacity is:

177,7824 / 0,85 = 209,16 ТБ

A set of sixteen 16 TB disks in RAID 6 provides roughly 224 TB before formatting: (16 - 2) × 16. It passes the preliminary capacity test with a small remainder, but the design is not yet approved. Subtract the specific array's system overhead, confirm support for a 16-disk group, check rebuild speed, verify annual workload for the disk model, and test write performance with concurrent reading.

Now consider bandwidth. Suppose the measured peaks are 3.5 Mbit/s for indoor cameras, 9 Mbit/s for outdoor units, and 20 Mbit/s for 4K. If an adverse event can affect every camera at once, the upper sum is:

24 × 3,5 + 16 × 9 + 8 × 20 = 388 Мбит/с
388 × 1,2 = 465,6 Мбит/с с сетевым запасом

One gigabit interface can nominally receive this load, but you should not blindly mix recording, client viewing, backup, and management on it. A practical design separates traffic into VLANs and interfaces where the architecture supports this, checks every uplink, and leaves room for outbound reads. If two remote sites converge through a 200 Mbit/s link, the server's gigabit adapter does not solve that bottleneck.

Motion recording would change the calculation. Suppose the indoor cameras record the primary stream 35 percent of the time and continuously record a 0.3 Mbit/s background stream, while all other cameras remain continuous. Calculate the indoor group as 24 × (2 × 0,35 + 0,3), not 24 × 2 × 0,35, because the background stream never stops. Confirm the 35 percent ratio from saved clips including pre-recording and post-recording.

On large and public-sector sites, make the calculation part of the technical specification: stream table, retention, usable capacity, RAID level, failure behavior, disk requirements, and acceptance-test method. GSE can design the server and data-center portion of such a system around S200 rack servers and connect the calculation to supply, integration, and round-the-clock support across Kazakhstan.

Sixty days do not appear on a disk specification. They emerge from a chain of testable assumptions. Keep the source measurements and formulas with the project. When cameras are added or lighting changes a year later, you can replace a few rows and see the new retention before the needed recording is deleted.