The pitch you'll hear from cloud backup vendors
Set-and-forget, off-site by default, no tape libraries to manage, scales infinitely. All true. What gets glossed over is what happens during your initial seed backup and your first full restore — the two moments your backup strategy actually has to perform.
Where the maths breaks down locally
The initial seed is bigger than the marketing suggests
A modest 2TB initial backup over a typical SA business fibre line (say, uncontended 50–100Mbps upload) takes days, not hours, and competes with your production bandwidth the entire time. Cloud backup vendors know this, which is why several offer "seed via physical drive" services at extra cost — itself an admission that pure-cloud doesn't always work as advertised on day one.
Restore time is the number that actually matters
Nobody budgets backup software around the backup — they should budget around the restore. Pulling 2TB back down over the same connection during a genuine disaster recovery scenario, while your business is already down, is a materially different experience to a local restore from BareOS running against on-site or co-located storage, which can recover at local network speeds (often 10x or more faster).
Load shedding and connectivity are still real variables
Even with load shedding largely stabilised compared to 2023, fibre and ISP-side outages during stage events haven't disappeared completely, and rural/branch-office connectivity in South Africa remains inconsistent. A backup strategy entirely dependent on internet connectivity inherits every weakness of that connectivity. A local BareOS repository with off-site replication as a secondary tier doesn't.
What we actually recommend: a hybrid model
- Local BareOS repository for fast, full-speed restores of recent backups — this is your "I need this back in the next hour" tier.
- Off-site replication of the BareOS pool to a second location or cloud object storage (S3-compatible), for disaster recovery if the primary site is lost entirely.
- Encrypted, automated, and tested — schedules and retention policies configured once, with quarterly restore tests so "the backup works" is a verified fact, not an assumption.
This gives you the speed of local backup for the 95% of restores that are "someone deleted a folder" or "a VM needs rolling back," while still carrying genuine disaster recovery coverage for the rare total-loss scenario — without making every restore dependent on your weakest internet connection.
When pure cloud backup is the right call
If you have no on-premises infrastructure at all — fully cloud-native, no local servers worth protecting — then local backup obviously isn't relevant, and your cloud provider's native backup tooling (or a cloud-to-cloud backup service) is the correct fit. The BareOS argument is specifically for businesses that still run meaningful on-premises infrastructure, which describes a large share of the SA SMB market.
The bottom line
For on-premises infrastructure, "cloud backup only" optimises for the backup operation and quietly de-prioritises the restore operation — which is the one that actually matters when something goes wrong. A local-first, replicated-second BareOS deployment gets you both.
Want a backup strategy that's actually been restore-tested?
We design and deploy BareOS environments with documented, verified recovery — not just scheduled jobs.
