Almost every organization I meet can tell me they have backups. Far fewer can tell me the last time they restored something, how long it took, and whether the result actually worked. Those are different statements. The first is a belief. The second is evidence.
A backup you have never restored is a guess. It might be complete. It might be missing the folder someone created last spring. It might take four days to bring back over your internet connection. You find out which on the worst day of the year, unless you find out on purpose first.
RPO and RTO in plain language
Two terms come up in every recovery conversation, and they are simpler than they sound.
- Recovery point objective (RPO) is how much work you can afford to lose, measured in time. If your accounting system is backed up every night, a failure late in the afternoon could cost you most of a day of entries. Your RPO is roughly 24 hours whether you chose it or not.
- Recovery time objective (RTO) is how long you can be without the system before the damage becomes serious. For a file share it might be a day. For the system that takes customer orders it might be a couple of hours.
These are business decisions, not IT decisions. IT can tell you what each target costs, but only the people running the business can say what an hour of downtime or a day of lost data really means. Shorter targets cost more, so it is worth setting them per system instead of demanding the shortest possible for everything.
The 3-2-1 rule, and what it looks like today
The classic rule still holds up well:
- 3 copies of your data: the live copy and two backups.
- 2 different types of storage, so one failure mode cannot take out both.
- 1 copy kept offsite, away from the building and the network.
Ransomware has added two refinements. At least one copy should be immutable or offline, meaning it cannot be changed or deleted for a set period, even by someone holding admin credentials. Attackers now look for backups first, because destroying them is what makes a ransom worth paying. The backup system should also use separate credentials from your everyday environment, so compromising one admin account does not hand over both.
You will sometimes see this written as 3-2-1-1-0: the extra one is the immutable copy, and the zero is zero errors when backups are verified. That last part is the subject of the rest of this article.
Your cloud data is not backed up the way most people assume
The most common misunderstanding I correct is about cloud services such as Microsoft 365. Microsoft runs the service reliably and keeps your data available across its data centres. That protects you from Microsoft's hardware failing. It does not give you an independent copy that you control.
Deleted items, recycle bins and version history all exist, but they have time limits. If a departed employee's account is removed and nobody notices for a few months, if ransomware on a laptop encrypts files that then sync to the cloud, or if someone deletes a folder and empties the bin, the recovery options shrink quickly and eventually disappear. Retention settings help, but they are not a separate backup either. The responsibility for your data is shared, and the part about recovering from your own mistakes or an attacker's actions is yours.
The same is true for most software you pay for by subscription. Ask each vendor directly what they can restore, for how long, and how quickly. Then decide whether that matches your RPO and RTO.
How to test recovery properly
Testing does not have to be a large project. It needs to be regular, varied and written down. This is the rhythm I recommend:
- Monthly: restore individual items. Pick a random file, a mailbox folder and a document from a shared site. Restore them to an alternate location and open them. This catches missing data and broken backup jobs early.
- Quarterly: restore a full system. Bring a server or virtual machine back in an isolated environment. Time it from start to finish, then compare that time to the RTO you set.
- Twice a year: test an application, not just data. Restore a line-of-business system and have someone who uses it confirm it works: they can log in, the records are there, the reports run.
- Annually: walk through a full scenario. Assume the office is unavailable or ransomware has encrypted everything. Who makes decisions, what gets restored first, how do staff keep working, and who talks to clients?
Record each test: what was restored, how long it took, whether it worked, and what you fixed afterwards. Rotate who performs the restore. If only one person knows how, your recovery depends on their availability that day.
What usually goes wrong in a test
The failures I see in recovery tests are rarely dramatic. They are small things that would have been very expensive in a real event:
- The backup job reports success, but a server or folder added last year was never included.
- A database was copied while running, without an application-consistent snapshot, and will not start after restore.
- The encryption key or password for the backup itself is stored on the server that failed.
- Restoring to different hardware fails because of drivers or licensing tied to the old machine.
- Pulling several terabytes back from cloud storage takes days, well past the RTO.
- Nobody knew the order to bring systems back: identity and network first, then databases, then the applications that depend on them.
Every one of these is easy to fix once found. None of them is easy to fix at two in the morning during an incident.
A recovery plan that fits on one page
You do not need a binder. Start with a single table that lists each important system and, for each one, the business owner, the RPO and RTO you agreed, where it is backed up, how it is restored, the date of the last test and the result. If a row has a blank in it, that is your next piece of work.
Keep a printed or offline copy. A recovery plan stored only on the file server you are trying to recover is not much help.
How we handle backup and recovery at Ceifa
Our backup and disaster recovery service starts with the recovery targets, not the software. We agree RPO and RTO with you per system, design the backups to meet them, include cloud services in scope, and run restore tests on a schedule so the results show up in your monthly reporting. It is part of how we run IT under our managed services. If you are not sure when your backups were last tested, get in touch and we can help you find out.
Frequently asked questions
How often should we test our backups?
Restore individual files or emails monthly, a full system quarterly, and walk through a complete disaster scenario once a year. Also test after any major change, such as a new server or a new application.
Is OneDrive, Dropbox or another sync service a backup?
No. Sync keeps copies identical, which means deletions and ransomware encryption sync too. Version history helps for a while, but it is not an independent copy with its own retention and access controls.
Do we need to back up Microsoft 365 if we already pay for it?
For most organizations, yes. Microsoft keeps the service available, but built-in recovery options are time-limited. An independent backup protects you from accidental deletion, departed accounts, malicious insiders and ransomware.
What RPO and RTO should we choose?
Start by asking what an hour, a day and a week without each system would cost you, then pick targets per system. Critical systems justify shorter targets. Archives and reference data can usually wait longer.