Backup strategy against ransomware: immutable backups, air-gap and rapid recovery

A Backup-Strategie gegen Ransomware today is less a question of “do we have backups?” and more “can we actually RESTore cleanly after a targeted attack?”. Ransomware groups no longer only encrypt file shares; they specifically target backup servers, repositories, admin accounts, hypervisor hosts and databases. In many incidents the real disaster is not the encryption itself but that backups are either encrypted alongside, deleted, tampered with or simply not RESTorable.

This article shows a practical approach to combining three building blocks: Immutable Backups (immutable backups), Air-Gap (a technical or organizational separation) and a fast recovery based on tested runbooks. The focus is on operational reality: identities, privileges, network paths, retention, monitoring, RESTore validation — and on typical pitfalls that cost minutes or days during a crisis. Since many enterprise environments use MariaDB (e.g. for portals, monitoring, asset tools or bespoke business software), the guide also includes concrete best practices for MariaDB-consistent backups and Point-in-Time-Recovery.

Backup-Strategie gegen Ransomware: Warum Ransomware Backups heute gezielt angreift

Ransomware is now typically a multi-stage attack: Initial Access (e.g. via phishing, exploited VPN gateways, unpatched web services), lateral movement, privilege escalation and then the deliberate „rollout“ of encryption. Backups are a primary target because functioning backups undermine extortion.

Typical attack vectors in the backup context:

• Backup servers as a “Single Point of Control”: If the backup console can write/delete across the domain, a compromised admin account is sufficient for total failure.
• Repository manipulation: Deleting RESTore points, shortening retention or creating “synthetic” backups that continue from already encrypted data.
• VSS/Snapshots and storage snapshots: Windows VSS (Volume Shadow Copy Service) and storage snapshots are deleted to remove quick rollback points.
• Credential harvesting: Backup credentials are often stored in plaintext in scripts, on jump hosts or as reused service accounts.
• Compromising backup chains: Incremental chains (e.g. forever incremental) can be “poisoned” if the base is not protected.

The consequence: a backup design must not only “copy data” but must limit attack paths, prevent manipulation and make RESToration predictable.

Define protection objectives clearly: RTO, RPO and “Clean RESTore”

Before selecting technology, define protection objectives:

• RPO (Recovery Point Objective): What amount of data loss is acceptable? Example: 15 minutes for a MariaDB, 24 hours for an archive.
• RTO (Recovery Time Objective): How quickly must a service be back online? Example: 2 hours for authentication/ERP integrations, 8 hours for reporting.
• Clean RESTore: RESToration into a clean state. That means: you must prevent RESToring malware, compromised accounts or manipulated configurations.

In ransomware scenarios recovery often fails due to missing sequencing (what first?), missing credentials (Break-Glass), unavailable installation media/keys, or because RESTore processes are too slow since they were never tested realistically. A good backup concept is therefore always also a recovery plan.

Component 1: Understanding immutable backups correctly (and applying them correctly)

Immutable Backups are backups that cannot be modified or deleted for a defined period of time – not even by administrators. Depending on the technology this is implemented as WORM (Write Once, Read Many), as “Object Lock” in S3-compatible object storage, or as repository-native immutability.

What matters for immutability in practice

Immutability is only as strong as the control over the “switches”:

• Independent identity: If the same domain admin accounts can also change object-lock policies, immutability is vulnerable. The goal is a separated identity and rights domain.
• Policy „write-protect“: Ideally retention cannot be shortened (compliance/governance mode vs. a true lock). Verify whether a “root” account can lift the lock.
• Time integrity: In some designs time/clock is a factor. If an attacker manipulates time sources or forces a policy to appear “expired,” it becomes critical. Use secured NTP sources and monitoring for time drift.
• Minimize network path: The fewer systems that have write rights to the immutable repository at all, the better.

Typical pitfalls with immutable backups

• Immutability only „on paper“: A storage snapshot is not automatically immutable if the storage admin can delete it.
• Retention too short: Many attacks are discovered late. If your immutable backups only persist for 7 days, that can be insufficient.
• No RESTore tests: Immutable does not automatically mean readable or consistent. Corruption, incorrect catalogs or missing keys are real risks.

Rule of practice: Immutability is a control mechanism against tampering, not a substitute for multiple copies and not an air gap.

Component 2: Air-Gap – technical, organizational or both

Air-Gap means separation: backups are not permanently reachable from the compromised network. This can be implemented “hard” (physically separated media) or “soft” (temporarily separated network paths, separate credentials, one-way transfers).

Air-gap variants that work in operations

• Offline media: Tape (LTO) or removable storage units that are physically separated after the backup. Advantage: very robust against network attacks. Disadvantage: process discipline, logistics, RESTore time.
• Isolated backup network: Backup servers/repository in a separate segment, with RESTrictive firewall rules and no general Internet access. Important: segmentation is not an air gap if attackers can still move via admin accounts.
• One-Way-Transfer / Staging: A ‚landing‘ repository accepts backups, a second system pulls the data and is not writable from the production zone. This reduces the risk that production accounts can delete the ‚last‘ backup store.
• Cloud-Object-Storage with Object Lock: Not a classical air gap, but combined with strict identity separation and minimal API rights often a very robust offsite component.

The important question is: How does your design prevent a compromised domain admin from also ‚administering‘ the air gap? The answer is usually: separate identities, separate systems, separate access paths (jump hosts), and preferably pull-based data flows.

Building block 3: Rapid recovery is a design objective, not an afterthought

‚Fast‘ depends not only on bandwidth and storage, but on process and parallelization. In ransomware incidents you often need to reinstall, rotate credentials, isolate the network, capture forensic evidence and prioritize services concurrently.

RESTore priorities: What must come back online first

Create a technical RESTart sequence. Commonly effective:

1. Identity and basic services: DNS, NTP, directory services (with special caution), PKI/certificates, jump host.
2. Virtualization/compute layer: hypervisor management, storage access, where applicable container orchestration.
3. Data platform: MariaDB/PostgreSQL/SQL Server, message queues, central file services.
4. Core applications: process-near software solutions, integrations, interfaces (API gateways).
5. Downstream systems: BI/reporting, dev/test, archive.

This sequence must fit your landscape. Crucial: you want to avoid dependencies that block the RESTore (e.g. ‚backup keys are stored in the encrypted file share‘).

The 3-2-1-1-0 rule as a guideline (and what it doesn’t solve)

The well-known 3-2-1 rule (3 copies, 2 media, 1 offsite) is often extended to 3-2-1-1-0 in the ransomware context:

• 3 copies: production data + at least two backup copies.
• 2 different media/targets: e.g. disk + object storage or disk + tape.
• 1 offsite: geographically separate (cloud or a second data center).
• 1 copy offline or immutable: this is the anti-ransomware lever.
• 0 errors in verification: regular checks and RESTore tests, not just ‚job was green‘.

What the rule doesn’t solve: incorrect permissions, compromised admin accounts, missing runbooks, missing keys/passwords or RESTore paths that are too slow. For these you need concrete operational measures.

Backup architecture against ransomware: reference patterns for operations

A practical pattern for medium-sized environments is a multi-stage backup chain:

• Primary backup repository (fast): for short RTOs, quick RESTores (e.g. last 7–30 days), ideally close to compute (but separately segmented).
• Immutable/offsite repository: object storage with immutability or a second system with WORM capability, longer retention.
• Optional offline copy: Tape or periodically exported offline media for „worst case“ (e.g. when cloud accounts are affected).

Important are the access directions: write access only where absolutely necessary; for the ‚last‘ copy prefer pull mechanisms. The fewer systems that can delete backups, the better.

Identities and permissions: the most common reason backups are destroyed

Many backup designs do not fail because of storage, but because of Identity & Access. A few robust principles:

• Backup accounts are not domain admins: Separate roles. Backup typically needs read rights on sources and defined rights on targets, but no full authority in the directory.
• Separate admin paths: Backup console and repository administration only via hardened jump hosts (not a normal admin notebook).
• MFA and Conditional Access: Enforce where possible. Especially for cloud APIs and backup management.
• Break-glass accounts: Emergency access accounts documented offline, strictly monitored and used only for recovery.
• Secret management: Do not „hide“ passwords/keys in scripts or task schedulers. Use a secrets vault or at least OS-native secure credential stores.

If you must prioritize a single measure: Protect the backup identities as strongly as your domain or cloud root identity. In incidents this is exactly the lever that determines whether you are able to RESTore.

MariaDB under ransomware pressure: consistent backups, PITR and fast RESTores

MariaDB is often a central component of digital enterprise solutions. Under ransomware the database is doubly critical: (1) it contains operational data, (2) it is frequently the target of indirect damage (encrypted storage LUN, manipulated binlogs, destroyed InnoDB tablespaces).

Which MariaDB backup types are suitable for which purposes

• Logical backup (dump): exports SQL contents. Advantage: portable, easily verifiable. Disadvantage: slow with large data volumes, RESTore takes long, not ideal for short RTO.
• Physical backup (file-/block-based): copies database files (e.g. InnoDB). Advantage: faster RESTore possible. Disadvantage: consistency requires a clean mechanism (hot-backup tool or correctly orchestrated snapshots).
• Point-in-Time-Recovery (PITR): combination of full backup + binlogs (binary logs). Advantage: RPO down to minutes/seconds. Disadvantage: binlogs must be complete, unaltered and time-consistent.

For ransomware recovery, PITR is often the difference between „last night’s backup“ and „we only lose a few minutes“. However, PITR is only as good as your binlog discipline (rotation, transport, protection, monitoring).

Practical setup: full backup + binlog shipping (with Immutability target)

A proven pattern: regular full backups (e.g. nightly) and continuous copying of binlogs to a separate, preferably immutable destination. This allows you to roll back to a point before the encryption.

Important prerequisites in MariaDB:

• Binary logging enabled: binlogs are the change logs. Without them no PITR.
• GTID or clean position management: facilitates reproducible replay, but depends on your replication/operations model.
• Separate export path: do not keep binlogs only locally on the same volume as the database.

Example configuration snippets (adjust path/parameters to your environment):

[mysqld]
log_bin = mariadb-bin
binlog_format = ROW
expire_logs_days = 3
sync_binlog = 1
server_id = 123

Why this is chosen: ROW-based binlogs are usually more reliable for PITR and replication in heterogeneous workloads than STATEMENT (fewer surprises from non-deterministic statements). A short local expire does not protect against attacks, but it reduces local storage usage – the real protection concept is offsite/immutable shipping.

Binlog shipping with robust error handling (example via rsync over SSH to a separate destination, ideally to a target that itself does not allow delete rights back):

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

SRC_DIR="/var/lib/mysql"
DEST_HOST="backup-ingest.example.net"
DEST_DIR="/data/mariadb-binlogs/$(hostname -f)/"

# Nur Binlogs übertragen, keine Löschungen auf der Gegenseite auslösen.
# So vermeiden Sie, dass lokale Rotation remote historische Logs entfernt.
rsync -av --ignore-missing-args 
  --include='mariadb-bin.*' --exclude='*' 
  "${SRC_DIR}/" "${DEST_HOST}:${DEST_DIR}"

When this fails: If the target server is in the same identity and admin domain as production, an attacker can compromise the target server or the SSH keys. For severe scenarios a pull model is stronger: the target server pulls the logs; production has no write rights to the final, immutable store.

RESTore runbook for MariaDB: from „we have backups“ to „we are back online“

A minimally usable runbook for PITR always contains:

• Which backup version is „clean“? (timestamp, indicators, approval by the Incident Lead)
• Where are the full backup, keys, checksums, binlogs located?
• RESTore order: apply the full backup, then apply binlogs up to the target point in time
• Validation: table checks, application health checks, verify users/grants
• Fallback: if PITR fails, roll back to the last consistent full backup state

Also plan an isolation environment for recovery: RESTore first into an isolated network (do not trust “clean” clients), then switch over.

RESTore tests: What you must test (and what is often forgotten)

“Backup job successful” is not a RESTore guarantee. RESTore tests must be realistic but scalable. In practice a mix of the following has proven effective:

• Automated sampling: daily/weekly small RESTores (a fileshare subfolder, a small DB, a VM/container instance).
• Quarterly recovery exercise: full RESTart of a critical service including dependencies, time measurement for RTO.
• Integrity checks: checksums, catalog verification, comparison of file counts/ACLs, DB consistency checks.

For MariaDB useful validations include startup capability, InnoDB recovery logs, spot queries and a defined application health check (e.g. login + core transaction). Important: tests must not endanger production; use RESTore into a test environment or onto isolated hosts.

Checklist: Hardening backup infrastructure against ransomware

The following checklist is intended as a “quick audit”. It does not replace a complete security concept but covers the most common weaknesses.

Repository and storage

• At least one copy is immutable (WORM/Object Lock) or offline.
• Retention cannot be shortened by ordinary admins.
• Repository is not domain-joined unless strictly necessary.
• No general SMB/NFS shares writable by many servers.
• Monitoring for unusual delete/rewrite operations (if the system emits events).

Network and access paths

• Backup network is segmented; firewall rules are minimal (sources → backup, not “any-any”).
• Management access only via jump host; admin access is logged.
• No direct Internet access for backup servers, except for clearly justified exceptions (updates via proxy/repo).

Identities, secrets, operations

• Separate backup accounts, no password reuse, MFA where possible.
• Regular rotation of keys/passwords and a defined process for emergency rotation.
• Break-glass documented (offline), tested and monitored.
• Runbooks are up to date: paths, IPs, credential process, priorities.

Troubleshooting: Common failure patterns and quick checks

“Immutable” can still be deleted

Quick check: Who can change policies? Is there a root/tenant admin who can reduce retention or disable Object Lock? Check roles, API keys, and whether the backup system has “too many” privileges.

Backups exist, but RESTore is too slow

Quick check: the RESTore path is often different from the backup path. Measure RESTore throughput to the target system (I/O, network, unpacking/de-dedupe). Plan parallel RESTores, prioritized data (e.g. critical DBs first) and a “staged RESTore”.

MariaDB backup starts, but PITR aborts

Quick check: missing binlog segments, incorrect time base, rotation deleting too early, or binlogs were manipulated during an attack. Verify completeness (continuous sequence), time drift and whether the binlogs end up in a tamper-resistant target.

RESTore returns encrypted/compromised data

Cross-check: selection of point in time and „Clean RESTore“ authorization are missing. In ransomware incidents it is common that data has already been exfiltrated or manipulated before encryption. Define a „Known Good“ point in time and validate it with anomaly checks (file extensions, mass changes, suspicious DB updates).

Implementation in phases: a realistic migration path without a Big Bang

If you currently run a classic disk backup in the same domain, the path to ransomware-resilient backups can be taken step by step:

1. Prove RESTore capability: introduce automated sample RESTores, measure RTO/RPO.
2. Harden identities: separate backup accounts, establish a jump host, improve MFA/secrets handling.
3. Add immutable target: enable Object Lock/WORM for an additional copy, define retention.
4. Add air-gap component: offline or pull-based offsite design.
5. Runbooks & exercises: at minimum quarterly recovery exercises for critical services.

This reduces risk early without changing everything at once.

Fallback strategy: what to do if the backup ecosystem is also compromised?

A fallback strategy is not pessimism but operational maturity. Plan for the case that backup servers/accounts are compromised:

• Independent offline copy: periodic and verifiable, including documentation on how it can be read.
• Rebuild from „bare metal“: golden images, IaC/config management, package repos, license/key archive.
• Emergency DNS/NTP: small, isolated baseline to be able to execute RESTores cleanly.
• Communication and approval process: who decides the „clean point“, who authorizes the RESTore, who documents.

The decisive point: backups are only one part. In ransomware incidents you must simultaneously regain identities, reset privileges and ensure you do not immediately reopen the same vulnerability.

Conclusion: ransomware-resilient backups are a holistic system

A resilient backup strategy against ransomware arises from the interplay of Immutable Backups, a real Air-Gap (technical or procedural) and a fast recovery that is practiced regularly. What matters less are individual products and more the clean architecture: separated identities, minimized privileges, clear data flows, verifiable retention and rigorous RESTore validation.

If you take three things away from this article: (1) protect backup identities like crown jewels, (2) build at least one immutable or offline copy, (3) test RESTores so that RTO/RPO become measurable — especially for MariaDB including binlogs and point-in-time recovery. Then backup will change from a „mandatory task“ into a reliable recovery tool.

Air-gap backup and ransomware recovery are also important for this topic. The article positions these aspects clearly and shows what matters in daily operations.