Ransomware Encrypted My Backups. The Second Backup Saved Everything.

Sunday morning. I sat down to check on the server. Every file extension was wrong.

Random-character extensions on everything. VM disks. Database backups. Configuration files. A ransom note sitting in the root of every drive with a contact email and a Session chat ID. The kind of thing you read about happening to someone else.

But here’s the part that made my stomach drop: the primary backup drive was connected. It was encrypted too. Years of incremental backups — 1TB of recovery data — completely scrambled. The backup software couldn’t even see a valid restore point.

I sat there staring at the screen for about ten minutes, running through the timeline. Then I remembered: six months ago, I had copied a full backup chain to a separate 4TB drive and physically unplugged it. It had been sitting in a drawer ever since.

That drive saved everything.

The Attack: What Happened

The infection vector was almost certainly Remote Desktop Protocol (RDP). The server had RDP exposed to the internet — something I’d set up years ago for convenience and never revisited. The password wasn’t strong by modern standards. That combination — exposed RDP plus a guessable password — was the entry point.

Once inside, the ransomware did what ransomware does:

Encrypted documents, databases, VM disks, ISO files, and configuration files across every mounted drive
Appended a random extension to every affected file
Dropped a ransom note with contact details on every drive
Deleted Volume Shadow Copies so Windows couldn’t self-recover
Encrypted the primary backup repository — ~1TB of Veeam backup chains, gone

Notably, media files were left alone. Photos, videos, music — untouched. The attackers were efficient: encrypt what matters, skip what’s too large to bother with, and demand payment. Ransomware gangs have KPIs now.

The OS drive itself was bootable. Windows Server still started. But every VM disk, every database backup, every tool configuration — encrypted. The server was a ghost of itself.

What Was Lost

This is the hardest section to write. Here’s what the encryption destroyed:

Two production VM disks: an Ubuntu Docker host running a dozen services (Nextcloud, Immich, Portainer, MeTube, Copyparty) and a Home Assistant instance controlling the entire smart home. Both VM disks were on drives that got encrypted.
All Veeam backups: roughly 1TB of backup chains spanning multiple years. Every .vbk, .vib, and .vbm file encrypted. The backup software couldn’t restore a single file.
Application configs: Docker Compose files, environment variables, Nginx configs, database connection strings. All the invisible glue that made everything work.
Jellyfin media server config: the media files survived (too large to encrypt), but the server configuration — user accounts, watch history, library metadata — was in an encrypted zip.

The smart home went dark. No automations. No remote access. No media streaming. Just a Windows Server login screen and a lot of encrypted files.

What Survived (And Why)

Three things were intact when the dust settled:

1. The pfSense Firewall VM

The firewall VM disk was stored on a different physical drive that the ransomware somehow missed. This was pure luck — no strategic decision, just a quirk of how the drives were partitioned. Having the firewall intact meant I could restore network routing, DHCP, and DNS without rebuilding from scratch. That saved hours.

2. Photos and Media

The ransomware skipped large media files — photos (~15,000 of them), videos, and music on an 8TB drive. The files themselves were untouched. The Immich photo database was on that same drive and also survived. This was the biggest emotional relief — photos are irreplaceable.

3. The Offline Backup

Six months before the attack, I had copied a full Veeam backup chain — one full backup plus two incrementals — to a 4TB external drive. Once the copy finished, I unplugged the drive and put it in a drawer. No network connection. No USB. No power. Just a cold drive in a drawer.

That drive contained a complete image of the server from June 2023. It wasn’t the latest state — I’d lose six months of incremental changes — but it had the OS, all VM configurations, all Docker Compose files, all application data. Everything needed to rebuild.

The Veeam Backup Validator confirmed the chain was clean. No corruption. No encryption. A cold, disconnected backup that the ransomware never touched.

The 3-2-1 Backup Rule (And Why Most People Break It)

You’ve probably heard this before. The 3-2-1 backup rule says:

3 copies of your data
2 different types of media
1 copy off-site

Sounds simple. Here’s where almost everyone (including me) gets it wrong: they keep all three copies connected.

My setup before the attack:

SERVER (Copy 1)
  ├── Production data on C:
  ├── Veeam backup repository on D:  ← connected via USB
  └── Secondary backup on E:         ← connected via USB

All three copies: ONLINE. All three copies: ENCRYPTED.

Veeam was doing its job — daily incrementals, synthetic fulls, retention policies, the works. But Veeam can’t protect backups that are physically connected to the compromised host. If the OS can write to the backup drive, so can the ransomware.

The fix isn’t buying more backup software. It’s adding air gaps:

Rotating offline drives: Keep at least one full backup on a drive that is physically disconnected. Rotate it weekly or monthly. If ransomware hits, the disconnected drive is safe.
Immutable cloud storage: Services like Backblaze B2 with Object Lock can make backups truly immutable — even the account owner can’t delete them during the retention window. Ransomware can’t touch what it can’t authenticate to, and even if it could, it can’t delete locked objects.
Pull-based backups: Instead of the server pushing backups to a destination, have a separate backup server pull data from the production server. The backup server initiates the connection and authenticates to the production server — the production server has no credentials to the backup target. Ransomware on the production server can’t reach the backup server’s storage.

My New Backup Architecture

After the attack, I rebuilt the backup strategy from scratch. Here’s what changed:

Tier 1: Local Backup (Same Machine, Different Drive)

This is the “quick recovery” tier. If a VM config gets corrupted or a Docker volume fills up, I can restore in minutes. But this tier is not ransomware-resistant — it’s connected, so it’s vulnerable. It exists purely for speed.

Tier 2: Offline External Drive (Rotated Weekly)

Once a week, a full backup runs to an external USB drive. When the backup completes, the drive is physically disconnected and stored separately. The next week, a different drive is connected and the cycle repeats. Two drives in rotation means even if ransomware hits mid-backup and encrypts the connected drive, last week’s drive is safe in a drawer.

This is the tier that saved me. The drive from six months ago was cold, offline, and untouched.

Tier 3: Cloud (Immutable Object Storage)

Critical data — Docker Compose files, database dumps, pfSense config, application configs — gets backed up nightly to Backblaze B2 with Object Lock enabled. Even if ransomware compromises the server, the cloud backup can’t be deleted or overwritten during the lock period.

This tier is slower to restore from but is the last line of defense. If the building burns down, the data still exists.

Total cost: about $6/month for B2 storage of critical configs and databases. A hundredth of what the ransom note was asking for.

Practical Steps For Your Homelab (Today)

You don’t need enterprise backup software or a six-figure budget. Here’s what you can do right now to avoid my mistake:

1. Find a spare external drive. An old 1TB USB drive costs nothing and might save everything.

2. Run a full backup to it. Use whatever tool you have — Veeam Agent (free for Windows), Duplicati, restic, or even robocopy if that’s what you know. The tool matters less than the fact that a copy exists.

3. Unplug it. Physically disconnect the drive. Put it somewhere other than where the server lives. A drawer in another room. Your work bag. Anywhere the ransomware can’t reach it.

4. Verify the backup works. Don’t wait until you need it. Pick a random file and try to restore it. If you’re using Veeam, run the Backup Validator. A backup you haven’t tested isn’t a backup — it’s a wish.

5. Set a recurring calendar reminder. “Rotate backup drive.” Every Saturday morning. Connect the drive, run a fresh backup, disconnect it. If life gets busy and you miss a week, you still have the previous week’s copy.

6. Sign up for cloud storage. Backblaze B2, Wasabi, or even Google Drive with rclone encryption. Back up your configuration files and databases — these are tiny compared to media, and they’re the hardest to recreate from scratch. $5/month for the peace of mind that your Docker Compose files and pfSense config exist somewhere else.

What I’d Do Differently

Hindsight is always 20/20. Here’s what I wish I had done:

Never expose RDP to the internet. Use a VPN (Tailscale, WireGuard, OpenVPN) for remote access. Zero open ports on the WAN. RDP through a VPN tunnel is fine. RDP directly on the public internet is a disaster waiting to happen.
Rotate offline backups more frequently. Six months is too long. I lost six months of incremental changes. Weekly rotation would have limited the loss to one week.
Use different credentials for everything. A single shared password across services made lateral movement trivial. Every service — hypervisor, VMs, Docker containers, backup targets — needs its own strong, unique password.
Enable firewall logging and alerts. If I’d had Suricata or pfBlockerNG running on the firewall, I might have caught the initial RDP brute-force attempts before they succeeded.
Document everything in one place — MAC addresses, static IPs, VLAN configs, VM specs. When you’re rebuilding from scratch, you don’t want to be guessing which NIC was WAN and which was LAN.

The Bottom Line

Ransomware doesn’t care about your homelab. It doesn’t care that you’re just a hobbyist running some Docker containers and a media server. It sees a Windows machine with drives attached, and it encrypts everything it can reach.

The only thing that saved my data was a backup that wasn’t connected. Not a better firewall. Not antivirus. Not a stronger password. A cold drive in a drawer.

If you run a homelab and your only backup is a USB drive plugged into the same machine, stop reading and go unplug it right now. Then plug it back in once a week to run a fresh copy, and unplug it again when it’s done.

That five-second ritual — plug, backup, unplug — is the difference between “I lost everything” and “I lost a week of changes.”

Ask me which one I’d rather say.