# CCTV Footage Storage: Retention Planning, Capacity Calculation, and Backup Architecture > **TL;DR:** > > * CCTV footage storage requirements are the product of five inputs: camera count, per-camera bitrate (which resolution and codec decide), frame rate, recording hours per day, and retention days. Move any one and capacity moves with it. > > * One number does most of the arithmetic. A stream running at 1 Mbps writes roughly **10.8 GB per camera per day**. Everything else is multiplication. > > * The 64-camera estate worked through below writes **2.59 TB per day**. That is 77.8 TB at 30 days, 233.3 TB at 90 days, and 946.1 TB at one year. > > * Retention is set by a police order, a court direction, an insurer or a regulator. It is not a property of the disk you happened to buy. > > * The architecture that holds up keeps 7 to 14 days on the NVR for fast scrubbing and moves everything older into S3-compatible object storage, with a default retention rule locking each upload on arrival and lifecycle rules handling expiry. > Most surveillance projects size storage backwards. Someone specifies an 8-bay NVR, fills it with 8 TB drives, and retention becomes whatever that hardware happens to deliver. Then a police request arrives for footage from 70 days ago, and the honest answer is that it was overwritten on day 41. CCTV footage storage requirements are better derived in the other direction: start with the retention period you are obliged to hold, work back through recording hours, frame rate, resolution and camera count, and decide the storage layer last. This post covers the arithmetic, a worked calculation for a real estate size, and the access, redundancy and archival design that keeps the footage usable once it leaves the recorder. ### **The five inputs that set CCTV footage storage requirements** Every video surveillance storage number comes out of the same five variables. Three of them are camera settings, one is a schedule, and one is a policy decision. * **Camera count** scales linearly and is the input people get right. Sixty-four cameras need four times what sixteen need, assuming identical settings. * **Resolution and codec** together produce the per-camera bitrate, which is the only figure that actually matters. Resolution sets how much detail the encoder has to carry, and the codec sets how efficiently it carries it. H.265 cuts bitrate by roughly 40 to 50 percent against H.264 at comparable quality, which is the single largest reduction available on most existing estates without touching a camera. Smart or variable codecs push further by compressing static scenes harder, though the saving depends entirely on how much the scene moves. * **Frame rate** scales close to proportionally. Dropping a camera from 15 fps to 10 fps removes about a third of its bitrate. For fixed overview cameras this is usually invisible in review. For a lane watching number plates or a counter watching hands, it is not. * **Recording hours per day** is the schedule. Continuous 24-hour recording is the default and the safe assumption for compliance work. Motion-triggered or scheduled recording cuts the number, but it introduces a failure mode: if the motion detection misses the event, there is nothing to retrieve, and nobody finds out until the footage is requested. * **Retention period** is the multiplier and the one input that is usually not yours to set. A move from 30 days ![](https://cdn.hashnode.com/uploads/covers/67a20ef8875434c6d881b8a5/640a919c-caae-4b6c-9fb0-9e9827abfc90.png align="center") *Figure 1. The five inputs that set CCTV footage storage requirements.* ### **The capacity formula** CCTV footage storage requirements reduce to one line of arithmetic:

Storage (GB)  =  Bitrate (Mbps) × 3,600 × Recording hours per day

× Number of cameras × Retention days  ÷  8,000

The division by 8,000 converts megabits to gigabytes. For continuous 24-hour recording, the whole middle of that collapses into a constant worth memorising: **1 Mbps of sustained bitrate consumes about 10.8 GB per camera per day**. A 3 Mbps camera writes 32.4 GB a day. Sixty-four of them write just over 2 TB. From there, retention is a straight multiplication. Two adjustments belong in every real estimate. Add 10 to 15 percent headroom, because bitrate on a variable-bitrate camera is an average and night-time infrared noise pushes it above the nominal figure. And if the destination bucket has versioning enabled, superseded versions keep consuming space until a lifecycle rule clears them. * * * # **A worked CCTV storage calculation: 64 cameras** Take a manufacturing site with a mixed estate, recording continuously at 15 fps on H.265. | **Group** | **Cameras** | **Bitrate per camera** | **Per camera per day** | **Group per day** | | --- | --- | --- | --- | --- | | 4MP internal, bays and corridors | 48 | 3.0 Mbps | 32.4 GB | 1,555.2 GB | | 8MP perimeter and gates | 16 | 6.0 Mbps | 64.8 GB | 1,036.8 GB | | **Total** | **64** | | | **2,592 GB (2.59 TB)** | At 2.59 TB per day, the retention target decides everything that follows: | **Retention** | **Raw capacity** | **What it means in practice** | | --- | --- | --- | | 30 days | 77.8 TB | Fits a well-specified on-premise NVR estate | | 90 days | 233.3 TB | On-premise becomes a rack, a cooling problem, and a drive replacement schedule | | 180 days | 466.6 TB | Economics have already moved to tiered storage | | 365 days | 946.1 TB | Only tiering keeps this sane | ![](https://cdn.hashnode.com/uploads/covers/67a20ef8875434c6d881b8a5/30e01263-1c8e-4880-841e-3df74e5fcae1.png align="center") *Figure 2. Worked capacity calculation for a 64-camera mixed estate.* ## **Where the levers actually move the number** Three changes applied to the same estate, so the effect of each is comparable: * Dropping the 48 internal cameras from 15 fps to 10 fps takes the daily figure from 2.59 TB to **2.07 TB**, a 20 percent reduction across the whole site. * Putting those same 48 cameras on a 12-hour schedule instead of continuous recording gives **1.81 TB per day**, a 30 percent reduction, at the cost of having no footage for half of every day. * Leaving the estate alone and moving everything past day 14 into object storage changes nothing about the volume. It changes where the volume sits, which is the point. The third option is the one that scales, because it stops treating a 90-day obligation as a 90-day disk purchase. * * * # **Retention periods are a compliance input** Retention is rarely a preference. In India it arrives from several directions at once, and the obligations do not agree with each other. | **Deployment** | **What sets retention** | **Verify before sizing** | | --- | --- | --- | | Commercial premises under a local police order | Area-specific orders. Delhi Police required establishments in Aerocity to hold footage for at least 90 days | The order in force for your police district, and when it lapses | | Any site recording identifiable people | The Digital Personal Data Protection Act, 2023, which pushes the other way: footage is personal data, and holding it past its purpose is exposure, not safety | Your stated purpose and erasure process | | Contractual and insurer requirements | The contract, usually 90 days or longer for high-value premises | The actual clause, not the broker summary | | Footage tied to an open matter | A preservation direction. Legal Hold is applied per object version, not as a bucket rule, and overrides scheduled deletion | Who is authorised to place and release the hold | Two obligations can therefore apply to one camera: hold this for a year, and delete that as soon as the purpose ends. A CCTV retention policy that handles both has to operate per bucket or per prefix rather than per site, which is an argument for storage that understands rules rather than a recorder that understands free space. * * * # **Tiering: hot at the edge, archive in object storage** Nearly all footage retrieval happens within the first two weeks, when an incident is fresh and somebody is scrubbing a timeline. Almost all of the capacity sits in the months after that, where access is rare but deletion is not permitted. Splitting along that line gives a design with two tiers. The NVR or VMS keeps 7 to 14 days locally, where scrubbing is instant and does not touch the network. Sizing NVR storage capacity for two weeks instead of three months also makes the on-site hardware a far smaller purchase. Everything older is written to S3-compatible object storage and held for the remainder of the retention period. For the 64-camera estate at a 90-day obligation, that is roughly 36 TB on site and 197 TB in [long-term data archiving](https://zata.ai/solutions/long-term-data-archiving), with the archive growing and expiring on a rolling basis rather than filling up. One practical note on sizing the archive tier: Zata publishes [storage plans](https://docs.zata.ai/account/billing) up to 100 TB, and anything above that is quoted as a custom plan. Both the 90-day and the 365-day figures for this estate land above that line, so an estate of this size is a conversation rather than a checkout. ![](https://cdn.hashnode.com/uploads/covers/67a20ef8875434c6d881b8a5/c475412e-2bde-43c9-89a2-b2d7d0814406.png align="center") *Figure 3. A two-tier design: hot retention at the edge, bulk retention in object storage.* Object storage suits this because it is flat, addressable by key, and priced on what is stored rather than on an array you provisioned in advance. A clip is an object at a predictable path, and retrieval is a single request rather than a restore job. * * * # **Access: retrieving one clip without pulling the archive** An archive nobody can query is a liability. Four mechanisms cover the retrieval patterns a surveillance archive actually has, and picking the wrong one is the usual mistake. A **prefix convention** decided before the first upload determines whether an investigator can find anything. Something like site/camera-id/YYYY/MM/DD/HH/ makes a date-and-camera request a list operation against a narrow prefix instead of a scan of a bucket holding millions of objects. The same prefixes then let you scope lifecycle rules and subuser permissions to one camera group rather than the whole site. * [**Presigned URLs**](https://docs.zata.ai/manage/bucket/storing-objects-in-a-bucket/sharing-an-object-using-presigned-url) are the right way to hand a single clip to an investigating officer or an insurer. You set a duration in hours and minutes, and the link works even though the bucket and the object stay private. Compare that with making the object public through its ACL, where the link never expires. For evidence, an expiring link is the only defensible option. * [**Subusers with access rules**](https://docs.zata.ai/subusers/roles) cover ongoing team access. Permissions are granted per subuser, per bucket, and a rule can be scoped to a single folder rather than the whole bucket. Four levels exist, and one of them matters more than the rest here: **Upload Only** lets a credential create and upload new objects but not list, download or delete existing ones. That is exactly what the uploader at the site should hold. If the recorder is compromised, its keys cannot read the archive back or wipe it. Keep **View Only** for auditors and backup verification, and leave **Full Access** with whoever administers the bucket. * [**Bucket ACLs**](https://docs.zata.ai/manage/bucket/access-control) are the blunt instrument. They are all-or-nothing and cannot target one person or one folder, so a surveillance bucket should stay Private and use the three mechanisms above. Worth knowing: Zata evaluates the ACL and the bucket policy together, and a Deny in a [bucket policy](https://docs.zata.ai/manage/bucket/bucket-policy-configuration) beats an Allow in an ACL. * Egress deserves checking before the architecture is signed off. Zata's [ingress and egress policy](https://docs.zata.ai/account/ingress-and-egress-policy) makes uploads free and unlimited and grants free egress each month equal to active storage volume, so evidence pulls measured in gigabytes sit nowhere near the ceiling. The consequence of crossing it is the part to design around: the account is temporarily suspended until the plan is upgraded or the next billing cycle begins, and while it is suspended public access stops working too. Listing the file list counts toward egress alongside downloads, so a bulk export or a script that walks the whole archive repeatedly is the realistic way to trip it, not day-to-day retrieval. * * * # **Redundancy and tamper resistance** Backup and immutability solve different problems, and surveillance needs both. Backup protects against hardware loss. Immutability protects against the much more common scenario in which the footage someone wants reviewed is the footage someone else wants gone. ![](https://cdn.hashnode.com/uploads/covers/67a20ef8875434c6d881b8a5/b1206b46-f723-4a89-90a2-57c0c9958d4d.png align="center") *Figure 4. Four controls, two different problems.* **Versioning** keeps superseded copies of an object, so an overwrite does not destroy the original. It can be switched on for a bucket that already exists, but once on it can never be fully removed, only suspended so that no further versions are created. [**Object Lock**](https://docs.zata.ai/manage/bucket/object-lock) is the control that matters for evidence, and the one decision you cannot revisit later.

ORDER-OF-OPERATIONS CONSTRAINT

Object Lock can only be enabled while the bucket is being created. It cannot be added to an existing bucket, and enabling it turns versioning on permanently. Decide this before the first object lands.

Enabling it is not sufficient on its own. The setting that does the work is the **Default Retention Rule** in Bucket Settings, which automatically locks every new upload for the number of days you specify. Without it, footage arrives unprotected and somebody has to remember to lock it by hand. Removing the rule later stops new uploads being locked, but it does not unlock anything already protected. Two retention modes are available, and the difference is who holds the escape hatch: * [**Governance mode**](https://docs.zata.ai/manage/bucket/object-lock/governance-mode): the Root User can bypass the lock and delete a protected version after typing a confirmation. Subusers cannot, whatever permissions they hold. This suits estates that want protection from routine error while the account owner keeps a way out. * [**Compliance mode**](https://docs.zata.ai/manage/bucket/object-lock/compliance-mode): nobody can overwrite or delete a protected version until retention expires. Not the Root User, not Zata support. A Compliance period can be extended, and a version can be upgraded from Governance to Compliance, but an active Compliance lock can never be shortened. [**Legal Hold**](https://docs.zata.ai/manage/bucket/object-lock/legal-hold) behaves differently from both. It is applied per object version rather than as a bucket default, carries no expiry date, and runs independent of the retention mode, so one version can hold a retention period and a Legal Hold at the same time. If the retention period lapses while the hold is on, the object still cannot be deleted. It is the control for footage tied to an open matter, and the one that has to be applied deliberately rather than inherited from a rule. Immutability and prepaid billing interact in a way that needs planning. Zata bills in fixed 30-day periods. If a subscription is not renewed, the account gets a 5-day grace period, then up to 90 days of suspension during which data is retained but inaccessible, after which it is permanently deleted. A 365-day Compliance lock does not survive that sequence, which is why the dashboard shows a recommended maximum retain-until date measured against your billing cycle. Long retention needs the subscription commitment underneath it. **Geographic separation** puts the archive in a different failure domain from the site. Zata runs two active regions, Indore ([idr01.zata.ai](http://idr01.zata.ai), region code CentralIndia) and Mumbai ([bom01.zata.ai](http://bom01.zata.ai), region code SouthIndia), with a third in Uttar Pradesh listed as coming soon. Both [service endpoints](https://docs.zata.ai/manage/service-urls-for-zata.ai-s3) sit inside Indian jurisdiction, which matters when the footage shows identifiable people. One regional difference is worth knowing before you choose: the Keep Newest Versions option on the Clear Old Versions lifecycle rule is supported in Mumbai but not in Indore. * * * # **The archival workflow** The workflow is a nightly job plus a set of rules, and most of it runs unattended. ![](https://cdn.hashnode.com/uploads/covers/67a20ef8875434c6d881b8a5/9ed83606-fcf5-47c5-b50a-69445550273f.png align="center") *Figure 5. What runs every night, and what the rules do afterwards.* Cameras write to the NVR or VMS continuously. A scheduled transfer moves the previous day's completed segments into the archive bucket under the agreed prefix. On a NAS-backed estate this is often the device's own backup app, such as [QNAP HBS 3 configured against an S3-compatible endpoint](https://docs.zata.ai/knowledgebase/how-to-integrate-qnap-nas-storage-and-backup-to-zata.ai). Where the recorder writes to a filesystem, [rclone](https://docs.zata.ai/knowledgebase/how-to-transfer-data-to-zata.ai-bucket-using-rclone) does the same job from a cron entry, and multipart upload handles the large continuous files without restarting a transfer from zero on a dropped link. [Lifecycle rules](https://docs.zata.ai/manage/bucket/lifecycle-rules) then do the expiry nobody wants to do manually. Expire Objects removes footage once it passes the retention age. Clear Old Versions is the rule that actually frees space on a versioned bucket, since expiry alone only places a delete marker. Discard Unfinished Uploads reclaims space from transfers that died mid-flight, which on a site with a flaky uplink is not a rare event. Rules run once daily, and changes take effect within 24 to 48 hours. Give that transfer job its own subuser with **Upload Only** permission scoped to the site prefix, rather than the root credentials. The job needs to write and nothing else, and a key sitting on a recorder in a plant room is the most exposed credential in the whole design. Two further settings are worth configuring while you are in Bucket Settings. A **Bucket Quota** caps storage in GB and object count, which turns a misconfigured camera writing at ten times its intended bitrate into a stopped upload rather than a surprise invoice. And the Default Retention Rule described above should be set before the first night job runs, so that every segment arrives already locked. Two operational habits separate an archive that works from one that merely exists: test a restore on a schedule and record how long it took, and reconcile object counts against expected segment counts so a silently failed night job surfaces in days rather than at the moment the footage is requested. * * * # **Build the retention plan before you buy the disks** The capacity number is the easy part. CCTV footage storage requirements fall out of five inputs and one multiplication, and anyone can run the arithmetic in a few minutes. The part that goes wrong is the sequence. Retention gets inherited from hardware instead of from the obligation, the archive gets no prefix convention, immutability gets considered after the bucket exists and therefore cannot be enabled, and the restore gets tested for the first time under pressure. Fix the order. Write down the retention each camera group is actually obliged to hold, size against it, and give the archive a storage layer that can expire objects on a rule and lock them against deletion when a matter is open.

Work out the daily write rate for your estate using the formula above, then take that figure to Zata's long-term data archiving solution to size the archive tier and set the Object Lock and lifecycle configuration before the first upload.

* * * # **FAQs** **How long should CCTV footage be stored in India?** There is no single national retention period applicable to all premises in India. CCTV footage storage duration depends on the type of premises, applicable local regulations, security requirements, and organisational policies. Businesses should define a retention period based on their operational needs, compliance obligations, and available storage capacity. **How do I calculate CCTV storage for 30 days?** Multiply each camera's bitrate in Mbps by 10.8 to get gigabytes per camera per day for continuous recording, multiply by camera count, then by 30. A 4MP H.265 camera at 15 fps runs around 3 Mbps, so 32.4 GB per day. Sixty-four mixed cameras at 2.59 TB per day reach 77.8 TB over 30 days. Add 10 to 15 percent headroom. **How much storage do I need for 64 CCTV cameras?** For the mixed estate above, 48 cameras at 4MP and 16 at 8MP recording continuously at 15 fps, around 2.59 TB per day. That is 77.8 TB for 30 days, 233.3 TB for 90 days and 946.1 TB for a year. Your figure will differ: measure actual bitrates from the recorder rather than using the camera's nominal setting. **Can CCTV footage be stored in cloud object storage?** Yes, and it is the usual answer for anything past the first two weeks. S3-compatible object storage accepts uploads from NVR backup apps, NAS tools and rclone, prices on what is stored, and supports lifecycle expiry and WORM retention. Keep recent days on the recorder for fast scrubbing and archive the remainder. **What is the best backup architecture for CCTV footage?** Two tiers. Keep 7 to 14 days on the NVR for immediate review, push everything older to an object storage bucket in a different region with Object Lock enabled at creation and a default retention rule applied. Let lifecycle rules handle expiry, give the upload job an Upload Only credential so a compromised recorder cannot wipe the archive, and test a restore on a schedule.