Most backup advice stops at "have backups." Ransomware operators know this, which is why modern attacks spend days or weeks quietly finding and destroying backups before they encrypt anything. The question isn't whether you have a backup. It's whether the backup survives the attack, and whether anyone notices in time.

This post walks through a realistic incident timeline and shows where each layer of a 3-2-1 strategy, with Duplicati handling the offsite copy, actually makes the difference.

The 3-2-1 rule, briefly

Three copies of your data, on two different media, with one copy offsite. It's old advice, but ransomware has given each part a new job:

• Three copies means an attacker has to destroy more than one thing to hurt you.

• Two media means a single compromised system (say, a NAS with an exposed admin interface) doesn't take everything with it.

• One offsite means the copy that matters isn't reachable from the network the attacker owns.

Duplicati typically plays the role of that third, offsite copy: encrypted, versioned, and pushed to cloud or remote storage the attacker can't simply browse.

A timeline: what an attack actually looks like

Day 0 — Initial access. A phishing email lands, or a VPN appliance goes unpatched. Someone now has a foothold on a workstation. Nothing visible happens.

Days 1–14 — Reconnaissance. The attacker moves laterally, harvests credentials, and maps the network. A key task in this phase is locating backups. Network shares named "Backup," NAS devices with default passwords, and locally stored backup files are all found and catalogued. If the backup software's credentials are on the compromised machine, those get harvested too.

Day 15 — Backup destruction. Before encrypting anything, the attacker deletes or encrypts every backup they can reach. Volume shadow copies are wiped. The NAS share is emptied. If your only backup was on the same network with write access from a domain account, it's gone now.

Day 16 — Encryption and the ransom note. Production systems are encrypted. This is the first moment most organisations realise something is wrong.

Day 16 onward — Recovery. This is where the strategy either works or doesn't.

Where each layer earns its keep

Versioning: recovering from before the damage

Ransomware doesn't just delete data; it often corrupts it slowly, or encrypts files that then get dutifully backed up in their encrypted state. A backup that only keeps the latest version will happily overwrite good data with ransomed data.

Duplicati's block-based backups keep multiple versions according to your retention policy, and because only changed blocks are stored, keeping weeks or months of history is cheap. In the timeline above, that means you can restore from Day 14 (before backup destruction started) rather than from whatever state the attacker left you in. The retention policy is the setting to think hardest about here: a "keep everything for 30 days, then thin out" schedule covers the typical dwell time far better than "keep the last 7 versions."

Encryption: making stolen backups useless

Modern ransomware groups run double-extortion: they exfiltrate data before encrypting it, then threaten to publish. Backup archives are an attractive target for exfiltration because they're neatly packaged copies of everything.

Duplicati encrypts every backup with AES-256 before it leaves the machine, using a passphrase the storage provider never sees. An attacker who gains access to your cloud bucket gets opaque blobs. This doesn't stop the attack, but it removes the leverage of "we'll leak your backups," and it means a breach at your storage provider isn't automatically a data breach for you.

The practical caveat: the passphrase must be stored somewhere that survives the incident. A password manager with offline export, or a sealed copy in a physical safe, is standard practice.

Offsite with limited credentials: the copy the attacker can't reach

The offsite copy only helps if the attacker can't delete it. Two things matter:

1. Credentials with minimal permissions. Where the storage backend supports it, give Duplicati write and list access but not delete, or use object-lock/immutability features on the bucket. Even if the backup credentials are harvested on Day 3, the attacker can't purge history.

2. Not a mapped drive. A cloud bucket or SFTP target accessed only through Duplicati is invisible to ransomware that walks the filesystem looking for things to encrypt.

Monitoring: shrinking the gap between Day 15 and Day 16

Here is the part most strategies neglect. In the timeline, backups were being destroyed for a full day before the ransom note appeared. Backup jobs failing, backup sizes suddenly changing, or a job that hasn't reported in are all early signals — if anyone is looking.

When each machine reports its backup status locally, nobody is looking. With backups reporting to a central view like the Duplicati Console, a job that fails on Day 15, or a backup that suddenly grows because every file changed at once, shows up as an alert across the whole fleet. For an MSP watching dozens of clients, that centralised signal is often the difference between an incident caught during the destruction phase and one discovered after encryption.

A recovery checklist

When the note appears, the order of operations matters:

1. Isolate affected systems before touching backups. Restoring into a still-compromised network just re-infects the restore.

2. Verify the offsite copy is intact. Duplicati's verification and test-restore functions let you confirm the archive is readable before you commit to a full rebuild.

3. Pick the restore point. Use the version history to find the last clean state — usually a day or two before the first failed job in your monitoring.

4. Restore to clean systems, starting with the most business-critical data.

5. Rotate every credential the backup system used, and re-enable jobs only once the environment is verified clean.

Putting it together

The timeline above ends badly for organizations whose backup was a network share. It ends with a restore and a bad week for those whose offsite copy was encrypted, versioned, held under credentials that couldn't delete it, and monitored closely enough that the first failed job raised an alarm.

None of that requires enterprise-scale budgets. It requires a retention policy chosen with attacker dwell time in mind, a storage target the attacker can't reach, a passphrase kept somewhere safe, and a dashboard someone actually watches.

Ready to see every backup job across your fleet in one place? The Duplicati Console gives you centralized status, alerts on failed or anomalous jobs, and the early warning that turns a ransomware incident into a routine restore. Start your free Console trial or talk to us about MSP and enterprise plans.