Backup Security:Protecting Backups From Ransomware and Deletion

Backups only protect you if an attacker who compromises your website or server cannot also delete, encrypt or steal them. Ransomware operators and other attackers increasingly look for backups first, because destroying them forces a payment. Secure backups are stored off the server, kept in several versions, protected by separate credentials (or made immutable), encrypted, and regularly tested by restoring them.

Why backups are targeted

• To prevent recovery: deleting or encrypting backups leaves the victim no option but to pay or rebuild.
• To steal data: backup archives contain entire databases and are often less protected than the live system.
• Because they are easy to find: backup files left in the website folder or on the same server are found by automated scanners.

Principles of secure backups

1. Keep copies off the server

A backup on the same server or the same hosting account is lost along with it. Keep at least one copy in a separate location, ideally with a different provider. The 3-2-1 rule (three copies, two kinds of storage, one off-site) is a good baseline; see server backup strategy.

2. Separate credentials

The server that creates backups should be able to write new backups but not delete or overwrite old ones. Use:

• a separate storage account with its own strong password and 2FA;
• access keys with write-only or limited permissions;
• pull-based backups, where a separate backup system connects to the server and pulls data, so the server holds no credentials to the backup store.

3. Versioning and immutability

• Versioned storage keeps previous copies when a file is overwritten.
• Immutable or "object lock" storage prevents deletion or modification for a set retention period, even by an administrator account. This is one of the strongest protections against ransomware.
• Offline copies (disconnected media) protect against online attacks entirely, at the cost of convenience.

4. Enough history

Attackers sometimes stay hidden for weeks before acting. Keep enough versions (for example daily for a month, monthly for several months) to restore to a point before the compromise began.

5. Encrypt backups

Encrypt archives before they leave the server, especially if they contain personal or financial data. Keep the encryption keys separately and securely; a backup you cannot decrypt is useless, so test decryption too.

6. Do not leave backups in the web root

Archives like backup.zip or site.sql inside public_html can be downloaded by anyone who guesses the name. Store them outside public directories and remove temporary copies.

7. Test restores

Regularly restore to a separate environment and confirm the application works and the data is complete. Time it, so you know your real recovery time.

8. Monitor

Alert when backups fail, when backup sizes change unexpectedly, or when someone deletes backup data.

Example: a pull-based backup design

A business runs its website on a VPS and keeps backups in a separate cloud storage account:

• A separate backup server (or backup service) connects to the website VPS each night over SSH with a dedicated, read-only backup user, and pulls the database dump and files.
• The backup server writes to object storage with versioning and a retention lock of 30 days.
• The website VPS holds no credentials for the backup storage, so an attacker who compromises the website cannot reach, delete or encrypt the backups.
• The backup storage account has its own owner login with 2FA, used by nobody day to day.
• A monthly restore test brings a backup up on a temporary server.

This design costs a little more than writing backups from the web server itself, but it closes the most common way ransomware destroys recovery options.

Signs your backups may be at risk

• The web server can delete files in the backup location.
• Backups and the live site share the same hosting account or login.
• Only one copy exists, or only a few days are kept.
• Nobody has restored a backup in months.
• Backup archives sit in a publicly reachable folder.

After an incident

1. Do not restore immediately on top of a compromised system.
2. Find and close the entry point first; see website malware: signs and what to do.
3. Choose a backup from before the compromise.
4. Restore to clean infrastructure, then change all credentials.

Quick checklist

• At least one off-site copy, with a different provider if possible
• Backup storage uses separate credentials with 2FA
• Server cannot delete its own backups (write-only, pull-based or immutable)
• Several weeks to months of versions
• Backups encrypted, keys stored separately
• No backup files in public folders
• Restore tested regularly
• Alerts on backup failures and deletions

Frequently Asked Questions

Are my host's backups enough?

They are a useful layer, but if your hosting account is compromised or suspended you may not reach them. Keep an independent copy you control.

Does RAID or replication protect against ransomware?

No. Encryption and deletions are replicated instantly. Only versioned, isolated backups protect you.

How often should backups be tested?

At least a few times a year, and after major changes to the site or backup system.

Related reading

Backups are step 5 of website security basics, and part of business continuity for websites. Automated backups are part of a ServerNeed managed VPS.

Sources

• CISA: Ransomware Guide