Backups and system recovery: what to agree

Agree what needs to be recovered

A website or application may need its database, files, code, configuration and environment details. Some data may live in other services, such as email, external file storage or an ordering system.

List these elements and identify which the backup actually covers. Check whether the database and files can be restored to a consistent state. A database backup alone will not restore a photograph or document missing from the file backup.

Discuss data loss and downtime

Two questions help determine the right approach: how much new data can the business afford to lose, and how long can the system be unavailable? A website updated once a month has different needs from an application collecting orders all day.

If the latest valid backup is from the previous night, newer enquiries may not be included. Downloading a large archive and preparing infrastructure may also take a substantial share of recovery time. Backup frequency and expected recovery time need to be considered separately.

Check who has access to backups

Agree where backups are stored, how long they remain available and who can retrieve them. Consider failure of the entire hosting account or compromised system access. A backup in the same location under the same credentials may be affected by the same incident as the original.

Limit access and choose storage appropriate for the contents. A backup of customer data still contains customer data. Do not accidentally copy it into a public directory or an unprotected test environment.

Run a recovery test

Use an isolated environment for the test. Check that the system starts, files are accessible and key functions work. Before starting the restored copy, disable operations that could send real messages, payments or data to production systems.

Walk through agreed scenarios: signing in, reading data, an important form, content editing or order handling. Record the backup used, time taken and any missing elements. A recovery test tells you more than a message confirming successful archive creation.

Agree how recovery decisions are made

Before restoring, decide which point in time to recover to and how to handle newer data. Rolling back a database can remove valid changes made after the backup. You may need to preserve them separately or restore only a selected component.

Record who is responsible for the decision, hosting, application and result checks. Repeat the test after significant changes to infrastructure or data storage. One successful test does not establish readiness for every future failure scenario.

As part of support and development, agree what backups cover and how they will be checked, as well as how they are created. Start by reviewing what is already protected and what your company needs to get back to work.