The short answer
Cloud backup copies your website, databases, mail and files to storage separate from the system they came from, on a schedule, with retention long enough to reach past a problem you found late. A backup only counts once it has been restored in a test. We run and check both.
What we back up and how
Websites and databases.
Captured on a schedule matched to how often the site changes, held away from the server they came from.
Mail and cloud files.
Microsoft 365 and Google Workspace mailboxes, Drive and SharePoint, because a provider's retention window is not a backup.
Servers.
Full snapshots of VPS and cloud environments, alongside server maintenance.
Off site copies.
Stored separately from production, so one compromised account can't take the originals and the copies together.
Retention that reaches back.
Daily copies for the recent past, plus weekly and monthly points for problems you find late.
Restore testing.
Scheduled tests where we pull data back and check it opens, runs and contains what it should.
A documented recovery plan.
What gets restored first, from where, and how long it takes.
A backup you have never restored is not a backup
It's a hopeful file. Most businesses that lose data had backups running the whole time, and the backups were why nobody worried. What they didn't have was proof.
The 3-2-1 rule in plain terms.
Keep three copies of anything you can't afford to lose, on two different kinds of storage so one failing technology doesn't take both, with one of them somewhere else entirely. It has outlived thirty years of changing technology because it's about independence rather than products. The modern addition: at least one copy an attacker holding your admin password cannot delete, because ransomware crews look for the backup console first.
Sync is not backup.
Dropbox, OneDrive and Google Drive keep files identical across devices, which is exactly what you don't want when something goes wrong. Delete a folder by accident and the deletion copies everywhere in seconds. Let ransomware encrypt a laptop and the sync client uploads every encrypted file over the good ones. Version history helps, but rolling back forty thousand files one at a time during a crisis is not a plan. Sync protects you from a dead hard drive. Backup protects you from a mistake.
Retention, and why thirty days often isn't enough.
Cheap backup keeps a rolling thirty days, which covers the obvious failures. The ones that hurt are slower. A table corrupts and shows up when the quarterly report doesn't balance. A plugin update breaks the enquiry form and nobody checks lead volume for six weeks. A folder deleted in March is wanted in August. In each case thirty days means every copy you hold already contains the problem. Keep dailies, then weeklies, then monthly points. Storage is the cheapest thing in this discussion.
What a restore test involves.
Not a green tick in an email. Take a backup that isn't the newest, restore it into an isolated environment, then check the data with something other than optimism. Does the site load, does the application connect and run, are the record counts right, does the most recent order match the date the backup claims. Time it, because that number is your real recovery time and it's longer than anyone guesses.
One question for your current provider.
Ask when they last restored your data, what exactly they restored, and how long it took. Not whether backups are running, because anyone can answer that. A vague reply, or a screenshot of a backup log, means you have backups nobody has ever proven. That's the standard we hold on every site we host.
How we set it up
We work out what matters
Which data ends the business if it's gone, which is annoying, and which nobody would miss. They get different treatment.
We set schedules and retention
Frequency matched to how fast data changes, retention long enough to reach past a slow problem, copies held away from production.
We test the restore
Before you rely on it, not after. You get the recovery time in writing.
We keep checking
Monitored jobs, failures chased the same day, and restore tests that don't quietly stop happening.
Who this suits, and who it doesn't
It works for businesses running a website with orders or bookings in it, offices whose files and mail live entirely in the cloud, and anyone who couldn't say when a restore was last performed.
It's a poor fit if you need enterprise archiving with legal hold obligations, or on site backup infrastructure for a large staffed network.
Why put backup with us
We restore, not just back up.
Test restores are scheduled work with a person's name against them, and you're told the recovery time rather than left to find out.
Australian hosting, Sydney data centre.
Production is onshore, and you'll be told plainly where the copies sit rather than left guessing at a region code.
We respond in 1 to 3 hours.
Data loss is the one problem where the first hour changes the outcome, because acting early means less to rebuild.
"Our hosting includes backups, so we're covered."
Maybe. Ask how far back it reaches, whether the copy is stored somewhere other than the server it protects, and whether anyone has restored from it.