Almost everyone has a backup. Significantly fewer have actually tried using it. The difference only becomes apparent when it truly matters, and by then it is too late to discover that the job stopped in March or that a database was never included in the schedule.
What usually comes to light during the first test:
A scheduled job has been silently failing for a long time because the alert was sent to an address that is no longer monitored. A system has been added to production but never to the backup schedule. A database is backed up at the file level, which results in a file but not a usable database.
Neither of these is unusual. Both stay invisible until someone actually tries to restore. That’s also why the 3-2-1 rule calls for multiple copies — a single chain that fails silently isn’t enough.
The difference between having data and being up and running
Being able to restore a file doesn’t mean the business is operational. Systems need to be started in the right order, integrations have to come back online, and permissions need to work.
That’s why two numbers matter. RTO is how long it can take before you’re up and running again. RPO is how much data you can afford to lose. Without them, it’s impossible to determine whether your backup is reasonable or severely undersized.
This is what a sensible test looks like
Restore to an isolated environment, not over production. Include the systems you actually need to invoice and deliver—not just the file server. Measure the time from the decision to a functioning operation, not from the start of the restore.
Document what went wrong—because something always goes wrong the first time—and fix it before the next test. A test that goes perfectly the first time usually means you tested too little. The test is part of your incident management, not a separate exercise.
What a test report should include
The date and who carried out the test. Which systems were included and which were deliberately left out. The time from decision to operations being back up and running, not just to the restore being completed.
What went wrong and what has been fixed since then. The next scheduled test.
It’s a single page of paper, and that’s the page that gets requested during an audit, a procurement process, or when the insurance company starts asking questions.
How we make sure it works
With Savecore BaaS, jobs are monitored and deviations trigger alerts, so a silent failure doesn’t go unnoticed for months. The copies are immutable and stored in our own data centers in Sweden.
For organizations that need to be able to show hard numbers — during an audit, a procurement process, or to meet NIS2 requirements — we complement this with DRaaS, where the recovery time is contractually agreed and tested regularly.
Frequently asked questions about tested backup
How often should we test?
At least annually for the entire environment, and always after major changes to the system landscape. Partial tests of individual systems can be performed more frequently.
Can testing be conducted without disrupting production?
Yes. Restoration is performed to an isolated environment that does not affect live operations.
What is a reasonable recovery time?
That depends entirely on how much downtime costs you per hour. Calculate that first, then set your target accordingly.
Do you know how long a restart takes?
We review your critical systems and provide a concrete figure, rather than an estimate.