How Long Are Backups Kept, and Why Is Storage Growing?
Backup frequency determines when data is collected. Retention determines which older recovery points remain available. A frequent backup schedule does not mean every version will be kept forever.
Choose a Retention Policy
As a Domain Administrator or System Administrator, select the domain and open Settings > Backup settings > Backup Options > Data retention policy.
| Option | Effect |
|---|---|
| Smart tiered retention | Keeps all recent versions and fewer versions as backups age |
| Keep versions for a fixed number of days | Keeps all versions within the chosen period, with a minimum of 7 days |
| Keep all records (no cleanup) | Disables automatic cleanup of backup versions and history records |
After choosing the policy, click Update data retention policy. Cleanup runs separately, so saving a shorter period does not immediately release disk space.
Smart tiered retention uses these intervals:
| Age of backup | Versions retained |
|---|---|
| Last 7 days | All versions |
| Over 7 to 30 days | Latest one per day |
| Over 30 days to 1 year | Latest one per week |
| Over 1 to 2 years | Latest one per month |
| Over 2 years | Latest one per year |
The latest recovery point for each user's app and each Shared Drive is always kept, even when older than the selected period. Gmail is currently excluded from version cleanup. A 30-day retention setting therefore does not mean that Gmail messages older than 30 days are deleted from backup storage.
Why Are Some Older Dates Missing?
Under tiered retention, older dates are deliberately reduced to daily, weekly, monthly, or yearly points. Under fixed retention, older points become eligible for removal apart from the latest point. Neither policy creates backups for dates when no successful backup occurred.
Choose a retention period with the person responsible for company records. Shortening it can remove versions you may later need. Increasing it afterward cannot bring back data that cleanup has already removed.
Retention cleans JitBackup's stored versions and records; it is not a command to delete current data from Google Workspace.
How Much Storage Do I Need?
Allow space for the selected users' current data, retained versions, future growth, and the local index and temporary files. Large mailboxes and frequently changed files can have very different storage needs. Compression savings depend on the data; already compressed files may shrink very little.
Measure the first completed backup and subsequent growth before choosing a long-term capacity. Check actual free space on both the index disk and the backup destination, not just the total shown in the console. The Annual Cost Calculator can help compare deployment and storage costs.
What If the Disk Is Almost Full?
Ask IT to identify whether the local index disk, backup destination, or both are running low. Expand capacity or review retention with the data owner, then confirm another backup succeeds.
Do not manually delete JitBackup database files or objects inside its backup folders to make space. They can be shared by retained recovery points. Do not apply a storage-provider rule that independently deletes backup objects by age without checking its effect on recovery.
Protect the backup data, local index, and application configuration as part of the company's server recovery plan. Moving to another machine needs those resources and their access credentials; retaining only the installer is insufficient. See Access and data privacy.