Modern ransomware does not encrypt and hope. It looks for backups first, because a victim who can restore does not pay. Mapped drives, mounted network shares, cloud credentials sitting in a config file: all of it is found and destroyed before anything is encrypted.

3-2-1, and why each number is there

  • 3 copies - the live data and two backups, so losing one still leaves a copy.
  • 2 different media or providers - one provider outage or one account suspension does not take everything.
  • 1 off-site and out of reach - the copy the compromised server cannot delete.

What "out of reach" means in practice

# the server holds a key that can write and cannot delete\n{\n  "Effect": "Allow",\n  "Action": ["s3:PutObject"],\n  "Resource": "arn:aws:s3:::backups/*"\n}\n# object lock or versioning on the bucket, managed elsewhere

A backup the server can delete is a backup the attacker can delete, because at that moment they are the server.

The mounted-share trap

A network share mounted permanently on the server is not a backup destination. It is a folder, and everything that reaches your files reaches it. Mount it for the copy, unmount it after, or push to something that only accepts writes.

Retention has to outlast discovery

Encryption is often triggered weeks after the break-in. Seven days of retention means every copy you hold was taken after they were already inside. Keep monthly copies for a year.

And test the restore

The moment you need it is the worst possible time to discover the archive is truncated or the dump does not import. Restore one to a spare machine on a schedule - see testing a restore and when the backup is also corrupt.