A successful backup report establishes that a job ran. It establishes nothing about whether the data can be brought back, how long that would take, or whether an attacker could have destroyed every copy first.
An organization is encrypted on a Monday morning. The backup dashboard has been green for eleven months. By Wednesday they are rebuilding from scratch, and the post-incident review records that backups were in place.
Both statements are true. Backups were in place, and they were of no use. The gap between those two facts is where most recovery failures live, and it is almost always visible beforehand to anybody who asks five questions.
Five questions with factual answers. Each one you cannot answer is itself the answer, and questions two and three decide the outcome.
This is the first distinction and it is worth being blunt about, because the terms are used interchangeably by people who should know better and by vendors who benefit from the confusion.
A snapshot is a point-in-time image held on the same platform as the production data. It is fast to take, fast to restore from, and it shares the fate of the platform holding it. An attacker who reaches that platform removes both, and they will, because destroying the recovery path is what makes the extortion work.
Replication is continuous copying to a second location. It protects against losing a site or a platform. It also replicates deletion and encryption faithfully, and frequently faster than anybody notices. A replicated copy of encrypted data is encrypted.
Both are useful. Neither is a backup, and recording either as one in a questionnaire or an insurance application is a representation that will not survive being tested.
The four events in the columns are the four ways organizations actually lose data. Only the last row survives all of them.
Could somebody holding your production administrative credentials delete or encrypt your backups?
If the answer is yes, you do not hold backups. You hold copies, and they will be gone before you know you need them. Modern ransomware operators spend days inside an environment before encrypting anything, and a substantial part of that time is spent finding and destroying the recovery path. It is not an afterthought; it is the step that determines whether the ransom gets paid.
Isolation is achieved by immutability enforced at the storage platform, by a separate account with credentials that do not exist in the production environment, by offline media, or by an equivalent mechanism. What does not achieve it: a different folder, a different server in the same domain, or a permission that an administrator can change.
The test is not whether the backup platform has a password. It is whether the credential that runs your estate, or any credential it can obtain, can reach the backup data.
In most environments that have not addressed this deliberately, the answer is yes, and nobody has ever checked.
Retention is usually set by what the storage costs and by what somebody assumed would be enough for accidental deletion. Thirty days is a common figure and it is reasonable for its original purpose, because a deleted file is noticed within days.
It is not reasonable for compromise. The period between an intruder getting in and somebody noticing is measured in weeks. If your retention is thirty days and the intrusion began forty days ago, every copy you hold was taken after the attacker was already inside.
Restoring from a copy taken after the compromise began reinstates the attacker, usually within hours. The second incident is harder to explain than the first.
The practical consequence is that retention should be set against observed dwell time rather than against convenience. Ninety days covers most cases. Whatever figure you choose, the decision should be recorded with the reasoning, because the alternative is discovering the number during an incident.
The backup report tells you a job completed. It does not tell you the data is readable, that it is complete, that the application will accept it, or how long the restore would take.
Each of those has been the thing that failed in a real recovery. Media that reads but produces a corrupt database. A backup missing the configuration needed to rebuild the system around the data. A restore that works and takes three days against a recovery objective of four hours, which is a failure even though the data came back.
Most organizations that do test record that a test happened. That is not the useful part.
The two fields that matter are the time achieved against the objective, and whether the person performing it normally operates the backups.
The second of those is the one people resist and it is the more revealing. The regular operator knows the undocumented steps, the credential that is not written down, and the order things have to come back in. They will complete the restore without noticing that none of it is recorded anywhere.
Have somebody else do it once a year. If they cannot, your recovery time objective is conditional on one person being available, which is a continuity finding as much as a security one.
Restoring after accidental deletion and restoring after an intrusion look similar and are not. The differences are worth establishing before you need them.
None of this requires new software and none of it requires a consultant. It requires establishing five facts about an arrangement most organizations have never examined, because the dashboard is green and nothing has gone wrong yet.
Our backup and recovery policy is free, editable, and built around the two clauses in this piece. It includes a restore test record, a recovery runbook, and an evidence appendix mapping each requirement to the artefact that demonstrates it.
If you cannot answer question two
Complete our free readiness assessment, send us the result, and we will spend forty-five minutes going through it at no charge. If our view is that you can close this yourself, we will say so and tell you how.