Decide what needs to be recoverable

Start with information the business depends on, wherever it is stored. Include the devices and services involved, rather than assuming everything important lives on one server. ACSC recommends choosing backup scope according to the importance of the data and the impact of losing it. How to back up your files and devices

A backup is a copy maintained for recovery after loss or corruption. Synchronisation keeps locations aligned and may propagate unwanted changes. Retention determines how long recoverable versions remain available. Ask what these functions actually provide in your chosen service; the label “cloud storage” does not answer those questions.

For an application, files may be only part of the recovery picture. Settings, compatible software, permissions and other dependencies can matter too. Guidelines for system management

Protect the recovery route

Consider who can alter or remove backup copies and how the credentials or keys needed for recovery are managed. Protecting those copies is part of making them useful when the normal environment has a problem. The appropriate isolation and retention arrangements depend on the workload and risks. Guidelines for system management

Terms such as snapshot, version history and immutable storage describe particular features. Check their actual scope and limitations before treating them as evidence that a recovery requirement is met. No feature name establishes a recovery guarantee.

Plan a safe restore exercise

A restore exercise needs an authorised owner, a defined scope and a destination where the work will not overwrite live information. The person responsible for the application should agree how usability will be checked. Restoring readable files is different from demonstrating a working service.

For an application, agree with its owner which data, settings and supporting components must be recovered together to a consistent point. Check that the recovered state supports the intended task; opening individual files alone does not demonstrate that the application is consistent. Guidelines for system management.

Discuss the recovery point and acceptable interruption with the business owner, and record the observed result separately. NIST’s contingency-planning guidance distinguishes recovery objectives from the planning needed to support them. Contingency Planning Guide for Federal Information Systems

An invented shared-files example

An office plans to restore a set of non-sensitive example documents into an isolated location. The proposed checks include whether the selected versions are present, whether authorised users can open them, and whether any needed dependencies were missed. The exercise record would capture elapsed time, problems and follow-up actions.

This example has not been executed. It does not demonstrate recovery of an entire application, and it is not permission to restore over production data.

Before arranging a test

  • Identify the business purpose, owner and selected backup point.
  • Agree an isolated destination and authorised access.
  • Confirm required software, keys and dependencies.
  • Define checks for integrity, completeness and usability.
  • Record actual results, limitations and corrective actions.
  • Assign responsibility for safe clean-up of test material.

Use a backup or application specialist to turn this planning checklist into a procedure for your environment. Required retention and disposal decisions may also need legal or privacy input.

Optional depth: distinguish restore from recovery

A restore retrieves material; recovery returns a useful service. The wider business may still need dependent systems, staff and reconciliation work before it can operate. Test frequency, application consistency and suitable recovery targets depend on business circumstances. Keep broader continuity decisions separate from an individual backup test.

  • Recovery planning and business continuity — Set broader business recovery priorities.
  • Cloud versus on-premises responsibilities — Clarify provider and customer responsibilities.
  • What an integration involves: data, permissions and failure recovery — Consider dependent systems and reconciliation.