Ransomware-Resistant Backups: 3-2-1 and Isolation

Ransomware can threaten backups as well as production data. Attackers may delete reachable backups and snapshots, while undetected compromise can leave recent restore points contaminated. If your hosting backups live on the same server, same network and with the same credentials as production, they remain backups, but share production’s blast radius and may be lost in the same incident.

This guide explains a ransomware-resistant backup strategy using the 3‑2‑1 rule, protected retention and offline or logically isolated recovery copies. The examples cover shared hosting, VPS, dedicated servers and colocation. They are illustrative designs: confirm available panel exports, storage features and operational responsibilities for your service. The aim is a recoverable copy outside compromised production access; no single feature guarantees that a retained copy is clean or usable.

Why Traditional Hosting Backups Can Fail Against Ransomware

The core problem: backups inside the blast radius

Fragile hosting backup setups can include:

• Nightly cPanel or Plesk full backups stored on the same server
• VPS snapshots in the same virtualization cluster using the same credentials
• Database dumps on /home or /root with no encryption or rotation

These approaches can work for accidental deletion or a broken update, but may fail when ransomware reaches the backup storage. Malware may inherit web-application privileges or gain root access. If those privileges allow writes to mounted backup storage, the attacker may be able to encrypt or delete the backups alongside production data.

We discussed this risk more broadly in our guide on how to design a backup strategy with RPO/RTO in mind, but ransomware adds an extra twist: you must assume the attacker will actively target your backup mechanism.

How attackers reach backups in real hosting setups

The following configurations can expose backups on VPS and dedicated servers:

• Reused credentials: One stolen SSH key or password can expose production and backup systems.
• Shared administration: One identity may control the hypervisor, storage and backup jobs.
• Writable mounts: NFS/SMB/iSCSI paths become exposed when the compromised account can modify their contents.
• Broadly privileged automation: Backup credentials accessible to a compromised administrator can extend the incident to the repository.
• Unprotected history: Versioning alone does not stop an identity permitted to delete object versions.

Shared failure and access paths can undermine otherwise useful operational backups. The design should cover multiple copies, media and location differences, as well as protected history and independent recovery access.

3‑2‑1 Rule for Hosting: More Than a Slogan

Refresher: what 3‑2‑1 really means

The 3‑2‑1 backup rule is simple but powerful:

• Three copies: Production plus two recoverable backup copies.
• Two media types: For example, disk and tape. In disk/cloud designs, document the actual independent storage failure domains; a different file format or dataset is not a second medium.
• One off-site copy: A separate physical location. Another account or provider name alone does not establish geographic separation.

For panel and VPS automation, see our 3‑2‑1 backup strategy guide. Ransomware resilience adds protection against compromised identities:

• Keep protected retention history with a documented threat model: which identities can delete, bypass or change protection?
• Maintain an offline or separately controlled recovery copy. Logical isolation limits access; it is not physical disconnection.
• Test that complete data, keys and recovery tooling remain available when production and its credentials are untrusted.

Adapting 3‑2‑1 to shared hosting, VPS and dedicated servers

Here is what a realistic 3‑2‑1 layout can look like on common hosting models:

• Shared hosting: Production files and databases form the first copy. A completed panel/account backup can be a second copy if its actual storage and access boundaries are known. An independent worker can collect files and completed database exports over supported SFTP/rsync or panel export methods, then store them at a separate site. Confirm that all required account settings and restoration permissions are available.
• VPS: Keep completed backups on separate physical backup storage, plus an independently managed off-site copy. A second partition or ZFS dataset on production disks is not a separate disk failure domain. The tool and locked-archive workflow below must fit the chosen backend.
• Dedicated/colocation: Local snapshots or separate backup disks can accelerate recovery; a different-site backup server or object store supplies another location. Separate storage management and recovery identities as well as network access.

Object storage is an access model, not evidence of a different physical medium or independent control plane. Ask which failures can still remove multiple copies.

These layouts are starting points, not automatic proof of 3‑2‑1 compliance: verify the media or storage failure domains, complete recoverable copies and off‑site placement. Ransomware resistance also requires protection against deletion and isolation from compromised production access.

Immutable Backups: Protecting Retained Copies from Ransomware

What “immutable” actually means

Immutable backups use controls intended to prevent a protected copy from being changed or deleted under defined conditions. Administrator resistance depends on the implementation and mode. A retained version can still contain corruption or compromised data; immutability does not establish a clean recovery point.

These mechanisms have different boundaries. The Object Lock examples below use Amazon S3 fixed retention; another S3-compatible product must document and demonstrate its own behavior.

Our S3 Object Lock and versioning guide examines the storage layer in more detail. Here, protected versions are one part of the complete recovery architecture.

Versioning and Protected Retention History

Corruption or tampering may go unnoticed for days, allowing backups to inherit the damage before detection. To retain earlier recovery options, you want:

• Versioning: Retains older object versions when a new version is written, but does not itself deny version deletion.
• Retention: Protects each version under its own mode and retain-until-date. New versions can still be created.
• Recovery selection: A simple delete can add a delete marker while older protected versions survive. Record version IDs and test retrieving the intended version.

An illustrative policy to adapt to your detection and recovery requirements:

1. Configure before uploading: Enable versioning and Object Lock on the selected bucket, then set the required fixed default retention. AWS Object Lock cannot subsequently be disabled, and versioning cannot be suspended.
2. Separate control: Keep bucket-lock administration, governance bypass and legal-hold removal away from the upload identity. An explicit per-object retention setting can override the default; constrain permitted retention values where applicable.
3. Prove the actual result: Upload harmless test data with the intended tool and identity, then inspect its version ID, mode and retain-until-date. Enabling a default does not establish protection of every previously written version; inspect older versions and apply required retention explicitly.
4. Test both sides: Verify that the daily archive-upload identity cannot delete the protected test version or shorten its retention, and that the recovery identity can read it. A governance test does not prove compliance behavior.
5. Choose sufficient history: Size the window for detection delay and recovery investigation. One to four weeks is only an example and may be too short. Preserve older clean recovery points where needed; do not remove their protection just to reduce cost.

These controls protect retained versions within their defined boundaries. A compromised writer can still poison new backups or consume storage, and a delete marker can obscure an older version from ordinary reads. Object Lock does not protect encryption keys: deleting an AWS KMS key can make retained objects unreadable. Keep recovery keys and account access independent, and check retained data for compromise before restoration.

Implementing immutable backups in real hosting scenarios

Let’s map this to illustrative hosting scenarios:

This guide separates the working backup repository from the locked archive tier. A backup worker collects completed, consistent outputs, manages its supported repository, then publishes a complete recovery generation to the independently controlled archive.

• Panel-managed VPS: Let the panel finish its export before collecting it. Confirm that files, database exports, account configuration and restoration requirements are included; an upload in progress is not a completed recovery set.
• Linux VPS: Coordinate application files and database state. A filesystem snapshot is not automatically application-consistent. MySQL transactional dumps have storage-engine and concurrent-DDL conditions; PostgreSQL dumps cover one database and exclude global roles. Physical backups require the database’s supported recovery procedure.
• Dedicated backup server: The worker pulls completed outputs from production through restricted access; production cannot initiate new management connections to the backup server. The worker still processes untrusted source data. It publishes encrypted recovery generations to the archive using a separate limited identity.

A restic snapshot record is not a standalone backup: the corresponding indexes and packs, every referenced tree/data blob within packs, repository configuration and required key files must also be preserved. Do not copy an actively changing repository with an ordinary sync and call it consistent. Quiesce modifications or use a documented consistent-copy/export procedure, retaining every dependency. Only accept a generation after transfer completeness, data checks, retention metadata and an isolated restore have been verified.

For tool-specific details, continue with our Restic and Borg off-site backup guide. Tool choice, repository maintenance and the immutable archive tier are separate design decisions.

Air‑Gapped and Logically Isolated Backups

Physical Disconnection vs Logical Isolation

A physical air gap removes the active network connection to a recovery copy. Logical isolation instead restricts connected systems through identity, network and administration controls. It can reduce access from compromised production systems, but is not physical disconnection.

• Physical: Tape, removable disk or a backup system that is actually disconnected while stored. Plan what happens during the next connection window.
• Logical: Separate accounts, networks and management identities with limited data access. An online server, a firewall rule or a scheduled tunnel does not by itself create a physical air gap.

Automated logical isolation and a less frequent offline generation can serve different operational needs. Choose them against your threat model, recovery objectives and available staff; neither should be treated as a guarantee that the stored data is clean.

Building Logical Isolation for Hosting Workloads

An illustrative design makes each access path explicit:

1. Independent identity: Separate backup administration and account-recovery paths from production panel/SSH access. Give the worker only the operations required by its tool; do not assume write-only access supports a repository.
2. Controlled pull: A backup worker initiates collection of completed exports. Production cannot initiate new connections to the backup management network. The worker must still handle production-supplied content as untrusted input.
3. Restricted connectivity: Avoid always-mounted writable backup shares on production. Limit required transfer endpoints, accounts and commands; inspect both firewall rules and the identities allowed to change them. A short connection window reduces exposure time but remains an access window.
4. Separate archive control: Use a distinct identity for publishing completed encrypted generations. Keep deletion, governance bypass, legal-hold removal and bucket policy changes outside normal upload credentials.
5. Separate administration: Use controlled management entry points and MFA. Shared identity providers, bastions or cloud-account recovery can still connect nominally separate systems; include them in the review.

This design reduces common production-to-backup access paths. Its effectiveness depends on the actual identities, management permissions, network rules and archive controls. Test the production identity’s access rather than assuming that two accounts or VLANs always require two independent compromises.

Minimal physical air gap that is still practical

If you can afford some manual steps, small teams can add a simple physical element:

• Prepare a completed, encrypted recovery generation on the dedicated backup worker.
• Copy it to removable media, read it back, and verify decryption and file integrity.
• Safely unmount and physically disconnect the media after the copy completes.
• Record the generation date, storage location, retention and recovery-key owner; store it at a separate physical location when off-site protection is intended.
• Do not discard the previous clean generation before the new one has passed its acceptance checks.

The offline layer still needs scheduled reading and restoration tests. Media damage, missing keys or contaminated source data can make it unusable even when malware cannot reach it while disconnected.

Designing a Ransomware-Resistant Hosting Backup Architecture

Step 1: Clarify RPO and RTO before buying hardware

Before deciding how many disks or buckets you need, define:

• RPO (Recovery Point Objective): How much data (time) can you afford to lose? 5 minutes, 1 hour, 24 hours?
• RTO (Recovery Time Objective): How quickly must you be back up? Minutes, hours, next business day?

Our RPO/RTO backup planning guide explains how to define acceptable data loss and recovery time. Choose targets from business requirements rather than treating example ranges as promises. Those decisions affect:

• How often you run incremental backups and database dumps
• How long your immutable windows must be
• Whether you need warm standby infrastructure or just cold restores

Step 2: Local fast backups + off‑site immutable layer

For an illustrative VPS, dedicated or colocation workload, separate fast operational recovery from protected historical recovery:

• Near storage: Keep completed backups on separate physical storage where possible. Another dataset on production disks is not independent. Coordinate uploaded files, application configuration and database exports.
• Database method: Use a supported tool/version combination. MySQL 8.4 physical backups can use compatible XtraBackup 8.4 and its required prepare phase; MariaDB has mariadb-backup with its own version and preparation requirements. PostgreSQL has its own dump/base-backup methods. The MySQL backup guide explains those choices.
• Snapshot limits: PostgreSQL filesystem snapshots need all relevant data and WAL plus simultaneous snapshots where data spans volumes. Crash recovery consistency is not the same as coordinating application files and business transactions.
• Locked off-site archive: The worker publishes completed, encrypted recovery generations to a preconfigured target. Verify the actual object-version retention and preserve every referenced data dependency until the last recovery point using it can expire.
• Frequency and cost: Set upload cadence and retained history from RPO, detection delay and recovery investigation. Fourteen to thirty days is an example, not a safe universal window. Include storage growth, retrieval fees and cold-tier retrieval delay in the plan.

Local storage can support a quick operational restore, while a protected off-site generation supplies another recovery option. Actual speed depends on data volume, bandwidth, storage class, preparation and application validation; measure both paths.

Step 3: Separate identities, keys and access paths

Ransomware thrives on shared credentials. To limit blast radius:

• Use a dedicated automation identity and protect its credential files. A separate Unix user does not hide credentials from an attacker who controls host root.
• Keep administrative SSH keys separate from transfer credentials; avoid secrets in shell history, panel notes or source control.
• Document necessary read/list/write/lock operations for the exact tool and backend. Keep archive deletion, retention administration and bypass privileges out of the daily uploader.
• Protect management and account-recovery access with MFA and controlled changes. Console MFA does not itself neutralize a stolen API key.
• Keep independent recovery copies of encryption keys, repository/crypt configuration and tool versions. A compromised restic key can expose repository data; simply changing its password does not replace an already exposed master key.

When discussing storage or colocation with a provider, document the actual management networks, physical locations, retention behavior, responsibilities and recovery support. Confirm which controls are available under your service agreement before treating them as part of the design.

Step 4: Integrate backup checks into your monitoring

Backups you never check are backups you cannot trust. At minimum, your monitoring (Netdata, Prometheus, or whatever you use) should alert on:

• Job result and age: Alert on missed runs, nonzero or partial-success outcomes, and stale last-verified generations.
• Data completeness: Track expected files and size changes; unexplained shrinkage or growth needs investigation.
• Repository and transfer checks: Instrument restic/Borg checks and object transfer results. Default restic check does not read all pack data; plan full or sampled data verification and real restores separately.
• Protection: Check actual retained-version metadata and alert on changes to retention, legal holds, bypass privileges or bucket policies.
• Capacity and recovery dependencies: Monitor storage growth, key availability and retrieval requirements. Monitoring tools require explicit collection of these results; they do not infer backup health merely by monitoring the VPS.

For server-side monitoring and alert configuration, see our VPS monitoring and alerts guide. Backup acceptance still requires explicit job, integrity, retention and recovery checks.

Step 5: Practice restores and DR drills

Set the drill schedule from risk and significant system changes. Monthly small-scope and quarterly full recovery exercises can be an initial plan; neither interval is a universal guarantee of safety.

• Clean isolated environment: Restore without trusting production. Prevent real payments, outbound customer email, webhooks and scheduled jobs during the test.
• Correct recovery point: Use incident timing, logs and data checks to select a clean candidate. Test retrieval of historical object version IDs instead of automatically choosing the newest backup.
• Full dependencies: Exercise single-site/database recovery and full-server recovery, including configuration, roles, permissions, application files and required keys.
• Actual application behavior: Restore the database, inspect representative records and check file-to-database relationships. Run login, order and payment flows in test/sandbox mode.
• Measure the whole path: Include retrieval, decryption, preparation, database loading and validation in the measured recovery time.
• Runbook and reconnection: Record exact tooling, responsibilities and secure key access. In a real incident, remove persistence, fix the entry path and rotate affected credentials before reconnecting recovered systems.

Our hosting disaster recovery drill guide develops the runbook and restore exercise. Use each exercise to record missing dependencies and revise the recovery plan.

Operational Hygiene: Make Backups Part of Overall Security

Hardening the backup pipeline itself

Your backup infrastructure deserves the same care as your production stack:

• Reduce exposure: Restrict backup management ports through controlled access paths and maintain the host and backup software.
• Protect administration: Use MFA and least privilege for consoles and account recovery, while separately controlling automated API credentials.
• Separate roles: Distinguish transfer, recovery and retention-management duties. Production automation should not silently change archive protection.
• Audit changes: Keep independent records of deletion attempts, legal-hold changes, bypass use and retention modifications.
• Review before cleanup: Do not let untrusted client-supplied snapshots or timestamps alone decide which old clean copies to prune.

Review host controls alongside the backup design, using our VPS security hardening checklist. Host hardening does not replace independent archive identities, retention controls and recovery testing.

Backup strategy for different risk levels

Use the following as planning categories rather than fixed service tiers or compliance prescriptions:

• Lower change rate: Start with documented recovery objectives, separate backup storage and a protected off-site generation. Daily local and weekly remote copies are only suitable if losing up to the remote interval is acceptable.
• Transactional workloads: Increase database capture and off-site frequency to meet measured RPO, coordinate application files, and practice critical business recovery flows. Hourly or four-hourly capture is illustrative, not a universal e-commerce requirement.
• Critical recovery needs: Evaluate database-native log-based recovery, independently managed off-site tiers, recovery capacity, separation of duties and incident exercises. Confirm the entire base-backup/log chain and required keys are retained and usable.

Choose protection duration from detection and investigation needs as well as retention obligations. Longer locks consume storage and can prevent a planned deletion; resolve that requirement before applying the period. Encryption or Object Lock alone does not establish legal or regulatory compliance.

The pattern is consistent: complete recovery copies, independent failure and access boundaries, protected history and repeatable restoration. Adjust frequency, retained history and capacity to the workload, and verify the result after material changes.

Verifying the Backup Strategy

A ransomware-resistant backup strategy combines multiple copies with storage and identity separation. Retention protection limits changes to selected versions; offline storage removes an access path while disconnected. Recoverability still depends on complete data, available keys and a tested clean restoration process.

Begin by writing down RPO/RTO and mapping which production credentials can reach each copy. Then test one complete recovery generation in an independent environment. Use the findings to address missing exports, shared administration, insufficient retention, unavailable keys or an unrealistic recovery time.

When reviewing your hosting arrangement, ask for the backup scope, physical location, retention mode, access responsibilities and restoration support in writing. A successful upload is the start of the evidence; the useful outcome is an application you have actually recovered and checked.

Technical References

• 3-2-1: Veeam
• CISA: #StopRansomware Guide
• Amazon S3 Object Lock
• Amazon S3: Object Lock configuration
• Amazon S3: managing Object Lock
• Restic: repository format and threat model
• Restic: forget and prune
• Restic: repository checks
• Borg 1.4: repository locations
• Borg 1.4: append-only mode
• rclone copy
• rclone sync
• rclone crypt
• MySQL 8.4: mysqldump
• XtraBackup 8.4: prepare
• MariaDB Backup
• PostgreSQL 17: pg_dump
• PostgreSQL 17: filesystem backups
• Linux chattr
• OpenZFS: snapshot holds