The moment ransomware lands on your website's server, whether you can recover comes down to a backup strategy you put in place months ago. The past 30 days of security events have shown that attackers can take over a cPanel control panel or an entire Linux website server in hours using AI tooling. Their first move isn't to encrypt the site; it's to delete every backup file they can see, then encrypt your website and leave a ransom note. If your backups only live on the same machine that got hit, one keystroke from them and you have nothing.
The strategy 5U Website runs for every managed client website has two layers: how deep in time the backups go (how many versions across what time horizon) and where the backups physically live, and who can reach them. The next sections cover each.
Layer 1: Why 7 + 3 + 12 restore points
The common belief is that "daily backups" are enough. They are not. Suppose a malicious script gets injected into your site today, but you only notice it two weeks from now. By then, all 14 of your last daily backups carry the script. Overwriting the current site with any of them just restores the infection. The issue isn't backup frequency; it's that your restore points need to span different time depths.
So here's what 5U Website runs for every managed client website:
| Backup tier | Retention | Used for |
|---|---|---|
| Daily backups | Last 7 retained | Most common case: a code change broke something, CSS got messed up, a database row was deleted by mistake. Roll back 1–7 days. |
| Weekly backups | Last 3 retained | One step deeper: an SEO setting changed two weeks ago turned out to be wrong, you need a version from three weeks ago. |
| Monthly backups | Last 12 retained | The deepest layer: a malicious script may have sat dormant for six months before being noticed. You need to dig back a full year. |
The point is not "more backups are better." 22 restore points (7 + 3 + 12) cover the full timeline from yesterday back to a year ago, far more useful than 365 consecutive daily backups, which never reach 12-month depth and cost more to store.
Layer 2: Backups must live in "another building," and they have to be drop-only
This layer matters more than the first. Here are the common options, ordered from least to most secure:
- Local RAID. Not a backup. RAID protects you if a hard drive fails — one disk dies, the data is still there. But it does nothing against ransomware that encrypts files, accidental deletion, or an attacker who gets your website's "master key" (administrator-level access). RAID solves "the disk broke," not "we got attacked."
- A backup folder on the same server. Also not a backup. Picture it this way: the backup folder sits in the same room as the live website files. A thief who breaks into the room walks out with both.
- The hosting provider's "automatic backup" feature. Better than the above, but if the host itself is breached or your control panel account gets hijacked, the attacker wipes the backups together with the live files. Last week's Canvas LMS incident took down several institutions exactly this way: the SaaS platform got breached and their backups went with it.
- A remote vault in "another building," drop-only. This is what a real backup looks like. Picture it this way: you rent a P.O. box in the next city. You can drop letters (backup files) into the slot, but you don't have a key to open the box and see — or delete — what's already inside. Even if an attacker steals every key to your website server, they can't pry open that P.O. box.
Every website 5U Website manages runs option four. A backup script on the client's server uses an account that can only deposit — no permission to list existing files, no permission to delete. Behind the scenes it's AWS S3 (Amazon's remote object-storage service), with "version retention" turned on, so the previous version of any same-named file is preserved (think of the post office keeping a record of every letter ever dropped in the box). To actually delete a backup, an administrator needs to log in with both a password and a one-time code sent to their phone — two locks, both required. The backup script itself can never do that.
Putting this into last week's cPanel attack scenario
We wrote last week about cPanel's authentication bypass — an attacker logs in to the control panel without a username or password. Linux's Copy.Fail flaw lets a routine script promote a low-level guest account up to the "master key" tier. Once both happen on your server:
- Attacker gets the master key → sees every file on the box → deletes the control panel's built-in backup directory → encrypts everything under
public_html/ - Drops a ransom note: pay to get the decryption key
- If your backups only existed on that same machine, your two options are: pay the ransom, or rebuild from scratch.
If you'd built Layer 2 above (the drop-only remote vault), the story is different:
- Spin up a clean temporary server, or wipe and reinstall the existing one.
- Pull your last known-clean snapshot from the remote P.O. box (e.g. a weekly backup from before the script was injected).
- Restore the site. The whole process typically takes 4–8 hours and zero ransom paid.
The "we're too small to be a target" assumption doesn't survive contact with reality. Vancouver small business websites get hit more often than most owners think. Attacker IP-range sweeps are automated, and they don't care whether you're a 5-person studio or the Fortune 500.
The full checklist 5U Website runs for managed client websites
- 22 restore points: 7 daily + 3 weekly + 12 monthly.
- Drop-only remote storage: the backup script has no delete permission. Version retention is on for the target storage. Deletion requires the admin's password + a one-time phone code.
- Monthly recovery drill: pick a restore point, run a full restore in an isolated environment. Writable does not equal usable. The only backup you can trust is one you've actually restored from.
- Metadata archive: every restore point ships with a file-fingerprint list so we can verify integrity after restoration.
The minimum if you're doing this yourself
If you're not on a 5U Website maintained plan and want to do this on your own:
1. Check what your hosting provider actually offers, today. Something that says "30-day automatic backup retention" is better than nothing. But as our complete guide to backing up websites already covered: if the host's automatic backup lives on the same machine as your site, it goes down with the site.
2. Add at least one off-site copy. You don't need a complicated setup on day one. A separate cloud storage account (Dropbox Business, Google Workspace, Backblaze B2 all work) with a unique password and the phone-code verification turned on, and a monthly manual pull of the latest backup into it — that already blocks about 80% of the ransomware scenarios we see.
3. Actually do a restore once. This is the step most often skipped, and the one that matters most. An untested backup is not a backup. You don't know whether it can actually recover the site, and you don't want to discover the answer is "no" the day you need it.
When to talk to us
5U Website designs, builds, and hosts websites for Vancouver SMEs. If reading this made you think "I'm not sure my current backup strategy holds up," that's a two-hour conversation worth having. Vancouver businesses get targeted by attackers regularly enough that patching the backup story before something goes wrong is much cheaper than paying the ransom after.
