What recovery objectives should managed backup support?

Managed backup should support recovery objectives that are set per workload, based on business impact, dependencies and the consequences of disruption. The right approach is to identify which services must be recovered first, define acceptable data loss and downtime for each one, then confirm that the backup design and recovery process can meet those requirements in practice.

Start with business processes rather than backup schedules. A database, file share or virtual server is important because it supports a business activity. Map each technical system to the processes that depend on it, such as order processing, finance, production, customer communications or document access. This prevents recovery planning from treating every workload as equally important and helps establish a sensible recovery sequence.

For each workload, document the following:

• the business process it supports;
• the maximum acceptable age of recovered data;
• the required restoration deadline;
• the people responsible for authorising and carrying out recovery;
• the systems, accounts, network services and data it depends on;
• the consequences if the objective is missed; and
• the evidence needed to confirm that recovery is complete and accurate.

Use workload tiers to avoid applying one target everywhere. A customer-facing application, production control system or live transactional database may need a more demanding recovery design than an archive, historical report repository or rarely used file store. Tiering can also account for systems that are important but can be recreated from source data, compared with systems where lost information cannot be reconstructed.

A practical classification might include:

• Critical workloads: systems whose loss would stop essential operations or create material financial, contractual or regulatory consequences.
• Important workloads: systems that can tolerate a controlled interruption but are needed for normal operations.
• Non-critical or archival workloads: data that is still valuable but can be restored after higher-priority services are operational.

The classification should be agreed with business owners, not determined solely by the IT team. A technically complex system is not automatically the most important, and a simple file share may contain information that the organisation cannot replace.

Consider the difference between backup frequency and recoverability. More frequent backup jobs can reduce the amount of recent information that may be missing after an incident, but they do not by themselves establish how quickly a service can be made usable. Restoration time depends on factors such as data volume, storage performance, available infrastructure, application configuration, access permissions and the order in which dependent systems are recovered.

Recovery objectives should therefore be tested against the complete service, not just the backup repository. For example, restoring a database is not necessarily enough if the application server, authentication service, network configuration or encryption keys are unavailable. A recovery plan should identify these dependencies and specify whether they are backed up, documented for rebuilding, or provided through another recovery arrangement.

Define what “recovered” means. The objective should refer to a usable business service rather than the point at which a backup file has been copied. Depending on the workload, recovery may require:

• restoring the data and application components;
• reconnecting users or devices;
• reapplying permissions and security controls;
• checking that integrations and scheduled processes work;
• validating data consistency; and
• obtaining approval from the relevant business owner.

For some systems, a temporary read-only service may be an acceptable first stage, followed by full restoration. For others, the service is not considered recovered until transactions, integrations and normal user access have been verified. Recording this distinction makes the objective measurable and prevents an apparently successful restore from masking an operational failure.

Set objectives for different incident types. Recovery from accidental deletion may involve restoring an individual file or database record, whereas recovery from ransomware, hardware failure or a major site incident may require an entire environment to be rebuilt. The same workload can therefore have different recovery procedures, dependencies and resource requirements depending on the cause of the disruption.

Security incidents require particular care. Recovery plans should account for the possibility that connected systems, administrator credentials or backup management functions have been compromised. Clean recovery points, separate administrative controls and a documented process for validating the environment before reconnecting it can be as important as the restoration operation itself.

Check that the objectives are technically achievable. A managed backup design should be assessed against the selected targets by reviewing backup frequency, retention, storage capacity, recovery infrastructure, network capacity and the expected size of each workload. Where rapid restoration is required, options may include maintaining suitable standby resources, using staged recovery, prioritising essential data or restoring services in a defined order. The chosen design should reflect the business value of the workload rather than assuming that the same method suits every system.

Recovery testing is the evidence that the objectives are realistic. Tests should cover representative workloads and should measure both the age of the recovered data and the time taken to reach an agreed usable state. They should also check application dependencies, permissions, data integrity, recovery documentation and the involvement of business users. A test that only confirms that a backup archive can be opened provides limited assurance about operational recovery.

Objectives should be reviewed when the organisation changes. New applications, larger data volumes, altered working practices, acquisitions, site changes and new compliance obligations can all affect the required recovery design. Review the objectives after significant system changes and use test findings, incidents and near misses to revise them where necessary.

A managed backup service can support this process by monitoring backup activity, retaining recovery points according to the agreed policy and helping coordinate recovery testing and documentation. The important decision remains the business-led definition of what must be recovered, in what order and to what standard; the backup arrangement should then be selected and maintained to support those documented requirements.