Furkan İkkan Türkçe
Back to posts
Post

· Network & System Administrator

Disaster Recovery Plan Mistakes That Wreck Your Backups

Common disaster recovery plan mistakes that break backups at the worst moment. Learn what to fix before ransomware or hardware failure hits your infrastructure.

BackupDisaster RecoveryRansomwareProxmox Backup ServerRTO RPOImmutable StorageRunbook

Most disaster recovery plan mistakes don't come from fancy tooling gaps — they come from assumptions. You assume the backup ran, assume the restore will work, assume someone will know what to do at 3 AM. In my environment, I've seen exactly these assumptions turn a recoverable incident into a full week of downtime. The biggest DR plan mistakes I run into are untested restores, single-site backups, no documentation, and no defined RTO/RPO. If you haven't restored from backup in the last 30 days, you don't have a backup — you have a hope.

Never Testing Restores Is the #1 DR Mistake

I've said this before and I'll keep saying it: as I mentioned in my previous post about backup testing (https://furkanikkan.com/urun/geri-yukleme-testi-olmayan-yedekleme-sadece-bosuna-disk-isgalidir-34), a backup you never restored is just occupied disk space. But in disaster recovery planning, the stakes are even higher because you're not just checking if the data comes back — you're checking if the whole recovery process works end to end.

Here's what I do every month in my environment:

  • Pick one critical system at random
  • Restore it to an isolated VLAN
  • Boot it, verify services, check application logs
  • Time the entire process
  • Document what broke and fix it before next month

The first time you do this, something will fail. That's the point. A restore test during a scheduled maintenance window is cheap. A restore test during a ransomware incident is not.

Single-Location Backups Will Kill You

This is the one I see most often in small and mid-size environments. The backup server sits right next to the production SAN, replicates to a NAS in the same rack, and everyone sleeps well. Then the building loses power, the sprinklers go off, or someone physically steals the rack.

A real DR plan needs at least two copies in two physical locations. I follow the 3-2-1 rule and I don't bend on it:

  • 3 copies of the data (production + 2 backups)
  • 2 different media types (disk + tape, or disk + object storage)
  • 1 copy offsite and offline

In practice, my setup looks like this: primary backup goes to a local Proxmox Backup Server for fast restores. A second copy syncs to a remote PBS instance over a WireGuard tunnel. A third copy lands on immutable S3-compatible object storage with versioning and object lock enabled. If ransomware encrypts everything on-site, the immutable copy is the safety net.

No Defined RTO and RPO Means No Plan

If someone asks you "how long until we're back online?" and your answer is "it depends," you don't have a DR plan. You have a DR wish.

RTO (Recovery Time Objective) and RPO (Recovery Point Objective) are not buzzwords — they're the numbers that drive every backup decision. How often you snapshot, how much retention you keep, whether you replicate or just copy, all of it comes from these two numbers.

In my environment, I sit down with whoever owns the business impact and we define RTO/RPO per system. Not per cluster, not per site — per system. A file server might tolerate an RPO of 24 hours, but the database behind the customer portal might need 15 minutes. Those numbers decide your backup frequency and your storage cost.

Warning: if you set an RTO of 1 hour but your restore takes 4 hours because you're pulling 2 TB over a 100 Mbps link, your plan is fiction. Measure the actual restore time and work backward.

Runbooks That Only Live in One Person's Head

This one is painful because it's so common. The senior admin built the backup system, configured the scripts, knows which job ID maps to which VM, and then went on vacation. Now the disk is full, backups have been failing for six days, and nobody noticed because the only alert goes to that person's email.

I write runbooks that a colleague can follow at 3 AM without calling me. Each one includes:

  • What the system does and why it matters
  • Where the backups live (host, path, credentials vault reference)
  • How to trigger a restore (exact commands or UI steps)
  • How to verify the restore succeeded
  • Who to escalate to if something looks wrong

Here's a quick example of what a restore runbook snippet looks like for a Proxmox VM:

# List available backups for VM 104
proxmox-backup-client snapshot list --repository root@pbs@backup-repo

# Restore VM 104 from the latest snapshot
qmrestore /mnt/pbs/dump/vm-104-2024*.vma.zst 104 --storage local-lvm

# Verify the VM boots and check network
qm start 104 && qm guest cmd 104 network-get-interfaces

If your runbook says "restore from backup" without specifying which backup, from which host, using which command — it's not a runbook. It's a sticky note.

Ignoring Immutable Storage and Access Controls

Ransomware doesn't just encrypt production data anymore. Modern variants specifically target backup infrastructure. They look for Veeam consoles, Proxmox backup endpoints, SMB shares with backup folders, anything they can reach. If your backup credentials are domain admin and your backup share is writable by everyone, you've handed the attacker a way to destroy your safety net.

I treat backup systems like crown jewels:

  • Separate admin credentials, not shared with production domain
  • Network isolation — backup VLANs with no inbound from user networks
  • Immutable storage where possible (object lock, WORM tapes, ZFS snapshots with hold flags)
  • Alerting on any backup deletion event, even authorized ones

If you want to understand what happens when attackers get creative, check out my earlier breakdown of real attack scenarios (https://furkanikkan.com/urun/saldirganlar-sirketleri-nasil-ihlal-eder-gercek-saldiri-senaryolari-41). The backup server is always on the target list.

Forgetting That DR Plans Expire

A DR plan written two years ago is probably wrong today. VMs were added, storage paths changed, someone rotated credentials and didn't update the runbook, the offsite replication target ran out of space three months ago and nobody noticed.

I schedule a DR review every quarter. Not a full drill every time — but at minimum, I verify:

  • Backup jobs are still running and succeeding
  • Retention policies match current storage capacity
  • Runbook credentials are still valid
  • Offsite copies are actually syncing (not just queued)
  • RTO/RPO numbers still match business expectations

What Actually Matters When Things Go Wrong

When a real incident hits, you won't be calm and collected. You'll be stressed, under pressure, and probably getting asked every five minutes when systems will be back. That's exactly when a solid DR plan earns its keep. The companies that recover in hours instead of weeks aren't the ones with the most expensive tools — they're the ones who tested their restores, kept copies offsite, wrote runbooks someone else could follow, and locked down backup access before the bad day arrived.

Start small if you have to. Pick one critical system this week. Restore it. See what breaks. Fix it. Then move to the next one. A DR plan you've actually tested is worth ten that look perfect on paper.

Cover image: USDAgov · PDM (Openverse / kamu malı) · https://www.flickr.com/photos/41284017@N08/8058113576