How Much Storage Does 30, 60, or 90 Days of Video Actually Take? Run the Math Yourself.

Gigabytes per day equals megabits per second times 10.8. That is the whole formula, and once you have it you never need a vendor's storage calculator again.

Here is where the 10.8 comes from, because you should not take an unexplained constant from us either. A stream running at B megabits per second produces B times 86,400 megabits in a day, since a day holds 86,400 seconds. Divide by 8 to convert megabits to megabytes and you get B times 10,800 megabytes. That is B times 10.8 gigabytes in decimal GB.

Every other input in storage sizing is arithmetic on top of that. There is exactly one number in the calculation that you cannot derive, and it is the per-camera bitrate. This piece is about where that number actually comes from and about the three haircuts that sit between the answer and the drive capacity you have to buy.

Why Two Calculators Disagree About the Same 16 Cameras

Because they are assuming different bitrates and neither one tells you what it assumed.

Seagate publishes a Surveillance Storage Calculator that takes number of cameras, frames per second, hours per day, number of days stored, resolution, a three-position video quality selector, and a compression setting (seagate.com/video-storage-calculator/, retrieved 2026-08-13).

Look at what that input set does and does not contain. Resolution, frame rate, and codec are there. Bitrate is not. Instead there is a three-position quality dropdown, and the page explains that "Video quality is determined based on bandwidth and compression settings" and that "Lower bandwidth and greater compression equates to lower video quality" (seagate.com, retrieved 2026-08-13). The page publishes no bitrate assumption and no formula.

We are describing the tool factually rather than criticizing Seagate, who publish a useful thing for free and whose output is tied to their own drive line. The structural point applies to every calculator in this category, ours included if we published one. When "medium" hides an unpublished number of megabits per second, the output is not a calculation you can audit. It is a result you have to trust. Two tools with different hidden assumptions will disagree about identical inputs, and neither will show you why.

The Bitrate Comes From Your Datasheet

The per-camera bitrate is a published specification. It lives on the specific camera model's own datasheet, usually under encoder or stream settings, and it is quoted at a stated resolution, frame rate, and codec.

That is the only place to get it. Not from a calculator's dropdown, and not from the bitrate ranges that fill CCTV blogs and comparison sites, because those ranges are almost never traceable to a manufacturer. A number that appears in six aggregator articles and no datasheet is still an unsourced number.

So the procedure is: open the datasheet for the model you are actually buying, at the resolution and frame rate you are actually going to run, and read the bitrate off it. If a vendor will not publish a per-stream bitrate for the configuration you asked about, that is worth noticing. It is a basic encoder specification, and its absence usually means the answer is "it depends" in a way the vendor would rather you discovered after installation.

A Worked Example

The bitrate below is a declared assumption, not a specification. We are using a round number so the arithmetic is easy to follow. Replace it with the figure from your own datasheet before you buy anything.

Assume 16 cameras, each averaging 4 Mbps, recording continuously.

Per camera per day: 4 times 10.8 equals 43.2 GB.

All 16 cameras per day: 43.2 times 16 equals 691.2 GB.

Ninety days: 691.2 times 90 equals 62,208 GB, or 62.2 TB of video in decimal terabytes.

That is the number a calculator would hand you. It is also not the number you buy, and the gap is roughly a factor of one and a half.

Decimal TB of video, assuming 4 Mbps average per camera, continuous recording. This is video volume only, before RAID parity and headroom.

Cameras	30 days	60 days	90 days
1	1.3 TB	2.6 TB	3.9 TB
8	10.4 TB	20.7 TB	31.1 TB
16	20.7 TB	41.5 TB	62.2 TB
32	41.5 TB	82.9 TB	124.4 TB
64	82.9 TB	165.9 TB	248.8 TB

Scale the whole table linearly for a different bitrate. At 2 Mbps average, halve every figure. At 8 Mbps, double them.

Variable Bitrate Makes the Nameplate Number a Bad Plan

Almost every modern camera encodes with variable bitrate, and that changes what the datasheet figure means. The published number is typically a ceiling rather than an average. The encoder spends bits when the scene moves and saves them when it does not.

The operational consequence is that identical cameras consume different amounts of storage depending on what they are pointed at. A loading dock at shift change and a stockroom that sees three people a day are not the same storage load, even on the same model at the same settings.

So plan on a measured average, not the nameplate maximum. The way to get one is to run a representative camera on a representative scene for a week and read the actual consumption off the recorder. A week of real measurement beats any calculator, including the arithmetic above, because it captures your scenes rather than a generic assumption.

The same caution applies to codec claims. H.265 is designed to deliver equivalent perceived quality at a lower bitrate than H.264, and vendors often round that to "half the storage." Whether you get half, a third, or considerably less than either depends on your scene content, your encoder implementation, and your quality settings. Treat the halving as a design target to verify on your own stream rather than a figure to plan against.

The Three Haircuts

Between 62.2 TB of video and the purchase order sit three reductions that calculators routinely omit.

RAID parity. Parity drives hold no video. A RAID 6 array of eight drives keeps six for data, so 75 percent of nameplate capacity is available. Our 62.2 TB of video now needs 82.9 TB of nameplate capacity behind it.

Practical fill ceiling. You do not run a recording array to 100 percent. Performance degrades, and a full array is one bad week from overwriting something you needed. Planning to 85 percent takes 82.9 TB up to about 97.6 TB.

Decimal versus binary. Drives are sold in decimal terabytes, where one TB is 10 to the twelfth bytes. Operating systems commonly report in binary tebibytes, where one TiB is 2 to the fortieth bytes. The reported figure is about 9 percent smaller for the same physical capacity. Nothing has gone missing and no capacity has been lost. It is the same storage counted in different units, and it accounts for most of the "my new array is smaller than advertised" support calls in this category.

Putting it together: eight 14 TB drives are 112 TB of decimal nameplate capacity, which clears the 97.6 TB the three haircuts asked for. What the array presents is a smaller number, and this is exactly where the units bite. Six of the eight drives hold data, so the array presents about 84 TB decimal, and your operating system will report that as roughly 76 TiB. The 112 TB figure is the sum of what you bought. The 76 TiB figure is what you can write to. Both are correct, and the distance between them is parity plus the decimal-to-binary conversion, not capacity that went missing. Check it against the requirement rather than the nameplate: 84 TB usable, planned to an 85 percent fill ceiling, leaves about 71 TB decimal for video, which covers the 62.2 TB the retention window needs.

Retention Is a Policy Decision Before It Is a Hardware One

The arithmetic above answers "how much storage for N days." It does not answer "how many days," and that is the question that should come first.

Regulatory floors vary by vertical and several of them are specific. Insurance requirements and contractual obligations often set their own minimums. Litigation exposure sets a practical floor of its own, since claims routinely surface many months after the incident and footage that has rolled over is footage that does not exist. We have written separately about how retention and export decisions determine whether footage is usable as evidence.

Decide the retention window against those constraints, then run the arithmetic, then buy. Doing it in the other order produces a system sized to a number somebody picked because it was the default.

Iron Gate's Position

We publish the formula because a buyer who can run it does not need us to size their system, and we would rather compete on engineering than on being the only party who knows the math.

When we size a system, the bitrate comes from the datasheet of the camera being deployed, the average is verified against the actual scene where the deployment is large enough to warrant it, and the RAID and headroom haircuts are shown in the proposal rather than folded into a single number. If our figure disagrees with a calculator you ran, we will show you which assumption differs.

The question to put to any vendor who will not publish a per-stream bitrate for your configuration is simply this: what number did your storage proposal assume, and what happens to my retention window if it is wrong?

Common Questions

How do I calculate CCTV storage requirements?

Gigabytes per day equals megabits per second times 10.8. Multiply by camera count and by retention days, then divide by your RAID data ratio and your practical fill ceiling. Take the bitrate from the camera's datasheet at the resolution and frame rate you will actually run.

How much storage do I need for 30 days of security camera footage?

For one camera at 4 Mbps continuous, about 1.3 TB of video, and roughly 2 TB of purchased capacity once RAID parity and headroom are included. Scale linearly by camera count and adjust for your real bitrate, since 4 Mbps here is an assumption for illustration rather than a specification.

How many terabytes for 16 cameras at 30 days?

About 20.7 TB of video at an assumed 4 Mbps average, continuous. Add RAID parity and a fill ceiling and the purchase lands near 32 TB of nameplate capacity on a RAID 6 array planned to 85 percent.

Why do two storage calculators give different answers?

Because each assumes a per-camera bitrate that it does not publish, and the assumptions differ. A quality dropdown reading low, medium, or high is standing in for a number of megabits per second you never see, which means the output cannot be audited.

Does H.265 really cut storage in half?

Halving is the design target rather than a guaranteed result. Actual savings depend on scene content, encoder implementation, and quality settings. Measure it on your own stream by running the same scene under both codecs and reading the consumption off the recorder.

What bitrate should I plan for per security camera?

The one on your camera's datasheet, at your resolution, frame rate, and codec, adjusted downward toward a measured average if you are using variable bitrate. Do not plan from bitrate ranges found in aggregator articles, since those are rarely traceable to any manufacturer.

Sources

• Seagate Surveillance Storage Calculator, seagate.com/video-storage-calculator/, retrieved 2026-08-13. Cited for its published input set and for the absence of any published bitrate assumption or formula.
• The gigabytes-per-day formula is arithmetic derived in the text above rather than a sourced claim. The 4 Mbps figure used throughout the worked example is a declared assumption for illustration and is not a specification for any product.