How much storage do offsite backups require?

The correct capacity for an offsite backup repository is based on the backup design and the amount of data retained, rather than simply the size of the live file estate. A sound estimate accounts for the initial protected dataset, the backup method, the number and type of restore points, repository overheads, and planned growth.

Start with a complete data inventory. Identify every workload that requires protection, including file servers, virtual machines, databases, applications, laptops, cloud platforms and data held at separate offices. Record the current size of each workload and distinguish active business data from operating-system files, temporary files, caches and other content that does not need backing up. Exclusions should be documented and approved rather than assumed, because omitting a dataset can create a recovery gap.

The repository size will also depend on how the backup platform creates recovery points:

• Full backups create a complete copy of the protected dataset for each applicable restore point, so they generally require more repository capacity.
• Incremental backups retain the changes since an earlier backup. They can reduce storage consumption, but the complete restore chain must remain available and usable.
• Forever-incremental or synthetic-full designs maintain recovery points from incremental data while periodically presenting a consolidated restore point. Their capacity requirements depend on the platform’s retention and consolidation process.
• Image-based backups protect an entire server or virtual machine, including system and application state, while file-based backups may cover only selected folders. These approaches are not directly comparable when estimating capacity.

Retention should be translated into actual restore points, not just described as a number of days. For example, a policy may retain recent daily points, older weekly points and longer-term monthly points. Each class can have a different storage impact, particularly where points are kept for compliance, investigation or recovery from delayed ransomware discovery.

Some items are easy to overlook when calculating capacity. Backup catalogues, indexes, checksums, snapshots, replicated metadata and temporary space used during validation or consolidation all consume repository capacity. A backup system may also need working space while creating a new point or removing expired data, so a repository that is technically large enough for the final retained set may still be too small to operate reliably.

Deduplication and compression should be based on observed results from representative workloads, not a generic assumption. Office documents, databases, encrypted files, compressed media and virtual-machine images can produce very different reduction levels. Deduplication may also be less effective when data is encrypted before it reaches the backup system. Testing a sample from each major workload gives a more defensible estimate than applying one reduction ratio to everything.

Capacity planning should include the way copies are separated. A primary backup repository, an offsite copy and an immutable or otherwise protected copy may each require their own retained data, depending on the architecture. Replication can also temporarily require additional space when a transfer is interrupted, when a new baseline is created or when two repository versions coexist during maintenance.

A practical sizing exercise normally follows this process:

1. Measure the source data included in the protection policy.
2. Separate workloads by backup type, change behaviour and retention requirement.
3. Model the number of restore points and the data held by each point.
4. Apply only tested compression and deduplication results.
5. Add catalogue, snapshot, replication and operational working-space requirements.
6. Allow capacity for planned users, workloads, offices and data growth.
7. Check the result against the repository’s ability to retain, replicate, verify and restore the planned points.

Monitoring is needed after deployment because the original estimate is not permanent. A business may add a file server, increase database activity, retain more versions or change its legal retention policy. Tracking repository consumption, daily change volumes, failed pruning and the age of the oldest retained point helps identify when the design needs adjustment.

For organisations without a dedicated backup specialist, S2 Technology Group can assess the protected workloads, retention policy and repository design as part of its managed IT and offsite backup support. The aim is to size storage around recovery requirements while avoiding both an under-sized repository and unnecessary capacity.