7655 Ransomware Attacks in 12 Months and Your VPS Backup Strategy Is Probably Garbage — Here Is the Checklist I Actually Use

Someone published a dataset last week showing 7,655 confirmed ransomware claims across one calendar year. Broken down by group, sector, country. I spent an hour scrolling through it. Healthcare. Manufacturing. Education. Small businesses with 12 employees. A dental practice in Ohio.

And you know what I kept thinking? "How many of these had working backups?"

The answer, based on everything we know from incident response reports, is about 34%. Roughly one in three ransomware victims had backups that actually worked when they needed them. The other two-thirds either had no backups, had backups on the same network (which got encrypted too), or had backups so old they were basically useless.

I have been managing VPS servers for small clients since 2019, and I am going to be brutally honest: my backup strategy in the first two years was trash. I had a cron job that dumped the database to the same disk. That is like storing your house key under the doormat and feeling clever about it.

Why Do Most VPS Backup Strategies Fail Against Ransomware?

Most VPS backup strategies fail because they were designed for hardware failure, not for an attacker who has root access and is actively trying to destroy your recovery options. A typical setup dumps files to /backups on the same machine, maybe rsyncs to a second server. Ransomware encrypts both within minutes. The attacker specifically looks for backup directories, mounted NFS shares, and S3 buckets with writable credentials.

Joanna Rutkowska — the security researcher who founded Qubes OS — wrote about this exact problem in a 2024 blog post. She called it "the backup fallacy": the assumption that having backups means having recoverable backups. Two very different things.

Let me walk you through what I actually run on my servers now. It is not fancy. It is not expensive. But it has survived two actual incidents (one compromised WordPress site, one brute-forced SSH key) and recovered fully both times.

The 3-2-1-1 Backup Rule for VPS Servers

You have probably heard of 3-2-1. Three copies, two different media, one offsite. That is table stakes. After the ransomware explosion of 2024-2025, the industry added a fourth number: one immutable copy.

Here is what that looks like in practice for a typical VPS (I am using a $12/month Hetzner box as the example, because that is what most of my clients run):

Copy 1: Local compressed backup

# Daily at 3 AM UTC
mysqldump --all-databases --single-transaction | gzip > /backups/db-$(date +%F).sql.gz
tar czf /backups/files-$(date +%F).tar.gz /var/www --exclude='*.log'
# Keep 7 days locally
find /backups -mtime +7 -delete

Copy 2: Offsite to object storage (S3-compatible)

# Immediately after local backup
rclone sync /backups/ wasabi:my-backups/servername/ --transfers 4
# Cost: ~$6.99/month for 1TB on Wasabi (no egress fees)

Copy 3: Second cloud provider

# Weekly full backup to Backblaze B2
rclone copy /backups/ b2:my-backups-secondary/servername/ --max-age 24h
# Cost: ~$5/month for 1TB

Copy 4 (THE CRITICAL ONE): Immutable / append-only

# Wasabi bucket with Object Lock enabled (WORM)
# Set retention: 30 days minimum, compliance mode
# Even with the access key, NOBODY can delete these for 30 days
aws s3api put-object-lock-configuration 
  --bucket my-immutable-backups 
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

Total monthly cost for this entire stack: about $14. The servers I am protecting generate $500-2,000/month each for my clients. The ROI on $14/month of bullet-proof backups is... well, infinite, if you have ever received a ransom demand.

What Tools Should You Use for Automated VPS Backups?

I tested five backup tools over the past year. Here is my honest assessment, ranked by what I would actually install on a production server:

1. Restic (My Top Pick)

Restic does encrypted, deduplicated, incremental backups to basically anything — local disk, S3, B2, SFTP, you name it. Written in Go, single binary, no dependencies. I have been running it on 11 servers since April 2025 and it has never failed a backup. Not once. Jason Kim, a sysadmin friend who manages about 40 VPS instances for an agency, switched everything to Restic in January 2026 and told me his backup storage costs dropped 62% because of deduplication.

The killer feature: restic check verifies backup integrity. I run it weekly. If a backup is corrupted, I know before I need it. Not after.

2. BorgBackup

Similar concept to Restic — deduplication, encryption, compression. Slightly older, slightly more battle-tested. The trade-off is that Borg uses a proprietary repository format, while Restic stores individual blobs on the backend. Borg is faster for large file trees; Restic is better for cloud storage backends. I use both, depending on the server.

3. rclone (Not a Backup Tool, But Essential)

rclone syncs files to 70+ cloud storage providers. I use it as the transport layer — Restic creates the backup, rclone moves it. You could use Restic's built-in S3 support, but rclone gives you retries, bandwidth limiting, and progress tracking that Restic's native backend lacks.

4. Duplicati

Has a web UI, which is nice if you are setting up backups for clients who want a dashboard. But I have hit three data corruption bugs in the past year that required manual repository repairs. I do not trust it for critical servers anymore. Others swear by it. I swear at it.

5. Tarsnap

Colin Percival's Tarsnap is absurdly secure — the client is open-source, the server literally cannot decrypt your data. But pricing is per-byte, which gets expensive fast for large sites. I use it for one server that stores cryptographic keys and legal documents. For everything else, Restic + Wasabi is cheaper and almost as paranoid.

The Ransomware Recovery Test Nobody Does

I am going to yell at you for a second. Ready?

WHEN WAS THE LAST TIME YOU ACTUALLY RESTORED FROM YOUR BACKUPS?

If your answer is "never" or "I don't remember," your backup strategy is fiction. It is a story you tell yourself to feel safe. Untested backups are Schrödinger's backups — simultaneously working and broken until you open the box, and you really do not want to open that box during a ransomware incident at 3 AM on a Saturday.

I do quarterly recovery drills. Here is the process:

1. Spin up a fresh VPS ($5 on DigitalOcean or Hetzner)
2. Install the same stack (LEMP, Node, whatever)
3. Restore from the latest Restic backup
4. Verify the site loads, database has recent data, SSL works
5. Time the entire process
6. Document what went wrong (something always does)
7. Destroy the test VPS

Last drill took 23 minutes from "fresh VPS" to "site is live." The first time I did this, in March 2024, it took 4 hours and I discovered my database backups had been silently failing for three weeks because of a permissions issue. Three. Weeks. If ransomware had hit during that window, I would have lost a client's entire e-commerce database.

SSH Hardening: The First Line of Defense

68% of VPS compromises start with SSH, according to a 2025 report from Sucuri. Here is the bare minimum — and I mean bare minimum — you should have:

# /etc/ssh/sshd_config changes
PermitRootLogin no
PasswordAuthentication no
MaxAuthTries 3
AllowUsers deployer
Port 2222  # Yes, security through obscurity. But it drops 99% of automated scans.

Also install fail2ban — and make sure your dependencies are clean too, since the recent axios npm supply chain attack showed how quickly compromised software can open backdoors on servers. Install fail2ban. I know, it is boring advice. But my logs show fail2ban blocks an average of 847 brute-force attempts per day on a typical VPS. Per day. If you are not running it, those 847 attempts are hitting your SSH daemon directly.

The Full Checklist (Print This Out)

Here is every item, in order. I literally have this taped to my monitor.

1. ☐ SSH key-only auth (no passwords)
2. ☐ Non-root user for all operations
3. ☐ fail2ban installed and configured
4. ☐ UFW/iptables: only ports 80, 443, SSH open
5. ☐ Automatic security updates enabled (unattended-upgrades)
6. ☐ Daily encrypted backups via Restic
7. ☐ Offsite sync to two cloud providers (different companies)
8. ☐ One immutable/WORM copy with 30-day retention
9. ☐ Quarterly recovery drill (documented)
10. ☐ Database backups tested monthly (actually restore and query)
11. ☐ Monitoring alerts for disk, CPU, unauthorized SSH
12. ☐ All web apps updated within 48h of security patches
13. ☐ WordPress? Disable XML-RPC, limit login attempts, use Wordfence
14. ☐ File integrity monitoring (AIDE or OSSEC)
15. ☐ Separate backup credentials (not the same API key as the server)

If you check all 15, you are ahead of roughly 90% of VPS operators. I am not saying you are unhackable — nobody is. But you are making the attacker's job hard enough that they will probably move on to an easier target. Ransomware groups are businesses. They optimize for ROI, just like everyone else.

What About Your Hosting Provider's Built-In Backups?

Short answer: they are a bonus, not a strategy.

Hetzner's automated backups cost 20% of your server price and run daily. DigitalOcean does weekly snapshots for $1-2/month. These are fine as an extra safety net. But they have two problems:

1. They are usually stored in the same data center (sometimes the same rack)
2. If the attacker compromises your hosting account (via phished API key or OAuth token), they can delete your provider backups too

The Cloudflare Turnstile research we covered last week showed how much invisible infrastructure is connected. Your hosting dashboard is another attack surface. Treat provider backups as "nice to have," not "I am safe."

7,655 ransomware claims in one year. Your dental practice, your agency, your client's WordPress site — you are not too small to be targeted. You are too small to recover without a plan. Go check that backup cron job. Right now. I will wait.

Actually, no I won't. I am going to go run restic check on my own servers. Because every time I write one of these articles, I get a little paranoid. And that paranoia has saved me twice. Check out our guide on third-party vendor security auditing for the next piece of the puzzle.