In brief: almost every company has a backup. Far fewer know how long a restore takes and whether it actually works. The difference between the two situations is measured in days of stopped business, and it is usually discovered on the worst possible day.
The useful question is not “do we have a backup”
The question that matters has three parts: how old the last usable copy is, how long it takes to bring the service back, and who confirms that the restore succeeded. A green report from the backup software answers none of them. The report says the job ran, not that the data can be brought back in a state where people resume their work.
Checking this is neither expensive nor lengthy. The reason it gets postponed is that nobody wants to find out the answer during a busy week.
What only comes to light at the first real restore
- The job runs, but skips files. Locked files, shadow copy errors and entries marked as warnings pile up in logs nobody reads. The job finishes with partial success and the report stays green.
- The server is backed up, the database is not. A file-level copy of an open database produces a file that will not start. Databases need their own backup method, consistent with their transactions.
- Every copy sits on the same network. If the only copy is on a NAS in the same building, reachable with the same accounts, an encryption incident reaches it in the same minute as the original data.
- Microsoft 365 is assumed to be backed up by Microsoft. We return to this below, because it is the most frequent misunderstanding.
- The keys and passwords are missing. The copy is properly encrypted, and the key is inside the system that has just disappeared, or with a colleague who no longer works at the company.
- There is nowhere to restore to. No spare equipment, licences tied to the old hardware, and a new server carries a delivery time.
- The restore takes longer than the business can absorb. Large volumes brought back from a remote location depend on bandwidth. Calculate the duration in advance, not during the incident.
RTO and RPO: two numbers management decides
RPO is the amount of data you can afford to lose, expressed in time: the distance back to the last usable copy. RTO is the time within which the service has to be working again.
Both are business decisions, not technical ones. They are set separately for each system, because the systems are not worth the same: invoicing down for a day costs something different from the project archive being unavailable for a day. Once set, these two numbers drive the architecture and the budget, in that order. Without them, any backup solution is an arbitrary choice and the conversation about price has no reference point.
The 3-2-1 rule and what has been added to it
| Digit | What it means in practice |
|---|---|
| 3 | Three copies of the data: the one in use and two more |
| 2 | On two different types of media or two different technologies |
| 1 | One in a physical location other than the office |
| 1 | One offline or immutable, which nobody can delete or alter during the retention period |
| 0 | Zero errors when the restore is verified |
The first three digits are well known and usually followed, at least partly. The last two are the ones most often missing, and they are the ones that make the difference against an attack and against a silent failure.
What a serious restore test looks like
- Pick a system, not a file. Restoring one document proves that restoring one document works.
- Restore into an isolated environment, separate from the production network, so the test cannot cause a problem of its own.
- Start the application and check it with the people who use it. Validation comes from users who recognise the data, not from a service that starts without an error.
- Time everything. Real time runs from the decision to a working service and includes hunting for passwords, downloading the data and reconfiguring.
- Write down what was missing. An undocumented step, a licence, an expired certificate, an account without rights. That list is the most valuable result of the test.
- Repeat it regularly, quarterly for critical systems and annually for the rest, and after any major infrastructure change.
Record the result in writing, with the date, the measured duration and the deficiencies found. A test without a report cannot be shown to anyone and will be forgotten by the next one.
Microsoft 365 and shared responsibility
Microsoft is responsible for the availability of the service and for the infrastructure behind it. The content in Exchange, SharePoint, OneDrive and Teams remains your company’s responsibility. The default retention covers short-term accidental deletion and is useful, but it has time limits and was never designed as a backup.
The situations it does not cover are precisely the expensive ones: a compromised account deleting systematically, a retention policy configured wrongly, the licence of a departing employee being released, a migration done in a hurry. These need a separate copy, with another provider or on your own equipment. We wrote separately about how responsibility is divided between provider and company in the article on private and public cloud, and the licensing and administration side is covered on the Microsoft 365 and cloud page.
Ransomware changes the requirements
Attackers go for the backups first, because a company that can restore does not pay. For that reason the requirement has moved from “a copy exists” to “a copy exists that the attacker cannot touch”.
- Immutable storage or an offline copy, taken off the network.
- A backup console with authentication separate from domain accounts and with two-step verification.
- Alerts on mass deletions and on changes to retention policies.
- Logs kept somewhere other than the system that produces them.
If your company falls within the scope of NIS2, business continuity and backup management are listed explicitly among the risk-management measures, and the annual self-assessment covers them. The restore test then becomes a document you have to present.
Six questions for your IT officer or provider
- When was the last full restore tested, and how long did it take, measured?
- Which systems are not backed up right now, and why?
- Where is the off-site copy and who has the right to delete it?
- If we lose the main server today, what equipment do we restore onto?
- Who receives the alerts when a job fails, and what happens the next day?
- Do we have a written recovery procedure, with the steps, the accounts and where the keys are kept?
If the answer to the first question is that a full restore has never been tested, the rest of the discussion is about hypothetical costs.
What we do and what stays with you
PRO IT designs the backup scheme starting from the RTO and RPO agreed with you, installs and administers the solution, monitors the jobs daily, runs scheduled restore tests with a written report and keeps the recovery procedure up to date. All of this is part of the IT maintenance and support service. If you do not know where to start, the IT audit establishes what exists today, what is missing and in what order it should be fixed.
The decisions that are not technical stay with you: how long each system can be down, what budget the second location gets, and who has the authority to declare the incident and start the restore.
If you do not have a restore test report from the last twelve months, that is the first thing to schedule.
