The arithmetic, and why estimates go wrong
Continuous recording storage comes down to one calculation:
bitrate × cameras × hours × days ÷ 8 = bytes
A single camera at 2 Mbps recording continuously uses roughly 21.6 GB per day. Four such cameras for 30 days is about 2.6 TB. The formula is trivial; the estimates go wrong because of what people assume about bitrate.
Most cameras encode at a variable bitrate. A quiet corridor at night compresses to almost nothing; the same camera on a windy day with moving foliage, rain, or a busy scene can sit at its configured ceiling for hours. Sizing against the average and discovering the ceiling during a storm is one of the most common ways a video deployment fails, and it fails precisely when something is happening.
Plan against the configured maximum bitrate, not the observed average.
What actually drives the number
- Bitrate — the dominant term, and the one you control directly.
- Resolution and frame rate — they influence bitrate but do not determine it. A 4K stream capped at 4 Mbps stores the same volume as a 1080p stream capped at 4 Mbps; it just looks worse at that ceiling.
- Codec — H.265 typically achieves similar perceived quality at roughly half the bitrate of H.264, at the cost of more decode work and less universal support.
- Retention period — a linear multiplier, and usually the term set by policy or regulation rather than engineering.
- Recording mode — continuous is predictable; event-triggered is far smaller but risks missing context before the trigger.
Recording continuously does not have to mean recording at full quality
These are separate decisions, and conflating them is expensive. A common and effective pattern is to keep a continuous low-bitrate record for context, and reserve full-quality clips for moments the system judged important. A downscaled, lower-frame-rate continuous track answers "what happened here at 3am" perfectly well at a fraction of the storage, while the evidence attached to an alert stays at a quality suitable for review.
Retention by age is the naive policy
Most systems delete the oldest footage first. That is simple, and it is wrong in the case that matters most: the oldest footage may be the incident, and the newest may be an empty car park.
A better model retains by importance:
- Locked — footage flagged for an investigation or legal hold. Never deleted automatically, regardless of age or disk pressure.
- Evidence — clips attached to a real alert. Kept substantially longer than routine footage.
- Continuous — the routine background record. First to be reclaimed.
- Corrupt or unreadable — reclaimed immediately; it has no value.
Expressing this as data rather than code matters too: a retention policy that can be read, audited and changed without a software release is one an operator can actually be accountable for.
The failure mode nobody plans for
A disk-full condition is not a storage problem, it is a recording problem — the system stops capturing exactly when you least want it to. So the emergency behaviour needs as much design attention as the steady state.
One subtlety worth internalising: if deleting everything the system is allowed to delete still would not free enough space to keep recording, deleting it achieves nothing except destroying footage. A well-built retention manager recognises that case and refuses, raising an alarm instead. Reclaiming 200 MB against a 30 GB shortfall is not a partial fix; it is pure loss.
Equally, retention should only ever manage directories it owns. Pointing automatic deletion at a directory that also contains exports, backups or unrelated data is a category of accident that is very hard to undo.
Practical sizing advice
- Size against maximum bitrate, then add 20–30% headroom. Filesystems degrade near full, and you want room to absorb a bad week.
- Measure real consumption for a week before committing to a long-term retention promise.
- Monitor free space as an operational signal with an alert, not as something noticed after recording has already stopped.
- Decide the legal retention requirement first — it is often the actual constraint, and it is not an engineering choice.
Where ManasaView fits
ManasaView records continuously at a deliberately reduced bitrate for context, keeps full-quality evidence with each alert, and manages retention by importance rather than age — including refusing to delete when deletion would not actually recover usable space. Everything stays on the local device.
Frequently asked questions
How much storage do I need for one camera?
Roughly bitrate x hours / 8. A camera at 2 Mbps recording continuously uses about 21.6 GB per day, or 650 GB per month. Size against the camera's configured maximum bitrate rather than its average, because variable-bitrate encoders reach the ceiling during busy or windy scenes.
Does higher resolution always mean more storage?
Not directly. Storage follows bitrate. A 4K stream capped at 4 Mbps consumes the same space as a 1080p stream capped at 4 Mbps — the higher resolution simply looks worse at that ceiling. Resolution influences the bitrate you should choose, but the bitrate is what fills the disk.
Is H.265 worth it for storage savings?
Often yes. H.265 typically achieves comparable perceived quality at around half the bitrate of H.264, which roughly halves storage. The trade-offs are higher decode cost and less universal compatibility across older software and browsers.
Should I record continuously or only on events?
Continuous recording gives you context before and after an incident and predictable storage growth; event-only recording is far smaller but can miss what led up to the trigger. A common compromise is continuous recording at reduced quality plus full-quality clips attached to alerts.
What should happen when the disk fills up?
The system should reclaim space by policy — corrupt data first, then routine continuous footage, while protecting locked and evidence footage — and alert the operator. Critically, if deleting everything permitted still would not free enough space, deleting achieves nothing and should be refused rather than destroying footage for no gain.
← Back to Knowledge