Every website owner eventually learns the same lesson, usually the hard way: the day you need a backup is never the day you planned for. A bad plugin update wipes your database. A billing hiccup suspends your account. A ransomware script encrypts your uploads folder. In each case, the difference between a bad afternoon and a business-ending catastrophe is whether you can restore a clean copy of your site quickly — and whether you have actually tested that restore before you needed it.
Cloud hosting gives you powerful backup tools, but it also creates a false sense of security. Your provider keeps your data on redundant storage, which protects against hardware failure — but it does not protect against your own mistakes, a compromised admin account, or a corrupted database that gets faithfully replicated to every redundant copy. This guide walks you through the 3-2-1 backup rule, the critical difference between snapshots and true off-site backups, what RTO and RPO mean in plain words, and a practical before-during-after plan for any site running on cloud infrastructure.
The 3-2-1 Backup Rule, Explained
The 3-2-1 rule is the oldest and most durable piece of backup advice in computing, and it applies to cloud hosting just as well as it did to tape drives. It says: keep three copies of your data, on two different types of storage, with one copy stored off-site — meaning somewhere completely separate from your hosting account.
- Three copies. Your live site counts as copy one. Then you need two more: typically a recent automated backup and an older one. If the newest backup is corrupted or encrypted by ransomware, the older one saves you.
- Two different media or locations. Don’t keep both backup copies in the same storage bucket as your server, in the same account, in the same region. If the account is compromised or the region has an outage, both copies are gone together.
- One copy off-site. This is the copy that survives account-level disasters: a suspended account, a hacked control panel, or a provider outage. It can be another cloud region, a different provider’s storage, or even a local drive for smaller sites.
Notice what the rule does not say: it says nothing about snapshots, one-click restore buttons, or your host’s “automatic backups.” Those are useful, but they rarely satisfy the rule on their own — which brings us to the most common misunderstanding in cloud backup.
Snapshots Are Not Backups
Most cloud providers let you take a “snapshot” of your server — a point-in-time image of its disk that you can roll back to. Snapshots are fast, convenient, and genuinely useful. They are also not backups, and confusing the two is how sites get lost.
A snapshot lives inside your hosting account, on the same infrastructure, under the same credentials. If an attacker compromises your account, they can delete your snapshots along with your server. If your provider suspends the account over a billing dispute, your snapshots are suspended too. If a database corruption happened three days ago and you only notice today, every snapshot since then contains the corruption — snapshots capture state, they don’t judge it.
A real backup is a copy of your data that is independent of the system it protects: different account or provider, different credentials, ideally a different geographic region. Think of it this way: a snapshot is an undo button for your own mistakes; a backup is a lifeboat for when the whole ship is in trouble. You want both, but only one of them saves you from the other kind of disaster.
| Feature | Snapshot | Off-site backup |
|---|---|---|
| Lives in your hosting account | Yes | No — separate account or provider |
| Survives account compromise | No | Yes |
| Survives provider outage | No | Yes, if in another region or provider |
| Speed of restore | Very fast (minutes) | Slower (download and restore) |
| Best for | Rolling back your own mistakes | True disasters |
Who handles backups also depends on your service model: on unmanaged infrastructure you own the entire backup process, while managed platforms often include automated backups as part of the service. If you haven’t already, read our breakdown of IaaS vs PaaS vs SaaS to see exactly where the provider’s responsibility ends and yours begins.
RTO and RPO in Plain Words
Disaster recovery planning uses two pieces of jargon that are worth learning because they turn vague anxiety into concrete targets. RTO (Recovery Time Objective) is how long you can afford to be down. RPO (Recovery Point Objective) is how much data you can afford to lose, measured as time.
- RTO example: “If the site goes down, we need it back within 4 hours.” That is your RTO. It decides how automated and practiced your restore process must be — a manual restore from a downloaded archive might take six hours, which fails a 4-hour RTO.
- RPO example: “We can afford to lose at most 1 hour of orders.” That is your RPO. It decides how often backups must run — a daily backup has a 24-hour RPO, which fails a 1-hour requirement. An online store needs far more frequent backups than a brochure site.
You don’t need enterprise paperwork here. Just write down two sentences: “Our site must be back within X” and “We can lose at most Y of data.” Every backup decision — frequency, retention, automation, testing — flows from those two sentences. A personal blog might accept a 48-hour RTO and a 24-hour RPO; a store taking orders cannot.
Before: Building Your Backup Plan
Disaster recovery is won before the disaster. Work through this checklist while everything is fine, and the “during” phase below becomes a calm procedure instead of a panic.
- Inventory what matters. List everything that would need restoring: the website files, the database, uploaded media, configuration files, DNS settings, SSL certificates, and any external services (email, payment webhooks, third-party integrations). Backups that miss the database are the classic failure — files without data are just a pretty shell.
- Automate on a schedule that matches your RPO. Manual backups fail because humans forget. Set automated backups at least as often as your RPO demands: daily for most sites, hourly or continuous for stores and busy applications. Automation is the entire game.
- Keep multiple generations. Retain several restore points — daily copies for a week, weekly copies for a month, monthly copies for a quarter is a common pattern. Ransomware and slow corruption mean the most recent backup is sometimes the infected one; older generations are your fallback.
- Store one copy off-site with separate credentials. Push backups to a different provider’s object storage or at minimum a different region under different access keys. Test that the credentials work from a machine outside your hosting account.
- Encrypt backups. Your backups contain everything an attacker wants — customer data, passwords, API keys. Encrypt them at rest, and keep the encryption keys somewhere other than the server being backed up.
- Document the restore procedure. Write down, step by step, how to rebuild the site from backup: which files go where, how to import the database, how to re-point DNS. In a real incident you will be stressed and possibly working with a colleague who has never done it. A written runbook turns chaos into a checklist.
- Test the restore — really test it. At least quarterly, restore a backup to a spare server or staging environment and confirm the site actually works: pages load, logins function, the database is intact. An untested backup is a hope, not a plan. Backups are one layer of a complete security posture; see our cloud hosting security basics checklist for the rest.
During: When Something Goes Wrong
When you discover a problem — the site is defaced, the database is corrupted, files are encrypted — follow a timeline, not your instincts. Instincts say “fix it fast”; the timeline says “protect the evidence and the backups first.”
- Minute 0–15: Assess, don’t touch. Confirm what happened and how far it spread. Is it one site or all sites on the account? Is the database affected or just files? Take screenshots and notes — you’ll need them later, and for any provider support ticket.
- Minute 15–30: Isolate. If the site is compromised, take it offline or put it in maintenance mode to stop further damage and stop serving malware to visitors. Change your hosting account password and revoke API keys — assume credentials are compromised until proven otherwise.
- Minute 30–60: Protect your backups. Before restoring anything, verify your backup copies are intact and, critically, that they predate the incident. If ransomware encrypted your server at 2 AM, a 3 AM “backup” is just an encrypted copy. Identify the newest clean restore point.
- Hour 1–2: Restore to a clean environment. Restore to a fresh server or a cleaned one — never restore a backup onto a still-compromised machine. Follow your written runbook. Import the database, restore files, re-apply configuration.
- Hour 2–4: Verify before going live. Check that the site works end to end: homepage, key pages, login, checkout or contact forms, email sending. Scan for leftover malicious files. Only then remove maintenance mode and re-point traffic.
The single most important rule of the “during” phase: never restore over your only good backup. Copy the backup aside first, so a failed restore doesn’t destroy the lifeboat you’re standing in.
After: Restore, Verify, Learn
Getting the site back online feels like the end, but the “after” phase is where you make sure it doesn’t happen again — and where you discover whether your plan actually worked.
First, verify thoroughly over the following days, not just in the first hour. Check that scheduled tasks run, that emails deliver, that analytics and payment webhooks fire. Some corruption only shows up when a monthly report runs or a customer hits an edge case. Monitor error logs closely for a week.
Second, find the root cause. Was it an unpatched plugin? A weak password? A provider-side failure? A billing lapse? The fix is different in each case, and “we restored from backup” is not a fix — it’s a reset. Patch the vulnerability, enforce stronger authentication, or set up billing alerts, whatever the cause demands.
Third, hold a short post-mortem — even if it’s just you with a notebook. Write down: what happened, how long the outage lasted, whether you met your RTO and RPO, what went smoothly, and what was missing. Then update the runbook with everything you learned. Every incident should make the next one shorter. Sites that do this diligently find that their second incident is a non-event; sites that skip it repeat the first one.
The Quick Checklist
- Automated backups running at least as often as your RPO requires
- Multiple generations retained (daily, weekly, monthly)
- One copy off-site under separate credentials
- Backups encrypted, keys stored separately
- Written restore runbook, tested quarterly on a spare environment
- RTO and RPO written down and realistic
- Post-incident review after every event, runbook updated
Cloud hosting makes backups easier than they have ever been — automation, cheap object storage, and one-click snapshots are all a few clicks away. But the technology was never the hard part. The hard part is the discipline: the off-site copy, the separate credentials, the quarterly test restore, the written plan. Do the boring work now, while everything is fine, and the worst day of your site’s life becomes a minor entry in the changelog instead of an obituary. For authoritative detail on managed backup services, see the AWS Backup documentation.
