What recovery time should a small business backup solution support?
A small business backup solution should support a recovery time objective (RTO) that matches how long the organisation can operate without each system or data set. Critical services may require rapid restoration from readily available backups, while less essential data can often tolerate a longer recovery period.
The right recovery time objective (RTO) is the maximum acceptable time each business service can remain unavailable before the disruption causes unacceptable operational, financial, legal or customer impact. A small business should set separate RTOs for critical services rather than apply one recovery target to every system.
Start by identifying the activities that must continue during an incident. These may include access to line-of-business applications, shared files, email, customer records, finance systems, production information, telephony or remote access. For each service, assess what happens if it is unavailable and how long the organisation can work around the problem. The resulting tolerance should determine the RTO.
Classify systems by business importance. A practical approach is to group services into recovery tiers:
- Critical services: systems required for core operations, customer commitments, safety or regulatory duties. These need the shortest achievable RTO and a recovery method that does not depend solely on manually locating or rebuilding data.
- Important services: systems that affect productivity but have a workable temporary alternative. They can usually have a longer RTO, provided the workaround is documented and realistic.
- Lower-priority services: information or applications that can remain unavailable while essential work is restored. Their recovery can follow the higher-priority systems without disrupting the business’s immediate response.
Priorities should reflect dependencies as well as individual applications. Restoring a database is not enough if the application that uses it, user authentication, network connectivity, encryption keys or configuration files are unavailable. A backup plan should therefore identify the order in which infrastructure and services must be recovered, including the people and permissions needed to validate each stage.
RTO is different from recovery point objective (RPO). RTO concerns how quickly a service must be usable again. RPO concerns how much recently created data the organisation can afford to lose if the latest recoverable copy predates the incident. A solution may restore a system quickly but still fail the business’s requirements if its backup data is too old. Both objectives should be recorded for each important service.
The available recovery method must be capable of meeting the target. Restoring from a readily accessible backup may suit a service with a short RTO, whereas retrieving older copies, rebuilding infrastructure and reinstalling applications may take substantially longer. Factors to assess include:
- how much data must be restored;
- whether the backup is stored locally, online or in more than one location;
- the speed and capacity of the connection used for recovery;
- whether systems can be restored to alternative equipment or infrastructure;
- the time required to configure applications and user access;
- whether backup copies are isolated from compromised production systems; and
- who is responsible for approving and checking the recovery.
Do not base an RTO on the backup schedule alone. A copy being created regularly does not show how long it takes to locate, retrieve, restore and verify the data. Restoration may also be slower during a widespread incident, particularly where several systems share the same infrastructure or where specialist support is needed.
Testing is the only reliable way to establish whether a recovery process can meet its intended RTO. A test should measure the complete process: selecting the correct recovery point, restoring the necessary components, reconnecting dependencies, confirming that data is usable and allowing staff to carry out representative tasks. Record the elapsed time, problems encountered and any manual steps that could delay recovery. The results should be used to revise the target or improve the backup design.
RTOs should also be reviewed when the business changes. New cloud applications, additional sites, larger data volumes, remote working arrangements, new compliance obligations or changes to operational processes can alter the consequences of downtime. Keeping a current list of systems, owners, dependencies, RTOs and RPOs helps ensure that the backup solution reflects how the organisation actually operates.
For a small business, the appropriate recovery time is therefore the shortest period the business can tolerate for each service, supported by a tested recovery process and realistic technical capacity. If a system cannot be restored within its required timeframe, the gap should be addressed through better backup storage, faster recovery options, alternative infrastructure, clearer procedures or a reassessment of the business continuity plan.
A recovery time objective (RTO) should state when a service must be usable at a defined minimum level, not simply when the underlying files have been restored. For some systems, recovery can be staged: basic access may be needed first, followed by full functionality, historical data and normal performance.
Document what each stage means for the business. For example, a finance system might initially need to provide access to current records before users can complete every reporting function, while a customer database may need both record access and the ability to update information. This prevents a backup process from appearing to meet its RTO when staff still cannot carry out the required work.
Where staged recovery is appropriate, record the target for minimum viable operation and the target for complete restoration separately. Assign someone to confirm that each stage supports real business tasks, and make sure the distinction is understood by anyone responsible for declaring the service recovered.
