Backup and Disaster Recovery, Proven
If every system in your business disappeared right now, how much of today's work would you lose, and how many hours before you're trading again? Most owners can't answer either question. We treat them as two engineered guarantees: RPO, how much you could lose, and RTO, how long you'd be down, proven with real, timed test restores under our 24/7 managed IT support, not a backup job that just reports success.
The Backup Assumptions That Don't Hold Up Under Ransomware
Knowing your RPO and RTO only means something if what you think is backing up your business actually is. In practice, the businesses we see hit hardest by ransomware or a failed drive are usually the ones who were confident they were protected, right up until they tried to prove it.
The External Drive Isn't Offsite Protection
A NAS in the server room or a drive plugged in at the end of the day feels like backup, but it sits on the same premises and often the same network as the data it protects. A fire, a theft, or ransomware that spreads from the live environment before anyone notices can take the copy down with the original, which defeats the entire purpose of having one.
Microsoft Doesn't Back Up Your 365 Data
Microsoft's responsibility under its service agreement is keeping Exchange, SharePoint and Teams online, not protecting your mailboxes and files from being deleted or encrypted by a user, an attacker, or a mistake. If a compromised account wipes a mailbox or ransomware encrypts synced SharePoint files, Microsoft's own retention windows were never built to bring that back the way a dedicated backup is.
One Copy Isn't a Backup Strategy
A single backup, wherever it sits, is a single point of failure. The standard we work to is the 3-2-1 rule: three copies of your data, on two different types of storage, with at least one copy offsite and out of reach of anything that compromises your live network, including an attacker who has already taken over your servers.
What Gets Built Into Every System We Protect
Every server, endpoint and Microsoft 365 mailbox under our support gets the same disciplined build from the day it’s brought under management, not bolted on after something goes wrong. Here’s what’s actually running behind the scenes.
A Backup Schedule Per System
How often a system copies depends on how fast its data changes, since the schedule is what actually sets your RPO.
The 3-2-1 Storage Rule
Three copies, on two different types of storage, with one kept offsite, so no single failure can take out every copy at once.
Recovery point objective Set
How much recent work could be lost is decided on purpose for each system, not left as an untested assumption.
Recovery time objective Set
How long a system can stay down is engineered around exactly how it gets restored, not guessed at on a proposal.
Retention and Version History
Multiple versions of each file are kept, not just last night’s copy, since a slow moving compromise is often only found weeks later.
A Written Recovery Runbook
The order systems come back online, ownership, and communication while you’re down, all set out before it’s ever needed.
The Restore Test That Turns A Promise Into Proof
An RPO and an RTO on a proposal are only numbers until someone actually pulls the trigger. We run scheduled test restores against real systems, time every stage from start to finish, and check the result file by file, because a backup job that reports success only proves data was copied, not that it can be brought back.
Restores, Timed And Verified
[Restore test / DR drill frequency to confirm] a system is restored fully from backup, the clock is timed from the moment recovery starts to the moment it’s usable again, and the result is checked file by file against the original data before it’s signed off.
Your Recovery Point, Set
RPO is fixed by how often each system actually backs up. Mailboxes, servers and busy file shares typically copy far more frequently than a share that barely changes, because how much of today’s work you could lose depends entirely on that schedule, not on hope.
YOUR RECOVERY TIME, SET AND UNDERSTOOD
RTO depends on how a system actually comes back online: restored from a local cache, pulled down from the cloud, or a server rebuilt from nothing. Catching a failing system early through proactive monitoring often shortens that recovery before it becomes a full rebuild.
Failover When Backup Isn't Enough
When a server fails outright or an office becomes unusable, backup alone isn’t enough. Disaster recovery takes over: failing across to standby infrastructure so the business keeps trading while the original environment is rebuilt properly, not restored under pressure.
What Actually Sets The Cost Of Backup Cover
There’s no flat per-device price for backup and disaster recovery, because what needs protecting and for how long differs by business. Cost comes down to four things. Every quote follows a review of your current systems and data volumes, priced as part of ongoing ESMS managed support, not sold on its own.
01 Systems And Data Volume
02 Retention And DR Scope
03 Data Residency And Compliance
who this is for
This fits any Johannesburg business running servers, cloud files or Microsoft 365 that cannot afford to lose today's work or sit offline for hours. It does not fit a standalone backup or disaster recovery infrastructure build, our cloud services team scopes projects like that separately.
How It works
Frequently asked questions
How much of today's work could we actually lose?
That comes down to backup frequency, not luck. The RPO agreed for each system under the ESMS bundle sets how many hours of work sit between one backup and the next, so you know the real worst case before anything goes wrong, not after.
If our server died right now, how long before we're trading again?
That’s your RTO, and it depends on how the restore actually happens: from a local cache, from the cloud, or by rebuilding a server from nothing. RTO is set per system and proven with a timed restore, not just written into a proposal.
Can ransomware reach our backups too?
Not if they’re built correctly. At least one copy is kept immutable or air gapped, meaning nobody, including an attacker who has already taken over your live network, can alter, encrypt or delete it. That’s the copy that stops ransomware wiping your recovery option along with your data.
Do you actually test the backups, or just trust the job log?
We restore on a set schedule, time it, and check the result file by file. A backup job reporting “success” only proves data was copied. A test restore is the only thing that proves it can be brought back, and every result is logged through our service desk and reporting.
Get Your Recovery Point And Recovery Time Numbers Down In Writing
Proven by test, built into your managed IT support plan.