Backups
How many GB do I need to back up my computer?
Start with the amount of data the backup job actually protects, not the advertised size of the computer's drive. If 200 GB is protected and you want one current copy, the backup needs at least about 200 GB before version history, growth, metadata and working headroom; adding 25% illustrative headroom makes that 250 GB. Retained restore points, full-system images and ongoing changes require more capacity.
Use the backup retention calculator to compare schedules, or follow the worked example below.
Start with protected data, not drive size
Use the amount of data the backup job actually protects, not the advertised size of the computer's drive. A simple one-copy planning estimate is protected data + working headroom; retention is a separate part of the calculation. If you are protecting 200 GB and only need room for one current copy, 200 GB plus 25% working headroom is 250 GB. Version history, incremental changes, full-system images and growth require additional capacity.
- 100 GB protected: about 125 GB gives 25% headroom for one current copy.
- 250 GB protected: about 313 GB gives the same one-copy headroom.
- 500 GB protected: about 625 GB gives the same one-copy headroom.
Those are sizing examples, not retention recommendations. If you keep several restore points, calculate the stored full and incremental data for those versions as well.
Measure what you are backing up
Check the used space of the files, databases, mail and settings your backup job actually includes. Free space on the source drive does not need backing up. A full-system image can include more than a selected-file backup, so use the size reported by your backup software.
On a workstation, decide whether you need a full-system restore or only selected files. On a website, include both files and a consistent database backup. Do not exclude something merely because it looks temporary until you know how the application recovers.
Use the backup method to estimate retained storage
For independent full backups, add the size of every retained copy. For incremental or deduplicated backups, start with the full backup and add the extra stored data needed to retain later restore points. The exact amount depends on how the software chunks, compresses and removes data.
A planning estimate for a simple incremental chain is: first full backup + stored changes for later retained days. Add headroom afterward. Synthetic fulls, separate full chains, delayed cleanup and immutable retention can need additional room.
Example: 200 GB of data and 30 daily restore points
Suppose the first full backup stores 200 GB and each later day adds 10 GB that remains needed for retention. This example assumes no compression savings or metadata overhead. The full-copy comparison assumes the protected dataset stays at 200 GB.
- Thirty separate full copies: 200 × 30 = 6,000 GB. Adding 25% headroom gives 7,500 GB.
- One full plus 29 daily increments: 200 + (29 × 10) = 490 GB. Adding 25% headroom gives 612.5 GB.
The 25% margin is an illustration, not a universal safety rule. Allow more for growth, unusually large changes, cleanup delays or a restore that needs temporary space.
Check the first backup and a normal week of changes
The destination's actual stored usage is more useful than a guessed compression ratio. Photos, video, encrypted files and compressed archives often leave less scope for compression than plain text. Measure the next several backup runs and check what happens when old restore points expire.
Deleting a snapshot does not always free its space immediately. Some tools need a separate cleanup or prune step, and shared data can still be required by another snapshot. Follow your backup tool's retention and cleanup instructions.
Restic's retention and pruning guide explains one example; other backup tools have different rules.
Choose capacity and a destination your software supports
Compare the expected retained size with the plan limit using the same units. A decimal GB is not the same as a GiB. Leave room for the backup job to finish, not just for yesterday's usage.
DotMoose offers SFTP Backup Storage and S3-compatible Object Storage. Use the protocol supported by your software. Ask about physical separation when the source is another DotMoose service; a separate storage account does not by itself prove a separate failure location.
Test a restore before relying on the backup
Restore representative files and application data to a separate test location. Check that you have the encryption keys and credentials needed to recover. A completed upload is not the same as a successful restore.
Follow the restore-testing guide, and review capacity when your dataset or retention policy changes.