Backup Your Data Securely: Expert Guide for Modern Security

Ransomware operators no longer just encrypt your production files and wait for a payment. Modern strains actively hunt for backup infrastructure first, because a working backup is the single thing that makes an organization say no to a ransom demand. If your data security strategy treats backup as an afterthought bolted onto a firewall and antivirus stack, you are leaving the exact door open that attackers are trained to look for. This guide walks through how ransomware specifically targets backups, and what a genuinely resilient, security-first backup architecture looks like.

Want expert help putting this into practice? B-Backup Pro can guide you through it.

How ransomware actually goes after your backups

Once an attacker has a foothold on a network — usually through a phished credential, an exposed RDP port, or an unpatched VPN appliance — the playbook rarely jumps straight to encryption. There is almost always a reconnaissance phase where the attacker maps out what backup software is installed, where backup servers live on the network, and which accounts have access to them. This matters because encrypting production files while a clean backup sits untouched is a failed attack from the attacker's point of view.

Three techniques show up repeatedly in incident post-mortems and vendor threat research:

• Shadow copy deletion. Windows Volume Shadow Copy Service (VSS) snapshots are a common local recovery point. Commodity ransomware routinely runs vssadmin delete shadows /all /quiet or equivalent WMI calls before or during encryption, specifically to remove the easiest, fastest recovery option available to an IT team.
• Mapped and reachable network drives. If your backup repository is exposed as an SMB share that a compromised domain account can read and write to, ransomware's file-encryption routine will happily walk that share like any other mapped drive. A backup target that is reachable the same way production data is reachable is not really a separate line of defense — it is an extension of the same blast radius.
• Backup software credentials and consoles. Backup platforms typically run with elevated service accounts so they can read every file on every server. Attackers who obtain domain admin credentials will frequently log into the backup console itself, disable scheduled jobs, delete retained restore points, or reconfigure retention down to nothing — all before triggering encryption, so that by the time the IT team goes looking for a restore point, there isn't one.

Why "backed up" and "recoverable" are not the same claim

Related: Backup Your Data Securely Tips: Essential Guide for Modern Security.

A backup job can report success every single night and still be worthless in a ransomware scenario if it was reachable and deletable by the same compromised credentials that hit production. This is the gap most organizations discover only during an actual incident: the backup existed, but it was inside the same trust boundary as everything else that got encrypted. True recoverability requires that at least one copy of your data sits somewhere an attacker with full domain control still cannot reach, modify, or delete within your normal retention window. That is a fundamentally different design goal than simply "having a backup job that runs."

Air-gapped and immutable copies — the actual defense

Two concepts do the real work here, and they are often confused with each other:

• Air-gapped backups are physically or logically disconnected from the production network outside of the brief window needed to write new data. Rotated offline tape, or a cloud target that authenticates through a separate identity provider with no trust relationship to your domain, both qualify. The key property is that there is no persistent network path an attacker's malware can traverse to reach the copy.
• Immutable backups use object-lock or WORM (write once, read many) storage semantics so that once a backup is written, it cannot be altered or deleted — not by an administrator, not by a compromised service account, not even by the backup software itself — until a retention timer expires. This defeats the "log into the console and delete the restore points" step of the attack even if the attacker does gain valid credentials.

The strongest posture combines both: immutability so a compromised admin account can't delete recent restore points, and air-gapping or credential isolation so the copy isn't sitting inside the same identity fabric as the rest of the network. Neither alone is a complete answer. Immutability without network isolation still leaves a copy discoverable and encryptable if the immutability window has lapsed or is misconfigured; air-gapping without immutability still leaves a window during the sync where an attacker who has been dwelling on the network could corrupt what gets written.

Isolating backup infrastructure from the production network

See also: Backup Your Data Securely: Expert Best Practices for Digital Safety.

Segmentation is not a nice-to-have here — it is the difference between a contained incident and a total loss event. Practical steps that consistently show up in resilient environments:

• Put backup servers and repositories on their own VLAN with tightly scoped firewall rules, rather than leaving them addressable from every subnet like a general file server.
• Use a separate authentication domain or at minimum separate, non-privileged credentials for the backup service account — never reuse domain admin for backup jobs, and never let backup service accounts have interactive login rights on production hosts.
• Restrict outbound connectivity from the backup repository itself; a repository that can only receive data via a one-way protocol is far harder to reach from a compromised endpoint than one with bidirectional, browsable access.
• Apply multi-factor authentication to the backup management console specifically, not just to general network login — consoles are a favorite target precisely because compromising one grants control over every recovery point.

This is the architectural equivalent of not storing your spare house key under the same mat as your front door key. If the backup repository is one hop away from anything a phished employee's laptop can reach, segmentation has effectively not happened.

Detecting a compromised backup before you restore from it

One of the more damaging mistakes during incident response is restoring from a backup that was itself already infected — either because the ransomware had been dwelling silently for days or weeks before triggering encryption, or because a webshell or backdoor got backed up along with legitimate files. Restoring blindly can reintroduce the exact foothold that caused the incident in the first place.

Before trusting a restore point, look for:

• Retention depth that predates the incident. If your retention policy only keeps seven days of restore points and dwell time in the affected environment was three weeks, every available copy may already be compromised — this is the strongest practical argument for retention windows measured in months, not days, on at least one tier of backup.
• File integrity anomalies. A sudden spike in file modification counts, unusual file extensions, or unexpected encryption-like entropy in a nightly change report is a signal to quarantine that restore point rather than trust it by default.
• Scan-before-restore workflows. Restoring into an isolated, non-networked sandbox first and running endpoint detection tooling against it before reconnecting to production is slower than a direct restore, but it is the only way to confirm a restore point is genuinely clean rather than assumed clean.

Treat every restore during an active or recent incident as guilty until proven innocent. The goal is not just to recover data quickly — it is to recover data without re-detonating the same problem.

Building this into an ongoing practice, not a one-time project

Ransomware-resistant backup is not a configuration you set once and forget. Attackers adapt, retention needs change as data volumes grow, and access lists drift as employees change roles. A disciplined practice includes quarterly restore testing against real (not simulated) data volumes, periodic review of exactly which accounts can reach the backup repository, and a documented, rehearsed incident runbook that specifies which restore point tier to use depending on how long the attacker appears to have been present. Providers built specifically around this threat model — B-Backup Pro is one example — structure their retention, immutability, and network isolation defaults around exactly this kind of scenario rather than treating ransomware resilience as an optional add-on tier. Whatever platform you use, the underlying principle does not change: a backup that an attacker with domain-level access can still reach, alter, or delete is not a security control, it is a false sense of one. Real data security means designing the backup itself to survive the same compromise that took down production.