How to Keep One Database Backup Ransomware Can't Touch

Why Good Backups Still Disappear During an Attack

Imagine you open your laptop on a normal workday to find your application down, your database inaccessible, and a ransom note in its place. You stay calm because you have automated backups. Then you check your backup location and find the files are encrypted, deleted, or inaccessible too. That moment is the real problem this guide solves.

This happens because many backups live too close to production. They sit on the same server, in the same storage bucket, under the same admin account, and with the same credentials that were just compromised. If an attacker or a malicious script can write to your database, it can often write to your backups as well. Synced folders, mounted drives, and overly broad access keys make this worse.

To protect database backups from ransomware, you have to stop thinking only about creating backups and start thinking about keeping one copy the attacker cannot reach. That copy needs separate credentials, a separate location, and controls that prevent changes even if someone gets full access to production.

What a Survivable Backup Actually Requires

A ransomware-proof copy is not a special product. It is the result of three properties working together. First is isolation, which means the backup lives in a different account or system with different credentials than production. Second is immutability, which means the backup cannot be overwritten or deleted before a retention period ends, even by an administrator.

The third property is recoverability, which means you know exactly how to find that isolated copy and restore it without relying on the systems that were just compromised. If your restore instructions live only in a wiki hosted on the same infrastructure that is down, or your decryption keys are stored next to the encrypted data, you do not have a complete plan.

When all three are in place, a single incident cannot take out production and every recovery path at once. An attacker who compromises your application server should find no valid credentials that allow deletion of the off-site copy. A team member who runs the wrong cleanup command should be stopped by a retention lock and a second approval step.

A Simple Framework: The 3-2-1-1 Rule for Databases

A practical way to organize this is the 3-2-1-1 rule, adapted for databases. It gives you redundancy for hardware failure plus isolation for ransomware and human error. You do not need enterprise tools to follow it, but you do need to be deliberate about where copies live and who can delete them.

Use this as a checklist for any production database, whether it is Postgres, MySQL, or another system. The goal is not more copies in the same place. It is one clean, locked copy somewhere else.

Keep 3 copies of important data: production plus two backup copies

Store copies on 2 different types of storage or locations, for example database-native dumps plus storage snapshots

Keep 1 copy off-site and in a separate account or provider from production

Keep 1 copy immutable or offline, with object lock, retention, or an air-gapped export that cannot be modified

Verify with 0 errors: confirm each copy completes and can be listed and restored from a clean environment

How to Isolate Your Database Backups Step by Step

Start with your most important database and build one isolated path before you try to perfect everything. Pick the backup you would need if production and your primary backup storage were both lost. That is the copy to harden first.

The key change is separation of control. Your daily automated backup can stay convenient for quick restores, but the survival copy should require a different login, a different set of keys, and ideally a different person or approval to delete. Store connection details and encryption keys in a place that stays available during an outage.

Create a dedicated backup storage account or bucket that production servers cannot delete from, only write to

Use separate credentials for backup storage with least privilege and no shared admin keys with production

Enable immutability or retention lock on the survival copy so files cannot be overwritten for 14 to 30 days or longer based on your needs

Require multi-factor authentication for deletion and disable permanent delete for standard roles

Encrypt backups in transit and at rest, and store the decryption key separately from the backup itself

Copy a full logical dump off-account on a regular schedule, not only snapshots tied to one provider

Document the restore steps, endpoints, and contacts in an offline location your team can access during an outage

How to Guard Against Accidental Deletion Too

In practice, human error deletes more backups than attackers do. A cleanup script with a wrong path, an expired lifecycle rule, or a well-meaning teammate tidying up storage can remove the exact files you need. The same controls that stop ransomware also stop these mistakes.

Treat deletion as a sensitive action. Limit who can delete backups, require confirmation for bulk deletes, and keep retention policies explicit. Your team should know how long daily, weekly, and monthly copies are kept, and what happens when someone requests early deletion.

It also helps to separate routine restore access from survival copy access. Developers may need daily backups for debugging, but only one or two trusted people should be able to touch the immutable off-site copy. That separation reduces both risk and confusion during a stressful incident.

Turn on versioning or retention protection so a delete does not immediately destroy data

Review lifecycle and expiration rules twice a year to confirm they do not delete your only good copy

Use distinct names for production, staging, and survival backup locations to avoid confusion

Log all access and deletions for backup storage and review alerts for unusual delete activity

How to Prove Your Safe Copy Will Work When You Need It

An isolated copy is only useful if you can restore it under pressure. You do not need to test every day, but you do need a repeatable check that the files are complete, readable, and usable from a clean system that does not depend on production credentials.

Schedule a short restore drill for your survival copy. Restore to an isolated test environment, verify that the database starts, check a few critical tables and application logins, and time how long the process takes. Write down anything you had to look up, because that is what you will forget during a real incident.

List and verify the off-account backup files without using production servers or keys

Restore the survival copy to a clean, isolated environment and confirm the database starts

Check record counts, recent timestamps, and one end-to-end login or query your app depends on

Record restore time, required credentials, and gaps to fix before the next test

Start With One Isolated Copy This Week

You do not need a perfect system to be much safer than yesterday. Choose one production database, create one off-account copy with a retention lock and separate credentials, and run one test restore. That single survivable copy protects you from the most common worst case, which is losing production and backups together.

Once that is working, make it routine. Automate the off-site copy, calendar the restore check, and write down who owns each step. If you are evaluating how ArmorDB fits into your routine, use this checklist to review where your current copies live and where that one isolated copy should go next.

Frequently asked questions

Can ransomware encrypt cloud database backups?

Yes, if the backups use the same account and credentials as production. Use a separate account, least-privilege keys, and immutability so an attacker with production access cannot overwrite or delete the backup copy.

What is an immutable database backup?

It is a backup that cannot be changed or deleted until a retention period ends. Many object storage services offer this as object lock or retention policy, which helps protect against both ransomware and accidental deletion.

How often should I copy database backups off-site?

At least as often as your recovery point objective requires. Many small teams start with daily full logical dumps off-account plus more frequent snapshots locally, then adjust based on how much data loss they can tolerate.

Should I use the same admin account for databases and backups?

No. Use separate credentials with minimal permissions for backup storage. Production should be able to write new backups but not delete the survival copy, and deletion should require multi-factor authentication.