HDD Capacity Calculation

Start with the retention requirement: how many days recordings must be kept before the recorder overwrites them, because the capacity grows in direct proportion to it. Then list the cameras in groups with the same settings (number, resolution, codec, frame rate and, if known, bitrate), and note the recording mode (continuous, set hours, or motion and events only) and whether audio or RAID is used. The core calculation is total bitrate (Mbps) × 10.8 = GB per day, then × days = GB for the whole period, plus a free-space margin of about 10%. Finally, check that the result fits the number of disk bays and the largest disk size the recorder supports.

The deciding factor is how long it can take before someone notices an incident and asks for the footage: thefts and stock shortages are often discovered days or weeks later, and once the retention period has passed the footage is gone. As typical practice, 7 to 14 days is common for homes and small shops, 30 days for most offices, shops and commercial sites, and 60 to 90 days or more where a regulator, insurer, client contract or internal policy requires it. If such a requirement exists, it sets the minimum and the calculation must be based on it. Because capacity is proportional to days, going from 30 to 90 days triples the disk space needed.

GB per day = bitrate (Mbps) × 86,400 ÷ 8 ÷ 1,000, where 86,400 is the number of seconds in a day, dividing by 8 converts bits to bytes and dividing by 1,000 converts MB to GB. In short, every 1 Mbps of continuous recording uses 10.8 GB per day and 324 GB per 30 days. If you record only part of the day, replace 86,400 with 3,600 × recording hours. The result is in decimal GB and TB (1 TB = 1,000 GB), the same units printed on hard disks and used by the KDT website's storage calculator.

Add up the bitrates of all the cameras and apply the formula: 16 cameras at 4 Mbps each (typical for a 2 MP camera with H.264 at 25 fps) make 64 Mbps, which uses 64 × 86,400 ÷ 8 ÷ 1,000 = 691.2 GB per day. Over 30 days that is 691.2 × 30 = 20,736 GB, about 20.7 TB. With the free-space margin of about 10% used by the KDT website's storage calculator you need 20.736 ÷ 0.9 = 23.04 TB, for example 2 × 12 TB disks. With H.265 (about 2 Mbps per camera) the same system needs half: 10.37 TB, or 11.52 TB with the margin, so a single 12 TB disk.

A camera recording continuously at 4 Mbps uses 4 × 86,400 ÷ 8 ÷ 1,000 = 43.2 GB per day (1.8 GB per hour) and 1,296 GB, about 1.3 TB, per 30 days. At the typical H.265 bitrates used by the KDT website's storage calculator (25 fps, medium scene activity), a 2 MP camera at about 2 Mbps needs about 648 GB per 30 days, a 4 MP camera at about 3 Mbps about 972 GB, and a 4K (8 MP) camera at about 6 Mbps about 1.94 TB. With H.264 these figures roughly double.

Use typical reference values and replace them with the real figures once the cameras are chosen. For one camera at 25 fps with medium scene activity, the KDT website's storage calculator uses 4 Mbps for 2 MP, 6 Mbps for 4 MP, 8 Mbps for 5 MP and 12 Mbps for 8 MP (4K) with H.264; H.265 is taken as half of these (2, 3, 4 and 6 Mbps) and the smart codec H.265+ as 0.3 times the H.264 value. For busy scenes or top image quality the calculator multiplies these values by 1.5, and for quiet scenes by 0.6.

Open the camera's web interface (or the camera settings on the recorder) and look at the video or encoding settings of the stream that is recorded, usually the main stream: they show the bitrate type (CBR or VBR) and the bitrate or its maximum, typically in Kbps. Many recorders also show each channel's current bitrate on a channel information or system status page. The most reliable method is to let the system record for a full 24 hours, including the night, and read how much disk space was used; that daily figure multiplied by the retention days is your real requirement.

Divide by 1,000 to get Mbps: 4096 Kbps is 4.096 Mbps, so the camera uses 4.096 × 86,400 ÷ 8 ÷ 1,000 ≈ 44.2 GB per day. The common setting 4096 Kbps is often called 4 Mbps (taking 1 Mbps as 1024 Kbps), but the difference is only about 2.4% (44.2 against 43.2 GB per day) and the usual free-space margin covers it. What matters more is whether this value is a fixed CBR bitrate or only the ceiling of a VBR stream.

With CBR the camera stays close to the set bitrate, so storage is predictable and you can use that value directly. With VBR the set value is only a ceiling: in quiet scenes the average can be well below it, but at night or in busy scenes it can approach the ceiling. If the retention period is a firm requirement, calculate with the VBR maximum; if you use a measured average instead, measure it over at least a full day and night and keep a larger margin. For example, a VBR stream capped at 4 Mbps needs 43.2 GB per day at the cap, while a measured average of 2.5 Mbps needs only 27 GB per day.

Disk makers use decimal units (1 TB = 1,000,000,000,000 bytes), while Windows and many recorders count in binary units (1 TiB = 1,099,511,627,776 bytes) but still label them TB. So a 4 TB disk is 4,000,000,000,000 ÷ 1,099,511,627,776 = 3.638 TiB, shown as 3.63 or 3.64 depending on rounding, or about 3,725 GiB; nothing is missing, the same capacity is simply expressed in a unit about 10% larger, so the number is about 9% smaller. The formula in this Help Center and the KDT website's storage calculator use decimal units, so compare their results with the capacity printed on the disk label; to compare with a binary display, multiply decimal TB by 0.909 (an 8 TB disk shows about 7.28 TiB).

At similar image quality, H.265 typically needs 30 to 50% less bitrate than H.264, and the KDT website's storage calculator uses the 50% end of that range (factor 0.5). Example: 16 cameras of 4 MP at 25 fps kept for 30 days need about 6 Mbps each with H.264 (96 Mbps in total, 1,036.8 GB per day, about 31.1 TB), but about 3 Mbps each with H.265 (48 Mbps, 518.4 GB per day, about 15.55 TB). The saving only applies if both the camera and the recorder support H.265 and it is actually enabled on the recorded stream.

Smart codecs add techniques on top of H.265, such as long, adaptive intervals between key frames and spending less data on the unchanging background, so their saving depends strongly on how much of the scene moves. The KDT website's storage calculator takes them as 0.3 times the H.264 bitrate, which is 40% less than plain H.265; for a 4 MP camera at 25 fps that is about 1.8 Mbps, or about 19.4 GB per day. The saving is largest in static scenes such as corridors and storerooms and much smaller on busy streets, and both the camera and the recorder must support the codec.

Not quite, because with fewer frames each frame differs more from the previous one and needs more data. The KDT website's storage calculator scales the bitrate by (fps ÷ 25)^0.85, so 15 fps needs about 65% of the 25 fps bitrate (a saving of about 35%, not 40%), 10 fps about 46% and 30 fps about 117%. In CBR mode, lowering the frame rate alone saves nothing because the camera keeps sending the set bitrate, so lower the bitrate as well. For less critical cameras, about 15 fps is usually enough.

Storage grows with resolution, but less than the pixel count, because the codec compresses larger images more efficiently. In the reference values of the KDT website's storage calculator (H.264, 25 fps), a 2 MP camera is 4 Mbps, a 4 MP camera 6 Mbps and an 8 MP (4K) camera 12 Mbps: 4 times the pixels needs about 3 times the bitrate. In CBR mode, however, storage follows only the bitrate you set: a 4K camera set to a very low bitrate uses little space, but its image shows compression artefacts and loses the detail you paid for.

With VBR and smart codecs, the bitrate depends on how much changes in the picture: trees and leaves in the wind, traffic, crowds, water, rain and flickering lights all raise it, while an empty corridor needs little data. The field of view matters too, since a wide view of a busy street contains much more motion than a close view of a door. The KDT website's storage calculator models this with a scene activity factor of 0.6 for low, 1 for medium and 1.5 for high; for a 4 MP H.265 camera at 25 fps that means about 1.8, 3 or 4.5 Mbps, or 19.4, 32.4 or 48.6 GB per day.

In low light the camera raises the sensor gain, and the resulting image noise looks like constant fine movement to the encoder, so a VBR stream can use noticeably more data at night than during the day. In CBR mode the bitrate stays the same, but the night image loses quality instead. When sizing, use a bitrate measured over a full day and night or, as a conservative estimate, choose high scene activity in the site's calculator for cameras that spend long hours in the dark. Good lighting or infrared (IR) illumination and the camera's noise-reduction settings help keep the night bitrate down.

Storage becomes roughly the continuous figure multiplied by the share of the day with motion, plus the pre- and post-record time added to each event (usually a few seconds). For example, a 3 Mbps camera needs 32.4 GB per day when recording continuously; if motion is present about 20% of the time, that falls to roughly 6.5 GB. These are only estimates: a storeroom opened a few times a day may save over 80%, while a busy entrance, trees in the wind, rain or car headlights at night can keep recording active most of the time and save little. The KDT website's calculator assumes continuous recording, so size cameras with unpredictable activity for continuous recording or leave a generous margin.

Use the recording hours instead of the whole day: GB per day = bitrate (Mbps) × 3,600 × recording hours ÷ 8 ÷ 1,000. For example, 8 cameras at 3 Mbps (24 Mbps in total) recording 12 hours a day use 24 × 3,600 × 12 ÷ 8 ÷ 1,000 = 129.6 GB per day, or about 3.89 TB in 30 days, half of 24-hour recording. In the KDT website's storage calculator, choose “Only some hours a day” and enter the hours.

Very little. A typical G.711 audio stream is 64 kbps, which is 0.064 × 86,400 ÷ 8 ÷ 1,000 ≈ 0.69 GB per day per camera, about 1.6% of a 4 Mbps video stream (43.2 GB per day). The KDT website's storage calculator counts video only, so if audio is recorded, add about 0.69 GB per camera per day (about 21 GB per camera for 30 days).

Group cameras with the same settings, multiply each group's per-camera bitrate by its number of cameras and add the groups; the total bitrate then goes into the formula. For example, 8 cameras of 2 MP with H.265 at about 2 Mbps (16 Mbps) plus 4 cameras of 8 MP (4K) with H.265 at about 6 Mbps (24 Mbps) make 40 Mbps, which is 40 × 10.8 = 432 GB per day and 12,960 GB, about 12.96 TB, in 30 days. The KDT website's storage calculator does this for you: add a group for each camera type with the “Add a camera group” button.

The KDT website's storage calculator adds about 10%: required capacity = calculated total ÷ 0.9, so the 15.55 TB of the 16-camera 4 MP H.265 example (30 days) becomes 17.28 TB. This margin is not about leaving the disk empty, because a recorder that overwrites old footage eventually fills the disk anyway; it means the retention target is still met if real bitrates turn out about 11% higher than estimated. If your bitrates are assumptions rather than measurements, or cameras face busy scenes or long nights, a 15 to 20% margin is safer; if more cameras will be added later, include them in the calculation or leave disk bays free.

Yes, if the recorder supports recording the sub-stream: a sub-stream typically runs at low resolution and about 0.25 to 1 Mbps, while a typical main stream is 2 to 6 Mbps. Example for one year: 16 cameras recording a 3 Mbps main stream need 48 × 10.8 × 365 = 189,216 GB, about 189 TB, while the same cameras recording a 0.5 Mbps sub-stream need 8 × 10.8 × 365 = 31,536 GB, about 31.5 TB. The price is detail: a low-resolution sub-stream shows what happened but is usually not enough to identify faces or licence plates, so critical cameras should still record the main stream.

No. You can keep critical cameras (entrances, cash desks) longer than less important ones: calculate each group separately as bitrate × 10.8 × its own days and add the results. For example, 4 cameras at 4 Mbps kept for 60 days need 10,368 GB and 12 cameras at 2 Mbps kept for 14 days need 3,628.8 GB, about 14 TB in total, compared with 25.92 TB if all 16 cameras were kept for 60 days. This needs a recorder that can assign disks or storage quotas to groups of cameras (see the Network Storage topic); the KDT website's calculator uses one retention period, so run it once per group and add the results.

Divide the required capacity (including the margin) by each common disk size and round up. For 17.28 TB (the 16-camera 4 MP H.265 example with its margin) the options are 5 × 4 TB, 3 × 6 TB, 3 × 8 TB, 2 × 10 TB, 2 × 12 TB or 2 × 16 TB; the KDT website's storage calculator suggests the option with the fewest disks and then the least spare capacity, here 2 × 10 TB (20 TB in total). Then check the recorder: it needs that many disk bays and must support that disk size. Fewer, larger disks leave bays free for later expansion, but RAID needs a minimum number of disks.

The recorder's ceiling is its number of disk bays × the largest disk size it supports; for example, 2 bays × 8 TB gives 16 TB. With the 16-camera example at 64 Mbps (691.2 GB per day), 16 TB holds only 16,000 ÷ 691.2 ≈ 23 days instead of 30. Options: switch to H.265 or a smart codec (at half the bitrate the same 16 TB holds about 46 days), lower the frame rate or bitrate of less critical cameras, record by motion or schedule, shorten retention for some cameras, or use a recorder with more bays or a second recorder. Also check that the total bitrate stays within the recorder's incoming (recording) bandwidth given in its datasheet.

Reverse the formula: days = disk capacity in GB ÷ GB per day. For example, 8 cameras of 4 MP with H.265 at about 3 Mbps make 24 Mbps, or 24 × 10.8 = 259.2 GB per day, so an 8 TB disk (8,000 GB) holds about 8,000 ÷ 259.2 ≈ 30.9 days. Real bitrates vary, so plan on about 10% less, here about 27.8 days, or check the actual retention on the recorder once the disk is full.

Once the disks are full and the recorder is overwriting, search the recordings in playback: the date of the oldest recording still available is the real retention. Before the disks are full, divide the used space by the number of days recorded to get the daily use, then divide the total capacity by that; take both figures from the same recorder screen so that the units match. For example, if the recorder shows 7.28 TB in total and 0.52 TB used after 24 hours, the disk will hold about 7.28 ÷ 0.52 = 14 days.

Most recorders are set to overwrite by default: the oldest recordings are deleted automatically to make room for new ones, so the disk stays full and the retention equals the number of days that fit on it. If overwriting is turned off, the recorder stops recording when the disk is full and usually raises a disk-full alarm, which is rarely what a surveillance system should do. Many recorders can also delete recordings older than a set number of days, which is useful when a rule or internal policy sets a maximum retention period rather than a minimum.

The calculated requirement must fit in the usable capacity after RAID, not in the raw total of the disks. With N disks of equal size: RAID 1 (mirror) = the capacity of one disk, RAID 5 = (N − 1) × disk, RAID 6 = (N − 2) × disk and RAID 10 = N ÷ 2 × disk (minimum disks: 2 for RAID 1, 3 for RAID 5, 4 for RAID 6 and RAID 10); a hot-spare disk adds no capacity, and with mixed sizes every member counts as the smallest one. For example, 17.28 TB with 8 TB disks needs 4 disks in RAID 5 or 5 disks in RAID 6 (24 TB usable in both cases), while three disks are enough without RAID. The KDT website's calculator suggests disks without RAID; RAID levels and recorder support are covered in the Network Storage topic.

The usual causes are real bitrates higher than assumed (VBR peaks, night-time noise, busy scenes, or a higher bitrate or frame rate set on the camera), the recorder also recording the sub-stream or audio, and the pre- and post-record time of events. Other causes are comparing a decimal calculation with a binary display (a 4 TB disk shows about 3.64 TiB) and forgetting the capacity taken by RAID redundancy. Measure the real daily use over a full day and night, correct the bitrates in the calculation, and then adjust the settings or the disks.

Yes, because a recorder writes around the clock. Annual writes = GB per day × 365: the 16-camera example at 64 Mbps (691.2 GB per day) writes about 252 TB a year. Without RAID this is spread over the disks (with two disks, about 126 TB each), while in a RAID 1 mirror every disk writes all of it. Surveillance-class disks are typically rated for about 180 TB per year and higher-end models for more, while desktop disks are generally rated lower and are not designed for round-the-clock recording. Check the workload rating in the disk's datasheet, and remember that reads for playback and backup count as well.

Use the same formula: days = card capacity in GB ÷ GB per day. A 128 GB microSD card recording continuously holds about 128 ÷ 32.4 ≈ 4 days at 3 Mbps, or about 12 days at 1 Mbps (10.8 GB per day); a 256 GB card doubles this. Motion or event recording, or recording a lower-bitrate stream to the card, extends this considerably, and cards made for continuous recording (high endurance cards) last much longer than ordinary ones.

Open the storage calculator in the After-sales services section (/after-sales/storage-calculator) and enter each group of similar cameras: number, resolution, codec, frame rate and scene activity; then choose continuous or part-day recording and the retention days. It shows the bitrate per camera and per group, the storage per day and for the whole period, the capacity needed with about 10% free space, a table of 4 to 16 TB disks with a suggestion, and whether a 100 Mbps or a gigabit link is enough for the total bitrate. The calculation is kept in the page address, so you can share it with “Copy link”, copy a summary or print it. It counts video only, with no audio, no RAID and no motion-based recording, so adjust the result for event recording, audio and RAID as explained in the other questions of this topic.

Yes. On the storage calculator page, the “Ask for a project design” button opens a request form for KDT's sales team, whose engineers size the recorders, hard disks and network for your project and suggest suitable cameras and NVRs. For an accurate answer, send the number of cameras of each type with their resolution, codec and frame rate, the recording mode and hours, the retention days, whether you need RAID or audio recording, and the recorder model if you already have one. A link to your own calculation from the “Copy link” button also saves time.