Backup and recovery testing
A restore someone can point at
Backup and recovery testing means taking a copy you already keep and turning it back into a system, or a set of records, that a person can use. The result is a date, an owner, a system name, and whether the restore was usable. Anything short of that is a claim about the backup product. We work around your normal operations, and we'll need access to the right areas and the right people while we do.
What a recovery test is
We pick one system the week depends on. An order path, a file store, an identity export, a database the application cannot run without. We do not test every job in the backup console. A single honest restore teaches more than a grid of jobs nobody has opened.
The test is scheduled so it does not pretend to be a surprise outage. Production stays up unless you have a separate, written decision to do otherwise. This page is not a failover exercise and not a disaster declaration.
The last restore
We ask when this system was last restored, who did it, and where the record of that restore is. If nobody can answer, the last restore did not happen in any way the company can trust. That is the start of the engagement, not a reason to buy another tool.
We need access to the backup system and to the person who would run the restore on an ordinary workday. If that person is a vendor, we need the person inside your company who can direct the vendor, and we need the vendor’s step written down. A phone number with no written step is not a restore path.
Copies that only one administrator can open are treated as a single point of failure. We write who else can reach them. We do not accept “it is in the password manager” unless someone besides that administrator has opened it.
Time and the owner
The report states how long the restore took and what was missing at the end: a configuration, a key, a DNS name, a file that was never in the job. We do not convert that time into a promise about the next incident. The next incident will not match the test exactly. The test still beats a blank.
The owner of the restore is a current person. If the only person who has done it has left, the test is the way the next person learns, and the playbook is updated with what they actually did. See ransomware readiness when the reason for the test is that incident type.
You receive the record. It stays with you. We do not keep a copy of your data as part of the engagement, and we do not need a standing login after the test is written up.
What this is not
We will not sell you a new backup product as the opening move. If the current path cannot restore, the finding says that. Replacing the product is a later decision, scoped on its own if you ask.
We will not quote a percentage of systems you should be able to recover, and we will not sign a recovery-time number you can show a customer. Those sentences need a test history you either have or you do not.
We work around your normal operations, and we'll need access to the right areas and the right people while we do. Once you approve it, we'll need access to the right areas and people. The person who can run the restore has to be available. We will not click through a console alone and call it your test.
Questions
What counts as a recovery test?
A restore onto a system someone can point at, with a named owner and a time written down. A backup job that reports success, and has never been restored, is not a test. We need access to the backup and to the person who would run the restore.
Will you install a new backup product?
Not as this engagement. We test the restore path you already have. If that path cannot produce a usable system, the finding says so. A new product is a later decision, scoped separately if you want it.
Contact
Task us with the system you hope the backup covers.
If a restore was attempted and failed, that note is enough to start. We work around your normal operations, and we'll need access to the right areas and the right people while we do.