Every business that’s ever lost data due to a cyber-attack or some sort of hardware failure genuinely believed that their backup was good to go. The problem is, the backup hadn’t actually been tested, just stored away somewhere in the cloud. And even though the files existed, somewhere, the process to actually get them back & get the business up & running again had never even been tried out. The subtlety between a backup completing ok & a backup actually restoring the business to a usable state is often where disaster recovery plans quietly fall apart, long before any disaster even has a chance to come along & really put them to the test.
What Business Continuity and Disaster Recovery Actually Mean in Real Terms?
You often hear business continuity and disaster recovery solutions thrown around like they’re one & the same thing, but in fact they cover two distinct things. Business continuity is about keeping the business running in some form even when there’s been a disruption of some kind, keeping the cash flowing in & still serving clients while you figure out what’s gone wrong. Disaster recovery is the actual technical process of getting your data, systems & access up & running again.
Two key numbers dictate how you plan for these sorts of things: Recovery Time Objective & Recovery Point Objective. The first one is how long you can survive without access to your systems before it starts to get pretty dire for the business. The second is how far back in time you can restore your data to before the lost data becomes close to catastrophic. But you’d be surprised how many businesses haven’t even thought to define these numbers precisely. And in managed IT conversations that don’t include them at all, that’s a fundamental planning gap just waiting to be exploited.
The Problem with Backup Testing That Almost No One Wants to Talk About
Automated backup monitoring will confirm that a file got copied ok, that the data actually got written to the backup destination & the job status came back successful. But that doesn’t actually confirm that data can be retrieved & restored to a working state within your recovery time objective. Those are two fundamentally different technical questions, & the second one requires you to actually try out a restoration test to be sure.
How often you test restoration is the metric that really separates providers that take disaster recovery seriously from those that just treat backup as some sort of box-ticking exercise. Monthly automated restoration testing, where you keep a log of what you restored, how long it took & any errors that came up is really the benchmark of a managed service. Quarterly is the minimum, annual is basically just winging it & hoping the backup works.
Backup Solutions in Cloud Environments Used by Businesses
In addition to that, the native retention feature of Microsoft 365 is not a proper backup solution in the disaster recovery sense. Microsoft 365 holds deleted items for certain periods depending on the default settings; however, it does not offer point-in-time restoration for mailboxes and document libraries after the respective retention periods. Thus, a cloud backup solution that functions independently from native retention in the platform is an additional product.
Google Workspace also includes such a misconception. The platform infrastructure is very resilient. However, the resilience helps to protect against platform failures and does not help in case of mistakes made by users or ransomware that locks data on the platform; thus, the backups in Azure should be configured and controlled separately.
What Happens Immediately After A Ransomware Attack?
During a ransomware attack, users get locked out of the system, get their files encrypted, and, depending on a specific attack model, may have their data exfiltrated first before getting the encryption. The result of such an attack is total: users stop receiving emails, cannot access the files, and cannot work with the line-of-business applications because they lose the connection to databases. After such an event, the organisation has to choose between paying ransom, restoring from the backup, and rebuilding everything.
However, in case of a tested backup, the choice changes completely. An organisation that knows how to restore its systems from the clean backup and do it in compliance with the set recovery time objectives can simply use ransom money for something else. Thus, tested backup makes restoration a real possibility and not the last resort after failing to restore from ransomware.
Questions That’ll Actually Tell You If A BCDR Provider Takes It Seriously
- How often do they actually conduct restoration tests, and can they produce a recent test report with specific details on dates and outcomes?
- What’s their guarantee for recovery time when you need to restore everything across all systems, no exceptions?
- Do they keep a documented BCDR framework that’s tailored to your business specifically, rather than just some generic template?
- Does their monitoring not just send you a ‘done’ alert, but actually catch a failure as it happens and sort it out for you?
- Are they covering every aspect of your business cloud, email, and on-site- with one comprehensive plan that they actually verify is working every month?
