What should a server backup recovery plan include?

A server backup recovery plan should turn business continuity requirements into specific recovery criteria, technical instructions and decision points. It needs to explain how the organisation will determine the scale of an incident, select an appropriate recovery method, confirm that restored systems are safe to use and return normal operations to control.

Define recovery objectives

Set a recovery time objective (RTO) for each important server or service: the maximum acceptable period before it is available again. Set a recovery point objective (RPO) as well: the maximum acceptable amount of recently created data that could be lost. These objectives should reflect how the business operates. For example, a database supporting active transactions may require different recovery criteria from an archive server.

Record the business owner for each service and the consequences of missing its RTO or RPO. This makes it easier to resolve competing priorities during an incident and prevents technical assumptions from determining business-critical decisions.

Document the recovery scenarios

The plan should cover more than accidental file deletion. Useful scenarios include:

• Hardware failure affecting a physical server.
• Storage failure or corruption.
• Ransomware or another form of malware.
• Human error, including an incorrect configuration change.
• Loss of a site, power, network connection or virtualisation host.
• Failure of a cloud or remote access dependency.

Each scenario may require a different response. A deleted file might be recovered without rebuilding a server, whereas a compromised system may need to be isolated, rebuilt from a trusted source and restored only after its security has been checked.

Include technical recovery prerequisites

A backup is only useful if the organisation can access the tools and information required to use it. The plan should identify the location of backup consoles, encryption keys, recovery media, virtualisation tools, licences, configuration exports and relevant documentation. It should also explain how these items can be accessed if the usual administrator accounts, domain services or production network are unavailable.

Record server specifications, operating system versions, storage layouts, application dependencies and network settings. Include details of required drivers and any special procedures for databases, directory services, mail systems or line-of-business applications. Configuration information should be kept separately from the server being protected so that a single failure does not remove both the system and the instructions for rebuilding it.

Set rules for clean recovery

The plan should state when a restore must be performed into an isolated environment rather than directly into production. This is particularly important after suspected malware, unexplained data corruption or an administrator account compromise. Recovery steps should include checking the source backup, scanning restored systems, applying appropriate security updates and changing credentials that may have been exposed.

Do not assume that the newest recovery point is always the correct one. The plan should explain how to select a point before the incident, how to compare available versions and how to handle uncertainty about when corruption or compromise began. For encrypted backups, document how authorised staff obtain the decryption material without placing keys in the same compromised environment.

Describe the restoration workflow

Use a numbered runbook that a suitably trained person can follow without relying on informal knowledge. It should cover:

1. Declaring the incident and recording the systems affected.
2. Preserving evidence where a security incident may have occurred.
3. Isolating affected equipment and preventing further changes to backup data.
4. Selecting and validating the intended recovery point.
5. Preparing replacement infrastructure or an isolated recovery environment.
6. Restoring the operating system, applications, data and configuration in the required sequence.
7. Testing authentication, connectivity, application functions, data integrity and user access.
8. Obtaining business approval before returning the service to normal use.
9. Recording actions, timings, issues and any data that could not be recovered.

Where a process depends on a particular console, script or command, include the relevant instruction and its prerequisites. Avoid relying solely on screenshots, as interfaces change and images may not explain why a step is necessary.

Assign authority and communication duties

Recovery plans should distinguish between people who approve decisions, people who carry out technical work and people who verify that a service meets business needs. Include deputies for key roles, escalation routes and the authority to stop an unsafe restoration.

Set out how staff, customers, suppliers and other stakeholders will be informed when a service is unavailable or restored. Communications should avoid disclosing sensitive technical details and should identify who approves external statements. Keep an incident log so that decisions and changes can be reviewed afterwards.

Plan for dependencies and temporary operation

Restoring one server may not restore the service if it depends on DNS, identity services, certificates, databases, file shares, network routes or third-party connections. Map these relationships and state how each dependency will be made available during recovery.

Where full restoration will take time, document acceptable temporary arrangements, such as read-only access, manual processing or a reduced service. Define who can authorise those arrangements and how data created during the temporary period will be reconciled with the restored system.

Test and maintain the plan

Testing should demonstrate more than the existence of backup jobs. A useful exercise restores representative systems or data, follows the documented runbook and records the actual decisions, prerequisites and problems encountered. Test both ordinary recovery and scenarios in which production access, a primary administrator account or the original hardware cannot be used.

Review the plan after infrastructure, applications, suppliers, staff responsibilities or security controls change. Remove obsolete credentials and instructions, confirm that recovery contacts remain appropriate and update the plan when a test exposes an undocumented dependency. S2 Technology Group can help organisations assess server backup arrangements and develop practical recovery procedures as part of broader managed IT support and cyber security planning.