How long should small business backup data be retained?
Small business backup data should be retained for as long as the organisation needs to meet its operational, legal, contractual and compliance requirements; there is no single retention period suitable for every business. A practical policy typically keeps several recent recovery points, preserves longer-term copies where historical recovery or record-keeping requires it, and securely deletes backups when their approved retention period ends.
The appropriate backup retention period is determined by the age of data the business may need to restore, rather than by the storage capacity available. A retention policy should be based on documented business, legal, contractual and operational requirements, with different rules applied to different data sets where necessary.
Before setting a period, identify what could trigger a restore. Common examples include accidental deletion, an undetected data error, a disputed transaction, a failed software change, or a request to recover information from an earlier stage of a project. The policy should consider how long it may take for an issue to be noticed. If a corrupted or encrypted file can remain unnoticed for an extended period, retaining only the newest backup may leave no usable version.
Retention should also reflect the importance and lifespan of the information:
- Operational data: Keep enough restore points to deal with routine mistakes, device failures and recent incidents.
- Project data: Retain versions for the period in which changes, approvals or deliverables could reasonably be questioned.
- Financial, contractual or personnel records: Apply the retention requirements relevant to the organisation and the records concerned, rather than relying on a general backup rule.
- Business-critical systems: Consider whether older recovery points are needed to support continuity after a prolonged or previously undetected incident.
Backup retention is not the same as document archiving. A backup is primarily intended to restore systems or data after loss or damage. An archive is normally structured for long-term reference, controlled access and retrieval of specific records. If a business must preserve a record for a defined period, it should confirm that its archive or records-management process meets that need; a backup copy alone may not provide the required searchability, controls or evidential context.
A useful policy separates retention into logical stages. Recent copies support everyday recovery, while older copies are kept only where they serve a defined purpose. This approach avoids treating every file and system identically and helps control storage growth. It should also specify whether retention applies to all backup sets, selected applications, particular users, databases, virtual machines or individual categories of information.
Retention rules need clear exceptions. A legal dispute, regulatory request, investigation, insurance claim or internal review may require relevant data to be placed on hold so that scheduled deletion does not remove it. The hold should identify the affected systems and information, record who authorised it, and state when it can be lifted. Without this process, an automated retention job could delete material that the organisation is required to preserve.
Deletion at the end of the retention period should be deliberate and controlled. The policy should define who can approve changes, how exclusions are recorded, and how expired copies are removed from primary storage, secondary repositories and removable media. Where backup copies are encrypted or held in a separate environment, the business should understand how those copies are identified and disposed of. Retaining data indefinitely can increase exposure to unauthorised access and make it harder to determine which information is current.
Review the policy when the business changes its systems, contracts, regulatory obligations or working practices. The introduction of a cloud application, a new line of business, a merger, a change in accounting processes or a move to multi-site operations can alter which information must be recoverable and for how long. Retention settings should therefore be recorded alongside the backup design and reviewed as part of wider IT governance.
Finally, a retention period is useful only if the retained copies can actually be restored. Restore checks should cover older recovery points as well as recent ones, confirm that applications and permissions work correctly, and record any failures or gaps. This verifies that the chosen policy provides usable historical recovery rather than simply accumulating backup data.
Backup retention and backup frequency are separate controls. Retention determines how far back recovery can reach, while frequency determines how many recovery points exist within that period. For example, a rolling 30-day policy with daily backups provides a different level of recovery choice from a 30-day policy with weekly backups.
The policy should therefore define both the retention window and the schedule for creating recovery points. It should also state how expiry operates: in a rolling arrangement, each backup normally becomes eligible for deletion according to its own creation date, unless it has been placed on an approved hold. This makes the available recovery history predictable and helps the business assess whether the backup schedule provides enough coverage for the changes occurring between backup jobs.
