Cloud Backup and Storage Services
Protect cloud and on-premises data with tested recovery.
Select, configure and validate storage and backup services according to retention, resilience and recovery requirements.
Discuss this requirement →Start with the environment, risk and required outcome.
Select, configure and validate storage and backup services according to retention, resilience and recovery requirements. 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.
What cloud backup is good at
The offsite copy
The 3-2-1 rule wants one copy off site. Cloud storage satisfies that without a second premises, a courier or tapes in a director’s boot.
Immutability
Object lock on cloud storage gives you a copy that cannot be altered or deleted within its retention period, including by an administrator. This is the single most valuable property cloud storage brings to a backup design and it is straightforward to configure.
Retention at low cost
Archive storage tiers are inexpensive per terabyte, which makes long retention affordable in a way that on-premises capacity does not.
Scale without planning
No capacity purchase, no forecasting, no procurement lead time.
Geographic separation that is genuine rather than the other building on the same site.
What cloud backup is not good at
Worth being direct about, because this is where cloud backup designs disappoint.
Fast full restores
Getting several terabytes back out of cloud storage over a business internet connection is measured in days, not hours. Bandwidth constrains it and, for archive tiers, retrieval time adds to it before the transfer even begins.
Egress cost
Getting data out costs money. A full restore of a large dataset carries a real bill, and it arrives at the moment you are least inclined to argue about it. Model it during design.
Archive tier retrieval delay
The cheapest tiers are cheapest because retrieval is slow, from minutes to many hours depending on tier and provider. Archive is right for long-term retention and wrong for anything you might need this afternoon.
The consequence for design
Cloud is where the offsite and immutable copies live. A local copy is what you restore from routinely, because it is fast and it costs nothing to read. Designing cloud as the only copy produces a recovery time nobody signed up for.
Storage tiers and where each belongs
Both major providers offer broadly equivalent tiering under different names.
| Tier | Cost per TB | Retrieval | Use for |
|---|---|---|---|
| Hot or standard | Highest | Immediate | Data being actively read, recent backup points |
| Cool or infrequent access | Lower | Immediate, with a read charge | Backups from the last one to six months |
| Archive | Lowest | Minutes to hours | Long-term retention, compliance copies |
| Deep archive | Lowest available | Hours | Multi-year retention you expect never to read |
Lifecycle policies move data between tiers automatically by age. Configuring them is a small piece of work and it is the difference between a backup repository that costs what it should and one that keeps everything on the most expensive tier because that is where it landed.
Minimum storage duration charges apply on the colder tiers. Deleting an object from archive before its minimum period incurs the remaining charge anyway, which catches people out when retention policy and tiering policy are set independently of each other.
Immutable cloud backup
The requirement that matters most, and the reason to use object storage rather than a virtual machine with a disk attached.
Object lock places a retention period on an object during which it cannot be modified or deleted, by anyone, including the account owner. Both major providers support it and most backup platforms can write to it.
Why it matters
A backup repository reachable with administrative credentials from the environment it protects shares that environment’s position. Immutability removes the dependency entirely: even full administrative access to the source environment cannot reach the immutable copy within its retention window.
Retention has to be long enough
Immutability protects the copies that exist. If the retention window is shorter than the gap between an event occurring and being detected, the surviving copies may all post-date it. This is the most common design error and it is covered in more detail on cyber resilience.
Separate account or subscription
Immutability plus a separate account, with distinct credentials and no trust path from production, is the arrangement that holds. Immutable storage inside the same account is better than nothing and it is not the same thing.
Cloud backup in South Africa
Local regions
AWS Africa (Cape Town) and Azure South Africa North and West mean the backup copy can sit in-country. That matters for the residency position and it matters for restore speed, because a restore from a local region over local connectivity is considerably faster than one pulled from Europe.
POPIA and residency
Backups contain personal information. A backup copy in an offshore region is a transborder flow of personal information and it needs the same consideration as any other. Keeping backup copies in a South African region removes that question for most organisations, and it is worth checking that the backup platform is not also replicating metadata or indexes somewhere else.
Bandwidth is the real constraint
South African business connectivity, and egress pricing, make the restore arithmetic tighter than the equivalent conversation in Europe or North America. This is the reason the local-copy-plus-cloud-copy design is the right one here rather than cloud-only, more so than in markets with cheaper bandwidth.
Retention affordability
Archive tiers make multi-year retention genuinely affordable, which is useful where sector or audit requirements ask for it and on-premises capacity would not stretch.
What Namandla delivers
Design. Which copies live where, tiering and lifecycle policy, retention aligned to obligation, immutability configuration and the account separation around it.
Egress and restore modelling. What a full restore of each critical system would cost and how long it would take, calculated rather than assumed, so the recovery objectives on backup and recovery are grounded in something real.
Implementation on AWS or Azure, integrated with your existing backup platform where you have one.
Microsoft 365 backup into cloud storage, since native retention does not cover the cases most organisations assume it does. Covered on Microsoft 365 management.
Ongoing operation. Job monitoring, repository capacity, tiering behaviour, cost reporting and restore testing.
Remote delivery nationally. Onsite in Gauteng where the local copy needs work.
Common questions about Cloud Backup & Storage
Should our backups go to the cloud?
At least one copy, yes. Cloud storage satisfies the offsite requirement and it gives you immutability, both of which matter. It should not usually be your only copy.
The arrangement that works is a local copy for speed of routine restores and a cloud copy for offsite and immutable protection. Cloud-only means every restore is a download, which for a large dataset over South African business connectivity is measured in days rather than hours.
How long does a restore from cloud backup take?
For a few files, minutes. For several terabytes over a business internet connection, days. Archive tiers add retrieval time before the transfer even starts.
This is the number that should be calculated during design rather than discovered during a recovery. We model it per critical system so that the recovery time objectives you have committed to are grounded in measured bandwidth rather than in an assumption.
What is immutable cloud backup?
A backup copy stored with an object lock retention period during which it cannot be altered or deleted by anyone, including an administrator with full access to the account.
It matters because a repository reachable with credentials from the environment it protects shares that environment’s fate. Immutability removes that dependency. The strongest arrangement adds a separate account or subscription with distinct credentials and no trust path from production.
What does cloud backup cost?
Storage is priced per terabyte per month and varies substantially by tier. Archive tiers are a fraction of standard storage. Egress, meaning getting data back out, is charged separately and it is the cost most often left out of a model.
Total cost is driven by data volume, retention period, tiering policy and how often you restore. Lifecycle policies that move older backups to colder tiers automatically make a large difference and they are frequently not configured, so the repository sits entirely on the most expensive tier.
Can we keep backups in South Africa?
Yes. AWS Africa (Cape Town) and Azure South Africa North and West all support backup storage in-country.
That helps on two fronts. It removes the transborder question for the personal information your backups contain, and it makes restores faster than pulling from a European or American region. Worth verifying that your backup platform is not also replicating indexes or metadata to another region, which is easy to miss.
Is cloud storage the same as cloud backup?
No. Cloud storage is a place to put data. Cloud backup is a process: scheduled copies, retention policy, immutability, verification and tested restores, using cloud storage as one of its destinations.
Copying files to cloud storage manually is not a backup, because nothing verifies it, nothing enforces retention and nothing tests whether it can be read back. The distinction matters when someone says their data is safe because it is in the cloud.
Does Microsoft 365 need separate backup?
Microsoft protects the service. Your data is your responsibility under the Shared Responsibility Model. Native retention covers accidental deletion within a window and does not cover data purged after retention expiry or a departed employee’s content once the licence is reclaimed.
Whether you need third-party backup depends on your retention obligations and your risk position. The point is to decide rather than assume. Covered in more detail on Microsoft 365 management.
What happens to our backups if we leave you?
They stay yours. The storage account or bucket is registered to your organisation, we hold delegated access which is revoked on exit, and we hand over the configuration and the retention position.
Confirm this with any provider. The arrangement that causes difficulty is backup stored in the provider’s own tenant with you as a tenant inside it, which makes leaving considerably harder than it looks. Ask who the storage account is registered to before signing.
When is cloud backup not the right answer?
Where the dataset is very large, the recovery time objective is short and bandwidth is limited. In that combination, cloud cannot deliver the restore speed and a local or second-site copy is what meets the objective.
Cloud still has a place in that design as the immutable and long-retention copy. It is just not the one you restore from routinely. Deciding that deliberately, from measured bandwidth, is the difference between a backup design that works and one that only works for small restores.