Backups: how to check that your business can actually restore

Define the recovery scenario

Describe a specific event: a deleted folder, a damaged website database or the need to rebuild an entire environment. Each scenario needs different data, permissions and time. A file copy may not include every setting required to make the application work again.

List the essential files, databases, configuration and keys. Agree how much recent work the business could afford to lose and how long the service could remain unavailable. These answers help define the backup frequency and the recovery objective. Identify who will decide that restoration is complete.

Separate continuity from historical recovery

Synchronisation to another server can help a service continue operating, but it can also copy an unwanted deletion or corrupted data. Establish whether a usable earlier version exists and how far back that history extends.

Check where backups are held and who can delete them. CISA recommends protected backups and regular availability and integrity testing as part of ransomware preparation. The implementation should reflect your environment, including access controls and the procedures needed to reach a protected copy during an incident.

Prepare an isolated exercise

Select a backup with a known date and restore it into a test environment. Before starting the restored application, check whether it can send email, charge customers or update external systems. Control those functions so that the exercise does not create real transactions.

Provide sufficient storage and the necessary permissions. For encrypted backups, verify that authorised staff can retrieve the required keys through a secure, documented process. An exercise that stops because a key is missing is still a valuable finding: it exposes a recovery obstacle before a real incident.

Verify the functions people need

Open representative files and check that the application can use its restored database. Test the operations that matter to the business, such as viewing orders or finding documents. Files being present on disk does not by itself demonstrate that the whole system is usable.

• What data date was recovered?
• How long did retrieval, restoration and verification take?
• Which steps required manual intervention?
• Who confirmed that critical data and functions were available?

Record the outcome and repeat

Record the backup used, the checks performed, the elapsed time and any required corrections. Repeat the exercise after significant application or infrastructure changes, and schedule regular reviews appropriate to the service's importance. Keep the instructions available to the people expected to respond during an incident.

When discussing backups with FastVPS, define the protected data, retention period, restoration request process and responsibility for the final application check. This connects the backup service with a procedure your business can follow when recovery is needed. Review the result against the original recovery objective and address any gap in the next service review.