A backup report says the job completed. That is good news. It still leaves an important question unanswered: if the system stopped working this afternoon, what would your team do next? Finding a copy of the data and getting people back to work can be very different tasks.
Cloud backup preserves recoverable copies of selected information or systems. Disaster recovery is the plan and capability for restoring the technology your business depends on. Business continuity looks wider again, including people, communications, facilities, and temporary ways of working. The right conversation covers all three without assuming they are interchangeable.
Decide what needs to work first
Start with the work, not the storage size. Which applications let you serve customers, approve payments, or coordinate the team? What depends on identity services, connectivity, or a particular database? A file restored successfully may not help if the application that reads it is still unavailable.
For planning, recovery time objective, or RTO, describes the time you aim to take to restore a service. Recovery point objective, or RPO, describes the point in time you aim to recover to, which relates to potential data loss. These are targets to design and test against. They are not automatically guarantees from a backup product.
Check the scope before assuming everything is covered
A company can have a backup service and still miss a new server, a recently added cloud workload, or data stored in a location nobody reviewed. Identify the workloads, accounts, retention settings, and exclusions. Ask what happens when a user leaves and when a file is deleted long before anyone notices.
- List the systems and cloud data included, and name the person checking coverage.
- Agree on retention based on operational needs and applicable obligations.
- Review how backup administration is protected from a compromised account.
- Test restore access when the usual administrator or primary system is unavailable.
Run a restore that resembles a working day
A small file test is useful, but it does not prove that your main business application can be recovered. Pick a realistic scenario and record the steps, time, missing permissions, and dependencies. Check the integrity of restored data before returning it to use. Keep the results so the next test can show whether the plan improved.
NIST places restoration and recovery communication within the Recover function of CSF 2.0. Its small business guide encourages reviewing backup integrity and deciding restoration priorities. RIKR’s practical recommendation is to turn those priorities into a sequence someone can follow when the usual systems are not there.
Source: NIST CSF 2.0 Small Business Quick-Start Guide
Where RIKR fits
RIKR uses Axcient for cloud backup across supported Microsoft 365 or Google Workspace data and supported server or workstation workloads. The configured scope, retention, and recovery options should be confirmed for your environment. Retention policies can support required compliance needs, but a backup service by itself does not establish compliance.
We want the answer to “Can we get it back?” to include the people, steps, and dependencies involved. That is a more useful result than discovering during an outage that everyone expected someone else to know the plan.
Related: practice the plan with a tabletop exercise
Explore RIKR managed IT support
Written by Joshua Price
Back to the blog