Disaster Recovery As A Service
Servers can all come back up after an outage, and the application still won't work, because nothing controlled the order: domain controller before database, before the app tier. DR as a service fails over on a tested runbook, in the right sequence and on the right addressing, so a Johannesburg SME with virtualised servers is trading again in minutes. It complements backup and disaster recovery, restoring the whole site, not just a file.
Where Disaster Recovery Plans Actually Fall Apart In Practice
Run a DR test on a setup nobody has rehearsed, and the servers usually come back up: domain controller, database, application server, each reporting healthy. The application still won’t open, because nothing controlled the order they came up in or where traffic should find them. That gap, between a server that boots and a business that actually runs, is what disaster recovery as a service is built to close.
Boot Order Nobody Scripted
A hypervisor will happily start ten virtual machines at once. If the domain controller comes up after the application server that depends on it, the failover reports success and the business still cannot work.
IP Addresses And DNS Still Pointing At The Old Site
Unless DNS and IP recutting is scripted into your failover runbook, your systems keep searching for an address on the server that doesn't exist anymore.
A Failover That Was Never Actually Tested
The only way to know a system works is running a real failover, something most businesses have never done outside an actual outage.
Testing That Risks The System It's Meant To Protect
Teams delay testing because a badly run test can interrupt the very system it is meant to protect. That is a design problem with the test, not a reason to skip testing.
Work doesn't stop because the primary site is down. Failback has to replicate everything changed on the standby servers back to the original machines before cutting traffic back, or that work is lost. As your Disaster Recovery as a Service partner, we script the boot order, the DNS and IP recutting, and the failback itself, so recovery means the business runs again, not just that the servers came back on.
Everything Included When We Build And Test Your Failover System
Replication and testing are not optional add-ons, they are what we scope from day one. This is different to Backup as a Service, which restores individual files and mailboxes: this is what’s included when we fail over entire running servers to a standby site until yours is fixed.
Continuous Replication
Every write on your production servers is journaled by and streamed to the standby environment as it happens, not captured in a nightly job.
A Runbook Built For Your Servers
The boot order for your domain controller, database and application tiers, plus the network changes each step needs, documented and agreed before it’s ever relied on.
DNS And IP Cutover, Scripted
The address changes needed to actually reach the standby servers are worked into the runbook itself, not figured out live during an outage.
Isolated Failover Testing
Failover is proven inside a network that never touches your live systems, so testing carries no risk to the production environment it’s protecting.
Failback Once The Primary Site Is Fixed
Changes made on the standby servers during the outage are replicated back before traffic cuts over to your original site, so nothing typed during the outage is lost.
Standby Compute When You Need It
Standby servers sit off or minimal most of the time and only spin up to full capacity the moment a failover triggers, part of how this sits inside our wider cloud services.
The Runbook And Test Result Behind Every DR Failover
A runbook is only proof once it has actually been run. For businesses running virtualised servers, we test failover in an isolated environment, and keep the boot order, the cutover steps, and the result on file so you can see exactly what was proven and when. Your standby environment is assessed against your compliance requirements before it’s provisioned.
Isolated From Production
Every rehearsal runs inside a network that never touches your live systems, so proving the runbook works never risks the environment it is protecting.
Timestamped Test Result
Our last recorded test achieves what you need, captured from an isolated failover rehearsal, not a number taken off a data sheet.
The Documented Runbook
The exact boot order for your servers, domain controller first, then database, then application tier, plus every network change the cutover needs, agreed and version controlled before it’s relied on in a real outage.
Failback, Reconciled
Changes made on the standby servers during the outage are replicated back and checked against the original site before traffic cuts over, so failback is proven as thoroughly as the failover half.
What Actually Drives The Real Cost Of DRaaS
DR as a Service runs on two meters, not one. Replication and storage bill continuously at a low rate; failover compute only bills when it runs.
The number moves with workload count, DR site location and test frequency. See Backup as a Service for retention based cover instead.
01 Replication And Storage Billing
02 Failover Compute And Testing
03 Workload Minimums And Scope
Who This Is For
This fits any Johannesburg business running virtualised servers on VMware or Hyper-V, or cloud VMs, where losing a site stops trading, not just inconveniences one user. It suits multi-site operations too, especially where Secure SD-WAN already links branches together. If your only critical system is mailbox or M365 data with no servers behind it, Backup & Disaster Recovery is the closer fit.
How It Works
frequently asked questions
Failover Questions Answered
Before you commit to a standby site, you want straight answers on the real recovery time, the boot order, the cost while idle, and how testing actually works.
What RTO can we actually rely on?
An orchestrated failover brings servers online in a fixed sequence rather than one at a time, which is what keeps it to minutes instead of the hours a restore from backup takes.
Can we choose which servers come back up first?
Yes. Your runbook sets the boot order: domain controllers and network services first, then database servers, then the applications that depend on them, so what matters most to your business is working again first.
What does this cost when nothing has failed over?
Replication and storage are billed continuously at a low rate while your standby servers sit idle. Compute is billed separately, only for the hours those servers run at full capacity during an actual failover.
Prove Your Failover Order Before An Outage Proves It For You
Test it. Don't guess it.