Backup and Disaster Recovery Services
A backup is not a recovery plan until it has been restored.
Design, test and document recovery across applications, databases, servers and virtual infrastructure.
Discuss this requirement →Start with the environment, risk and required outcome.
Design, test and document recovery across applications, databases, servers and virtual infrastructure. Namandla Consultants begins with evidence and recommends a proportionate engagement rather than a generic technology package.
Connected expertise for the wider environment.
Clear steps. Visible decisions.
The gap between backup and recovery
Almost every organisation backs up. A much smaller number can state, with evidence, how long a recovery would take and what it would restore.
The gap is specific and it is measurable. Ask two questions of any environment:
When was the last time a restore was actually performed, and what did it prove?
If your primary application server were unavailable this morning, what is the sequence to bring it back, who holds it and how long does it take?
In most environments the answers are “during the original implementation” and “the person who built it would know”. Both are recoverable positions and both mean the stated recovery time is a hope rather than a number.
The typical shape of the surprise is consistent. A recovery time objective of four hours on paper turns into eleven hours in practice, because nobody had run the sequence end to end: the restore itself took longer than the backup console suggested, a dependency was missed, a service account credential had expired, and the application needed a component restored from a different job.
None of that is exotic. All of it is found by testing once.
Design
The objectives come from the business
Recovery time objective is how quickly a system must be available again. Recovery point objective is how much data loss is acceptable, expressed as time.
Both derive from what the process the system supports can tolerate, which is the work described on business continuity planning. Setting them from IT preference produces either an unaffordable architecture or one that protects the wrong things.
Set them per system, not per site. Most environments have three or four systems that genuinely need a short recovery time and thirty that do not, and pricing the whole estate at the shortest requirement is how backup budgets become indefensible.
The 3-2-1-1-0 structure
The traditional rule was three copies, on two media types, with one offsite. Two additions matter now.
3 copies of the data, including production. 2 different storage media or platforms. 1 copy offsite. 1 copy immutable or otherwise unable to be altered or deleted within its retention period. 0 errors on the last verified restore test.
The immutability requirement is the significant addition. A backup repository reachable with administrative credentials from the environment it protects can be deleted by anything that obtains those credentials. Immutable storage, object lock or an air-gapped copy removes that dependency.
The zero-errors requirement is the one nobody counts. A backup structure that satisfies the first four points and has never been restored satisfies four fifths of a rule that only pays out on the fifth.
What has to be in scope
Environments consistently under-protect four things.
Microsoft 365 data
Microsoft protects the service. Your data is your responsibility. Native retention covers accidental deletion within a window and does not cover data purged after retention expiry, a departed employee’s content after the licence is reclaimed, or files encrypted and synced through OneDrive. Exchange, SharePoint, OneDrive and Teams need separate backup.
Configuration, not just data
Firewall configurations, switch configurations, application settings, certificates and the build documentation. A restored database on a rebuilt server that nobody can configure is a partial recovery.
Endpoints holding local data
Ideally none of them do. In practice several do, and the ones that matter are usually a director’s laptop and a specialist workstation running something bespoke.
SaaS platforms other than Microsoft 365
Your CRM, your accounting platform, your HR system. Each has its own export or backup position and most organisations have never checked what it is.
Testing, which is the entire point
Restore testing on a schedule, with the results written down. This is the difference between a backup service and a backup product.
Four levels, increasing in what they prove.
File-level restore
Recover a file, confirm it opens. Monthly. Proves the repository is readable and the process works.
System restore to an isolated environment
Recover a full system, boot it, confirm the application starts. Quarterly on critical systems. Proves the backup is complete and the sequence is right.
Application recovery test
Recover a multi-tier system in the correct order and confirm it functions end to end, including integrations. Annually on critical systems. Proves the dependency map is accurate, which is where the surprises live.
Full disaster recovery exercise
Failover to the recovery environment and operate from it. Where the recovery commitment is contractual or regulatory.
Every test produces a measured recovery time
That number replaces the objective on paper with the objective in practice, and where they differ the gap gets an owner and a plan.
Technical notes
Backup windows and duration trend. A job that has grown from two hours to seven over six months will breach its window shortly, and nobody notices because it is still succeeding. Monitor duration trend, not just success.
Synthetic full and incremental forever reduce the load and the window on most modern platforms. Verify that the periodic health check on the backup chain is enabled, because a corrupt increment in a long chain invalidates everything after it and is only detected by that check.
Deduplication and compression ratios vary by data type and by platform. Ratios quoted in vendor material assume favourable data. Size the repository from your own data after a pilot, not from a ratio in a datasheet.
Encryption in transit and at rest, with the keys held somewhere that survives the loss of the environment. A key held only in the system being protected is a recovery failure waiting to happen.
Retention aligned to obligation, not to default. What your auditors, your sector and your customers require, with a defined period rather than an indefinite one. Indefinite retention is a storage cost and, where the data includes personal information, a POPIA problem.
Recovery runbooks written for someone else. The test is whether an engineer who did not build the system can follow it. Sequence, dependencies, credentials location, verification steps and expected duration at each stage.
What Namandla delivers
Assessment. What is protected, what is not, current recovery objectives against current capability, and the date of the last successful verified restore.
Design. Recovery objectives per system, repository architecture including immutable and offsite copies, retention schedules aligned to obligation, and backup scope covering servers, endpoints, Microsoft 365 and SaaS platforms.
Deployment and migration from an existing platform where one is in place.
Managed operation. Job monitoring, failure remediation, capacity and duration trend management, and repository health.
Restore testing on the schedule above, with measured recovery times and written results.
Recovery runbooks, maintained rather than written once.
Disaster recovery environment design where the objectives require warm standby or replication, on premises or in cloud.
Reporting. Job success, capacity, duration trend, restore test results and measured recovery time per system against target.
Remote delivery nationally. Onsite in Gauteng for deployment and for physical recovery work.
Common questions about Backup & Disaster Recovery
What is the difference between backup and disaster recovery?
Backup is a copy of data. Disaster recovery is the ability to bring a service back into operation within a defined time. Backup is a component of disaster recovery, not the whole of it.
An organisation with good backups and no documented recovery sequence, no tested restore and no recovery environment has data and not recovery. The distinction shows up as the difference between a stated recovery time and the one measured during the first real event, and that difference is routinely a factor of two or three.
How often should we test restores?
File-level monthly, full system restore to an isolated environment quarterly on critical systems, application recovery test annually including integrations, and a full failover exercise where the commitment is contractual or regulatory.
The frequency matters less than the fact of it happening and the results being recorded. A single honest annual test that measures actual recovery time is worth more than quarterly tests that nobody records. The measured time is the deliverable, not the pass mark.
Is Microsoft 365 backed up by Microsoft?
Not in the way most organisations assume. Microsoft protects the service and the infrastructure. Your data is your responsibility under the Shared Responsibility Model.
Native features give you recycle bins, retention policies and litigation hold, which cover accidental deletion within a defined window. They do not cover data purged after retention expiry, a departed employee’s content once the licence is reclaimed, or files encrypted and synced through OneDrive. Exchange, SharePoint, OneDrive and Teams need separate backup if your retention or recovery position requires it.
What is immutable backup and do we need it?
Immutable backup cannot be altered or deleted within its retention period, including by an administrator. Object lock on cloud storage and hardened repositories on-premises both provide it.
You need at least one immutable or air-gapped copy. A repository reachable with administrative credentials from the environment it protects shares that environment’s fate if the credentials are obtained. Immutability removes that dependency and it is generally a configuration change rather than a new product.
How long should we keep backups?
Long enough to meet your obligations and no longer. Thirty to ninety days of operational recovery covers most restore requests. Longer retention is driven by audit, tax, sector regulation or contract rather than by preference.
Set a defined period and have a reason for it. Indefinite retention is a storage cost, and where the data contains personal information it is a POPIA exposure as well, because the Act requires that personal information not be kept longer than necessary for the purpose. A tiered schedule with short operational retention and defined long-term archive is usually the right shape.
What recovery time can we expect?
It depends on the architecture, which depends on what you have decided to pay for. Restore from offsite backup is typically twenty-four to seventy-two hours. Warm standby is four to twenty-four hours. Replicated standby with tested failover is one to four hours.
The number that matters is the one measured during a test on your environment, not the one on the design document. We measure it and report it per system, and where it does not meet the objective we say so rather than reporting the target.
Can you back up to the cloud?
Yes, and it is the usual answer for the offsite copy. Cloud object storage with immutability enabled satisfies the offsite and immutable requirements in one place.
The consideration people miss is egress cost and restore duration. Getting data out of cloud storage costs money and takes bandwidth, and a full restore of several terabytes over a business internet connection is measured in days. The architecture that works for most mid-market environments is a local copy for speed of recovery and a cloud copy for resilience.
We already have backup software. Do we need to change it?
Usually not. Most established platforms are perfectly capable and the gaps we find are in configuration, scope and testing rather than in the product.
The common findings are missing scope, particularly Microsoft 365 and configuration data, no immutable copy, retention left at defaults and no restore testing. All of those are addressable on the platform you already own. We would rather fix the configuration than sell you a migration.
What about ransomware recovery?
The controls that matter are an immutable or air-gapped copy that cannot be deleted with compromised credentials, retention long enough to reach a clean restore point, and a tested recovery sequence.
The technical requirement is straightforward. The part organisations get wrong is retention: if the only clean copy is older than your retention period, the immutability did not help. Retention needs to be long enough to cover the gap between compromise and detection, which is usually longer than people assume.
How much does managed backup cost?
Priced on protected capacity, system count or per workload, plus the repository storage. The variables are data volume, retention period, whether an offsite cloud copy is included, and the recovery objectives, since shorter objectives need more infrastructure.
The cost people underestimate is repository storage over the retention period, which grows with data volume and is the line that moves most. Size it from a pilot on your own data rather than from a vendor deduplication ratio, because ratios in datasheets assume favourable data.
Who is responsible if a restore fails?
We are, for the systems in scope, and that is why testing is in the service rather than optional. A provider who manages backup and does not test restores has taken responsibility for the job and not for the outcome.
Ask any provider what their restore testing schedule is and to show you the last set of results with measured recovery times. If those do not exist, the recovery position is unverified regardless of how good the job success reporting looks.
When is a simpler arrangement enough?
A single-site environment with a handful of servers, no compliance obligation and a tolerance for a day or two of downtime is well served by a straightforward backup product with a cloud copy and an annual restore test done internally.
Not every organisation needs managed backup with quarterly testing. What every organisation needs is one offsite copy, one immutable copy and evidence that a restore has been performed at least once. If you can show those three things, you are in a reasonable position and we will say so rather than scoping a service around it.