A “completed successfully” status in the backup console means one thing: the data was written. It does not mean the data can be read, that it is complete, that it is consistent, or that anyone on the team knows how to restore it in a reasonable time. Between “we have a backup” and “we can restore the environment” lies a gap that is usually discovered at the worst possible moment.
Start with two numbers
Before anyone picks a tool or a schedule, the organisation should answer two questions, separately for each system:
- RPO (Recovery Point Objective): how much data can be lost. An hour? A day? The answers for the accounting system and for the file server with marketing material will differ.
- RTO (Recovery Time Objective): how long the system can be down. The answer “zero” is almost always untrue and always expensive.
These numbers determine backup frequency, location, and how much to invest in restore speed. Without them, a backup strategy is guesswork.
Three, two, one
The classic 3-2-1 rule has not aged; only the meaning of its last element has changed:
- three copies of the data, counting production,
- on two different media or systems, so that a failure of one does not affect the other,
- one off-site, and in practice also disconnected from the network or immutable.
The last point matters most today. Ransomware that obtains domain administrator rights also encrypts backups if it can reach them. A copy in the same domain, on a share accessible from a service account, is not a backup in the very scenario it is supposed to protect against. What is needed is a copy that cannot be modified or deleted from production: storage with a write lock, separate credentials, removable media, or a repository outside the domain’s reach.
Beyond the data
Restoring an environment takes more than data. A list of things whose absence stops a restore:
- documentation with the restore order: directory services and DNS usually come first, because everything else depends on them,
- passwords, keys and certificates, including the password to the backup system itself, stored somewhere that remains accessible when the domain is down,
- installation media and licences,
- network device and firewall configuration,
- for container environments: the repository with manifests, the secrets, and the data volumes; the cluster itself can be rebuilt, the data cannot.
The restore test
The only measure of a backup’s value is a successful restore. Tests should be scheduled, recurring, and rotate between scenarios:
- A single file or object from a specific date.
- A single virtual machine in an isolated network.
- A database to a specified point in time.
- The directory service in an isolated environment.
- The whole site: at least once a year, on paper or in a test environment, with the time measured.
Every test ends with a comparison of the actual restore time against the agreed RTO. If restoring the file server takes eight hours and the RTO is two, the backup formally exists but does not serve its purpose.
Monitor age, not status
The backup system reports job status. A far more useful metric is the age of the last successful backup of each system. A job may not start at all because somebody disabled the schedule or changed the service account password, and the console will show no errors. An alert saying “the last successful backup of system X is older than 26 hours” catches what the job list will not.
Summary
A backup is worth exactly as much as its last successful restore test. Defined RPO and RTO, a copy beyond the reach of production, the full set of things needed beyond the data, and scheduled tests with measured times turn the nightly green status into something decisions can rest on.