Backups
S3 backup retention planning: estimate capacity before history grows
Backup capacity is a function of history, not just the size of the live server. An object repository that begins nearly empty can fill quickly when daily change, full backups, retained object versions and long retention all compound.
Measure the protected dataset
Start with the bytes the backup software actually reads after exclusions, not the advertised disk size of the source server. Databases, uploads and user files may grow at different rates.
Record a baseline from a real backup run. Estimates become more useful when they are anchored to the compressed or deduplicated representation the tool stores.
Measure daily change
Incremental systems store changed blocks or files while full-backup systems may create another large object set. A small live database with high churn can produce more historical data than a larger mostly-static archive.
Observe several normal days and at least one busy period before setting a long-term capacity expectation.
Account for object versions and incomplete uploads
Bucket versioning can retain old generations beyond the backup software’s own catalog. Abandoned multipart parts can also consume storage until they are cleaned up.
Use backend authoritative byte counts when reconciling capacity because the backup application may not include every billable object in its own summary.
Translate recovery goals into retention
Keeping 30 daily points is different from keeping hourly points for seven days plus monthly archives for a year. Write the recovery timeline first, then calculate how much historical data that policy produces.
More retention is useful only when operators can identify and restore the desired point. Catalog and restore testing belong in the capacity design.
Keep headroom below the hard quota
A repository at 99.9% capacity can fail a large backup or multipart upload even though the nominal new data seems small. Alert before the quota boundary and provide a controlled upgrade path.
Capacity enforcement should stop unexpected overrun, while monitoring should make reaching the hard stop a rare event with advance warning.