How long should server backups be retained?
There is no universal retention period for server backups: retain them for as long as the data is needed for operational recovery, legal or regulatory obligations, and protection against delayed threats such as ransomware. Your policy should define retention periods for recent, older and long-term backups, then review them against business requirements and available storage.
Server backups should be retained under a documented schedule that reflects the business value, age and recovery purpose of the data. Retention is not simply a matter of keeping every backup indefinitely. It determines which restore points remain available, when older copies can be removed, and how the organisation balances recoverability, storage capacity, privacy and governance.
A practical policy normally separates backups into retention tiers:
- Short-term recovery copies: These support the recovery of recently changed or deleted files, recent configuration changes and current server data.
- Medium-term copies: These provide restore points from earlier periods when an issue was not discovered immediately, such as a corrupted database record or a slowly developing malware infection.
- Long-term copies: These are kept for historical reference, contractual requirements, audits, investigations or records that the business may need to retrieve after the normal operational backup cycle has passed.
The length of each tier should be based on how far back the business may need to recover, rather than on the backup software’s default settings. Consider the time it takes to discover different types of incident. An accidental deletion may be identified quickly, while incorrect data, a compromised account or a damaged application may remain unnoticed for considerably longer. The retention schedule needs to leave an appropriate restore point before the problem began.
Retention should also be set by data type and business process where necessary. A database supporting current operations may need a different schedule from a file share containing completed project records. Financial information, customer records, design files, email data and system configuration may each have different legal, contractual or operational requirements. A single period applied to every server can either remove useful recovery points too soon or retain data that no longer needs to be held.
Do not treat backups as a substitute for an archive or records-management system. A backup is primarily designed to restore systems and data after loss or disruption. It may contain temporary files, obsolete versions, system metadata and deleted information that should not be preserved as a permanent business record. If the organisation has a separate archive policy, the backup policy should identify which system is responsible for long-term preservation and how the two processes interact.
Some retention requirements begin with an event rather than a calendar date. For example, a project-related backup may need to remain available until a project has been completed and associated obligations have expired. A copy relevant to an investigation, dispute or legal hold should not be deleted simply because its normal expiry date has passed. The retention process should allow authorised staff to suspend deletion and record why the hold exists and when it can be released.
Privacy should be considered alongside retention. Keeping personal or confidential information for longer than necessary increases the amount of data that could be exposed if the backup environment is accessed improperly. The policy should define who can retrieve retained copies, how access is logged, how encryption keys are managed and how expired backup data is securely disposed of. Deleting data from the production server does not necessarily remove it from existing backup sets, so deletion and retention rules need to account for those copies.
The technical design of the backup system affects how retention can be applied. Incremental backups may depend on earlier full or incremental copies, while snapshots and deduplicated repositories may share underlying data blocks. Deleting an apparently old restore point can therefore affect other recovery points if dependencies are not handled correctly. Retention jobs should be configured and monitored with an understanding of the backup chain, replication process and repository architecture.
A sound policy should document:
- the retention period for each backup tier and data category;
- the event or date from which retention is measured;
- which copies are held on primary, separate or offline infrastructure;
- who may approve exceptions, legal holds and early deletion;
- how expired data is removed and how that removal is recorded;
- how the schedule is reviewed when systems, contracts, regulations or business processes change.
Retention settings should be checked against the actual restore points available in the repository, not just the policy document. A repository may appear to retain data for a particular period while failed jobs, capacity limits, dependency errors or automated cleanup have reduced the usable history. Review reports should confirm that expected restore points exist and that older copies can be identified and removed without affecting required recovery options.
For a small or medium-sized organisation, the most useful approach is usually to begin with business-critical systems and document the recovery history each one requires. The resulting schedule can then be implemented in the server backup platform and reviewed whenever the organisation changes its applications, data classifications or compliance obligations.
A retention period is useful only if the corresponding restore points are protected from alteration or premature deletion. A backup that is scheduled to remain available for a year may not meet that requirement if an administrator, malware or an automated cleanup process can remove it before the period ends.
For each retention tier, confirm how the backup platform prevents unauthorised changes and how expiry is enforced. Depending on the repository design, this may include write-protected or immutable copies, separate administrative permissions, offline media or an approval process for deletion. The controls should be documented alongside the retention period, with records showing when copies were created, placed on hold, expired and removed.
This distinction is particularly important for long-term restore points. Retaining a copy for longer does not by itself preserve its evidential or recovery value if its contents, metadata or deletion status cannot be trusted. Retention reviews should therefore assess both how long a backup remains available and who or what can change it during that period.
Review Your Server Backup Retention Policy
If your current retention schedule has not been matched to your recovery requirements, speak to S2 Technology Group about reviewing your server backup policy and restore-point coverage. This can help identify gaps in retention, access controls and recovery planning before the policy is next relied on.