Ransomware Reality Check: Backups That Actually Save You

Quickstart

If you only have an hour or two, do these high-leverage moves first. The goal is simple: make sure you have at least one backup an attacker can’t erase, and prove you can restore it.

Overview

Ransomware is a business problem disguised as malware: attackers aim to stop operations and pressure you into paying. Backups are your best “no” — but only if they’re designed for an adversary who can log in, not just a disk that fails.

Core concepts

1) The ransomware backup threat model (why “it’s on the network” matters)

Traditional backups were designed for accidents: disk failure, bad deployments, human mistakes. Ransomware adds an adversary who tries to destroy recovery. That usually looks like:

• Steal privileged credentials (phishing, token theft, lateral movement)
• Disable backup agents or delete jobs/snapshots
• Delete or encrypt backup repositories and catalogs
• Exfiltrate data to add pressure (double extortion)

The key insight: if backups are writable with day-to-day admin credentials, they’re part of the same failure domain.

2) RPO and RTO: the two numbers that shape everything

Backups are about outcomes. RPO and RTO translate “security” into “operations”.

3) 3-2-1-1-0: the backup principle that survives attackers

3-2-1 is a solid baseline. Ransomware pushes you to add “1-0”: one immutable/offline copy, and zero errors verified by restore tests.

4) Separation: identities, networks, and blast radius

Ransomware resilience is mostly about separation: making sure compromise of one area doesn’t grant control over everything.

Step-by-step

This section is a practical build plan. You can apply it to a home lab, a startup stack, or a mid-size org. The names of tools vary, but the architecture and habits stay the same.

Step 1 — Inventory what you must restore (and in what order)

In a real incident, you don’t restore “everything at once”. You restore capabilities: identity, core services, apps, then endpoints. Start by listing:

This tiering prevents the classic failure: restoring an application before the identity or database it depends on.

Step 2 — Set RPO/RTO per tier and choose a backup method that can meet it

Different systems need different strategies. A database usually wants point-in-time recovery; a static file share may not. Use this mapping as a starting point:

Step 3 — Build a two-layer recovery architecture (fast layer + survivable layer)

A useful mental model is two layers:

Step 4 — Harden the backup plane (make deletion hard)

Most backup failures during ransomware aren’t “the backup job failed.” They’re: someone logged into the backup console and deleted the history. Harden the backup plane like it’s production.

Step 5 — Automate backups + retention + basic verification

Automation is how you keep backups boring (boring is good). Below is a practical example using a versioned backup tool and an object store as a repository. Adapt the concepts to your platform: schedule, encrypt, retain, and verify.

#!/usr/bin/env bash
set -euo pipefail

# Example: a simple encrypted, versioned backup routine (adapt to your tooling)
# - Initializes repository (once)
# - Runs backup
# - Applies retention ("forget/prune")
# - Performs a lightweight integrity check
#
# Tip: store credentials in a secret manager, not in this file.

export RESTIC_REPOSITORY="s3:https://s3.example.com/my-backups"
export RESTIC_PASSWORD_FILE="/etc/backup/restic.pass"
export AWS_ACCESS_KEY_ID="$(cat /etc/backup/s3_access_key)"
export AWS_SECRET_ACCESS_KEY="$(cat /etc/backup/s3_secret_key)"

HOST_TAG="$(hostname -s)"
DATE="$(date +%F)"

# 1) Initialize repo once (idempotent-ish check)
if ! restic snapshots >/dev/null 2>&1; then
  restic init
fi

# 2) Backup critical paths (tune per host)
restic backup \
  /etc \
  /var/lib \
  /srv \
  --tag "${HOST_TAG}" \
  --tag "daily" \
  --exclude-file="/etc/backup/excludes.txt"

# 3) Retention policy (example):
#    - keep 7 daily, 4 weekly, 12 monthly snapshots per host
restic forget --tag "${HOST_TAG}" \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 12 \
  --prune

# 4) Lightweight verification (spot-check metadata + a small sample)
#    Full verify is heavier; schedule it weekly/monthly.
restic check --read-data-subset=1/50

echo "[OK] Backup finished for ${HOST_TAG} on ${DATE}"

Step 6 — Keep backup policy in a config file (so it’s reviewable)

Teams often “configure backups” in a UI and never write down what they did. Treat backup policy like code: it should be readable, reviewable, and versioned.

# Example: a readable backup policy file you can version-control (conceptual)
# Use this as a template even if your tool uses a different format.

backup_policy:
  name: "core-servers"
  schedule:
    daily: "02:15"
    weekly: "Sun 03:10"
  retention:
    daily: 7
    weekly: 4
    monthly: 12
    yearly: 3
  data_scope:
    include:
      - "/etc"
      - "/srv"
      - "/var/lib"
    exclude:
      - "/var/lib/docker"
      - "/var/tmp"
      - "**/*.iso"
  security:
    encryption: true
    repository:
      type: "object-store"
      offsite: true
      immutable: true          # enforced by storage policy, not just client settings
    identities:
      backup_operator_mfa: true
      writer_cannot_delete: true
  verification:
    smoke_restore:
      frequency: "weekly"
      target: "isolated-restore-vm"
      checks:
        - "checksum_sample"
        - "app_health_check"
    full_integrity_check:
      frequency: "monthly"

Step 7 — Test restores like a fire drill (and measure your real RTO)

Restore testing has two layers: technical and operational. Technical tests prove bits can be restored. Operational tests prove people can do it under time pressure.

You can automate parts of this. The script below demonstrates a simple concept: periodically restore a random sample and verify integrity with hashes. Even if you don’t use this exact script, the pattern is the win.

import hashlib
import os
import random
import subprocess
from pathlib import Path

"""
Conceptual restore test:
- Restore a snapshot (or file sample) into an isolated directory
- Compute hashes for a sample of files
- Compare with expected hashes if you have them (or store as "golden" over time)

Adapt to your backup tool by replacing the restore command.
Run in an isolated environment, not on production hosts.
"""

RESTORE_DIR = Path("/tmp/restore_test")
SAMPLE_FILES = 25
MAX_FILE_BYTES = 10 * 1024 * 1024  # skip very large files in smoke tests

def sha256_file(path: Path) -> str:
    h = hashlib.sha256()
    with path.open("rb") as f:
        for chunk in iter(lambda: f.read(1024 * 1024), b""):
            h.update(chunk)
    return h.hexdigest()

def restore_snapshot(snapshot_id: str) -> None:
    # Example placeholder restore command. Replace for your environment/tool.
    # e.g., restic restore SNAPSHOT --target /tmp/restore_test
    subprocess.check_call(["restic", "restore", snapshot_id, "--target", str(RESTORE_DIR)])

def list_restored_files(root: Path) -> list[Path]:
    files: list[Path] = []
    for p in root.rglob("*"):
        if p.is_file():
            try:
                if p.stat().st_size <= MAX_FILE_BYTES:
                    files.append(p)
            except FileNotFoundError:
                # In case files are moved during listing; ignore
                continue
    return files

def main() -> None:
    RESTORE_DIR.mkdir(parents=True, exist_ok=True)

    # Pick a snapshot id (you can also select "latest" with your tool)
    snapshot_id = os.environ.get("SNAPSHOT_ID")
    if not snapshot_id:
        raise SystemExit("Set SNAPSHOT_ID env var to a snapshot you want to smoke-restore.")

    # Restore into isolated directory
    restore_snapshot(snapshot_id)

    # Sample files and hash them
    files = list_restored_files(RESTORE_DIR)
    if not files:
        raise SystemExit("No files restored; check restore command and snapshot contents.")

    sample = random.sample(files, k=min(SAMPLE_FILES, len(files)))
    print(f"Restored files found: {len(files)} | Hashing sample: {len(sample)}")

    for p in sample:
        digest = sha256_file(p)
        print(f"{digest}  {p}")

    print("OK: smoke-restore completed (hash sample printed).")

if __name__ == "__main__":
    main()

Common mistakes

These are the patterns behind “we had backups but still paid” or “recovery took weeks.” Each mistake includes a practical fix you can apply without rebuilding everything.

FAQ

Do backups stop ransomware?

No—backups don’t prevent infection. Backups prevent ransomware from becoming a business-ending event by letting you restore without paying. Pair backups with prevention (patching, MFA, EDR) and detection (alerts, logging) for real resilience.

What’s the difference between “offsite” and “air-gapped” backups?

Offsite means geographically/separately hosted; air-gapped means not continuously reachable. Many “offsite” backups are still reachable via the same cloud account and credentials. Air gap is about access path and blast radius, not distance.

Are cloud backups automatically safe from ransomware?

Not automatically. Cloud storage can be deleted or overwritten if an attacker has the right permissions. The safety comes from immutability (WORM/object lock), least-privilege identities, and separating backup access from daily admin access.

How often should we test restores?

Weekly for a small smoke test and quarterly for a full scenario is a practical baseline. If your systems are high-change or high-stakes, increase frequency. The goal is to keep restore steps fresh and catch silent failures early.

How long should we keep backup retention to handle late discovery?

Use multiple horizons: daily for quick rollback, weekly/monthly for late discovery, and a longer immutable archive for worst-case scenarios. Retention should reflect how quickly you can detect compromise and how long you need for compliance.

What should we restore first after a ransomware event?

Restore Tier 0 first: identity, DNS, secrets, certificates, and core networking—then databases and critical apps. Restoring apps before identity and data usually creates a mess (and can reintroduce compromise).

Cheatsheet

A scan-fast checklist for ransomware-ready backups. Print it, paste it into a ticket, or turn it into your internal standard.

Wrap-up

Ransomware-ready backups aren’t about buying a bigger storage box. They’re about designing for an attacker who can log in. If you remember one thing: survivable backups require immutability, separation, and restore testing.

If you want to level up beyond backups, the next steps are about reducing initial compromise and limiting blast radius: threat modeling your environment, hardening authentication, and building a DevSecOps pipeline that prevents risky changes. UniLab has related guides to help:

• Threat Modeling in 45 Minutes: A Lightweight Template
• Passkeys, MFA, Sessions: Modern Authentication Done Right
• DevSecOps Basics: Add Security to CI/CD Without Chaos

Related posts

• OWASP Top 10 in Real Life: How Apps Actually Get Hacked
• Threat Modeling in 45 Minutes: A Lightweight Template
• Passkeys, MFA, Sessions: Modern Authentication Done Right
• API Security Checklist: Auth, Rate Limits, and Abuse Cases
• DevSecOps Basics: Add Security to CI/CD Without Chaos
• Dependency Attacks: How One Package Can Burn Your App