A “backup completed” message does not prove that the business can get back to work. The critical test is whether the right data exist, whether they can be restored without errors and whether the team knows who performs the steps when the primary system is unavailable.
A backup strategy should begin with operations rather than storage space. Which files, accounts, settings and systems are essential for serving customers? How recent must the last available version be, and how much downtime can be tolerated?
Define two time limits
The recovery point objective (RPO) describes how much recent data may be lost in an incident. The recovery time objective (RTO) describes how long restoration may take. These are not targets for IT to invent in isolation: every service needs agreement with the team that will experience the interruption. An e-shop, accounting records and old advertising material may require different priorities.
Map what needs to return together
Do not copy only individual files. Record the dependencies a function needs: accounts, settings, keys, permissions, integrations and contact information. For every item, note its owner, backup location, capture frequency and restoration method. Keep recovery information somewhere that cannot be accessed through the same account that may have been compromised.
Protect and verify the backups
Restrict who can create or delete backups, record important changes and check that all copies are not in the same location with the same permissions. A copy that immediately synchronises corruption or deletion is not necessarily a safe recovery point. Isolation, retention of previous versions and access control need to be considered alongside availability.
Test restoration in a safe environment
Choose a representative file or system and restore it in a test environment. Check not just whether the process finishes, but whether data open, accounts have correct permissions and key workflows operate. Measure actual duration and record where the team needed information missing from the runbook.
Write a simple playbook
Include who decides to begin restoration, where communication exists outside the affected system, the order in which functions return and how the service is confirmed safe to resume. Run a small scenario and ask someone else to follow the instructions without verbal help.
Put the test on the calendar
Keep the date, test scope, outcome, actual observed RTO/RPO and corrective actions. Retest when a critical system, supplier or team changes. If there is no time to test every system, start with those whose loss stops the main service provided to customers.
This recovery framework and test checklist are original practical guidance developed by DigitalNow, not a technical assessment of a provider.