How to keep website backups safe from hackers?

To keep website backups safe from hackers, store them away from the website server, encrypt them, make at least one copy immutable so it can't be changed or deleted for a set period, and use separate credentials that only allow the server to add backups rather than remove them. Just as important, keep backups out of your public web directory, retain several restore points, and test restores regularly so you know they actually work.

Backups are usually treated as the thing that saves you after an attack. Attackers know that too, which is why ransomware operators and persistent intruders go looking for backups to delete, encrypt, or steal. A backup sitting next to your site, with the same password protecting both, is not much of a safety net. This article covers how attackers target backups and the practical steps, from simple plugin settings to server-level configuration, that keep yours out of their reach.

Why Hackers Target Backups

There are three main reasons an attacker cares about your backups:

• To remove your way out: If you can restore from a clean backup in an hour, a ransom demand has no leverage. Deleting or encrypting backups first makes paying look like the only option.
• To steal data: Backup archives often contain full database dumps with user accounts, email addresses, order history, and password hashes, plus configuration files with database passwords and API keys. A downloadable backup is a complete data breach in a single file.
• To survive your cleanup: If your backups include a backdoor planted weeks ago, restoring them simply puts the attacker back in.

Each of these needs a different defence, which is why a single measure isn't enough.

The Most Common Backup Mistakes

Before looking at solutions, it helps to know what goes wrong most often:

1. Backups stored on the same server: If the server is compromised or the disk fails, the backups go with it.

2. Backups in a public folder: Archives saved inside the web root, such as /public_html/backup.zip or a plugin's backup folder, can sometimes be downloaded by anyone who guesses or discovers the file name.

3. Shared credentials: The same account that runs the website can also delete everything in the backup storage.

4. Unencrypted archives: Backups stored in cloud storage or email without encryption expose every piece of data if the storage account is compromised.

5. Too few restore points: Keeping only the last one or two backups means an infection that went unnoticed for a week has already overwritten every clean copy.

6. Never testing restores: Corrupt archives, missing databases, and forgotten files are only discovered when you need them most.

Follow the 3-2-1 Backup Rule

The 3-2-1 rule is a simple starting point:

• 3 copies of your data: the live site plus two backups.
• 2 different types of storage: for example, your host's snapshots and a cloud object storage bucket.
• 1 copy off-site: stored with a different provider or in a different location from your server.

Many people extend this to 3-2-1-1-0: one copy that's offline or immutable, and zero errors when you test your restores. That extra "1" is what really protects you from hackers, because it's the copy an attacker can't touch even with full control of your server.

Store Backups Off the Server

The first and most important step is getting backups off the machine that runs your site. Good off-site destinations include:

• Object storage: Amazon S3, Backblaze B2, Wasabi, Cloudflare R2, or Google Cloud Storage.
• A dedicated backup service: Managed backup services for WordPress such as BlogVault or Jetpack VaultPress Backup store copies on their own infrastructure.
• A separate backup server: A small VPS with a different provider that pulls backups from your site.

If you use WordPress, plugins such as UpdraftPlus, BlogVault, Jetpack VaultPress Backup, and Duplicator Pro can all send backups to remote storage automatically. Check the plugin's settings to make sure remote storage is enabled and that local copies are deleted after upload, or at least limited to one.

Keep Local Copies Out of the Web Root

If backups have to be stored on the server even briefly, keep them outside the public directory. For example, if your site lives in /var/www/example.com/public, store backups in /var/backups/example.com, which isn't served by the web server.

When a plugin insists on storing files inside wp-content, block web access to that folder. UpdraftPlus, for example, uses wp-content/updraft and adds its own protection, but it's worth confirming. On Apache 2.4, place a .htaccess file inside the backup folder:

Require all denied

On Nginx, add a rule to your server block, then test and reload:

location ^~ /wp-content/updraft/ {
    deny all;
    return 403;
}

sudo nginx -t && sudo systemctl reload nginx

You can quickly check for stray archives in your web root with a command like this:

find /var/www/example.com -type f \( -name "*.sql" -o -name "*.sql.gz" -o -name "*.zip" -o -name "*.tar.gz" -o -name "*.bak" \) -size +1M

Review the results and move any old backup files out of the public directory. Be careful not to delete legitimate downloads you offer to visitors.

Encrypt Your Backups

Encryption means that even if someone gets hold of a backup file, it's useless without the key. There are two layers to think about:

• Encryption in transit: Make sure backups are uploaded over HTTPS or SSH. Every reputable backup plugin and cloud provider does this by default.
• Encryption at rest: The file itself should be encrypted before it leaves your server, so the storage provider or anyone who steals the storage credentials can't read it.

Many backup plugins, including UpdraftPlus's premium version, offer database encryption with a passphrase. Store that passphrase in a password manager, not on the server, and definitely not in the same place as the backups.

Use Public-Key Encryption for Server Backups

If you script your own backups, public-key encryption with GnuPG is a strong option. The server holds only the public key, which can encrypt but not decrypt. The private key stays on your own computer or in a secure vault. An attacker who takes over the server can't read existing backups, even ones still on the disk.

First, on your own secure machine, generate a key pair and export the public key:

gpg --full-generate-key
gpg --armor --export backups@example.com > backup-public.asc

Copy backup-public.asc to the server and import it:

gpg --import backup-public.asc

Then create a database dump and encrypt it in one pipeline. Store the MySQL credentials in a protected option file rather than on the command line:

# /root/.my.cnf  (chmod 600)
[client]
user=backup_user
password=use-a-long-random-password

#!/usr/bin/env bash
set -euo pipefail

STAMP="$(date +%F-%H%M)"
OUT="/var/backups/example.com/db-${STAMP}.sql.gz.gpg"

mysqldump --single-transaction --quick example_db \
  | gzip \
  | gpg --batch --yes --trust-model always --encrypt --recipient backups@example.com \
  > "$OUT"

chmod 600 "$OUT"

The --trust-model always option is used here only because the key was imported deliberately for this purpose. Test decryption on your own machine with gpg --decrypt before relying on it.

Give the database user only the privileges needed for dumps. For a typical InnoDB database that's roughly:

CREATE USER 'backup_user'@'localhost' IDENTIFIED BY 'use-a-long-random-password';
GRANT SELECT, SHOW VIEW, TRIGGER, LOCK TABLES, EVENT ON example_db.* TO 'backup_user'@'localhost';
FLUSH PRIVILEGES;

Depending on your MySQL version and options, mysqldump may also need the global PROCESS privilege, or you can add --no-tablespaces to avoid it.

Use Separate, Limited Credentials

This is the step most people miss. If your website server holds credentials that can delete backups, an attacker who compromises the server can delete them too.

The fix is to give the server write-only or append-only access:

• The server can upload new backups.
• The server can't delete or overwrite existing backups.
• A separate account, which never touches the server, manages retention and deletion.

Example: A Limited S3 Policy

With Amazon S3, you can create an IAM user just for backups and attach a policy that allows uploading and listing but not deleting. Combined with bucket versioning, even an overwrite keeps the older version:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListBackupBucket",
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": "arn:aws:s3:::example-site-backups"
    },
    {
      "Sid": "UploadBackups",
      "Effect": "Allow",
      "Action": ["s3:PutObject"],
      "Resource": "arn:aws:s3:::example-site-backups/*"
    }
  ]
}

Backblaze B2, Wasabi, and Cloudflare R2 support similar scoped keys or tokens. Look for options that restrict a key to one bucket and remove delete permissions.

Some backup tools need to read or prune old snapshots, which requires more permissions. In that case, run pruning from a separate, trusted machine using a different key, and keep the server's key limited.

Example: Pull Backups From a Separate Server

Another approach is to reverse the direction. Instead of the website server pushing backups out, a separate backup server connects and pulls them. The website server never has credentials for the backup storage at all.

On the website server, restrict the backup server's SSH key so it can only read the backup directory. The rrsync script ships with rsync; its path varies by distribution (on recent Debian and Ubuntu it's usually /usr/bin/rrsync). Add a line like this to the backup user's ~/.ssh/authorized_keys:

command="/usr/bin/rrsync -ro /var/backups/example.com",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... backup@backup-server

The -ro flag makes the directory read-only, and restrict disables port forwarding, agent forwarding, and interactive terminals for that key. From the backup server, pull the files:

rsync -a backup@example.com:/ /srv/backups/example.com/

When you change SSH settings, keep your current session open and test in a new terminal first, so a mistake doesn't lock you out.

Make at Least One Copy Immutable

Immutable backups can't be modified or deleted until a retention period expires, even by someone with full account access. This is the strongest protection against ransomware and malicious deletion.

Options include:

• S3 Object Lock: Available on Amazon S3 and several S3-compatible providers, including Backblaze B2 and Wasabi.
• Provider snapshot locks: Some hosts and cloud platforms offer locked or protected snapshots.
• Offline copies: A periodic backup copied to an external drive that's disconnected afterwards.

With the AWS CLI, you can create a bucket with Object Lock and set a default retention period:

aws s3api create-bucket \
  --bucket example-site-backups \
  --region eu-west-2 \
  --create-bucket-configuration LocationConstraint=eu-west-2 \
  --object-lock-enabled-for-bucket

aws s3api put-object-lock-configuration \
  --bucket example-site-backups \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"GOVERNANCE","Days":30}}}'

There are two modes to choose from:

• Governance mode: Most users can't delete locked objects, but accounts with a special permission can override the lock. It's a good place to start while you test.
• Compliance mode: Nobody can delete or shorten the retention of a locked object until it expires, not even the account's root user. It gives the strongest protection, but it also means you'll pay to store those objects for the full retention period, so choose the number of days carefully.

Keep Enough Restore Points

Attackers sometimes get in quietly and wait. If you keep only a few days of backups, every copy might already include their backdoor by the time you notice. A layered retention schedule helps:

• Daily backups kept for two to four weeks.
• Weekly backups kept for two to three months.
• Monthly backups kept for six to twelve months, or longer if you have regulatory requirements.

Adjust these to your storage budget and how often your site changes. Busy e-commerce sites may want more frequent database backups, such as every few hours, while a brochure site might be fine with daily.

Protect the Accounts That Control Backups

Your backup storage account, backup plugin account, and hosting account are all targets:

• Turn on two-factor authentication for every account that can manage or delete backups.
• Use unique passwords stored in a password manager.
• Use a different email address, or at least a different password, from your website admin login.
• Limit who has access, and review access regularly.
• Turn on alerts for deletions or unusual activity if your storage provider offers them.

Check Backups for Malware Before Restoring

A backup isn't automatically clean. Before restoring after a hack:

1. Choose a restore point from before the intrusion: Use logs, file modification dates, and security scanner reports to estimate when the compromise began.

2. Restore to a staging environment first: Never restore straight to production without checking.

3. Scan the restored copy: Use a malware scanner and look for unexpected PHP files in upload folders, unknown admin users, and modified core files.

4. Patch before going live: Update everything and fix the original vulnerability before the restored site faces the internet again.

Test Your Restores Regularly

Testing is the only way to know your backups work. At least every few months:

• Restore a full backup to a staging site or local environment.
• Confirm the database imports cleanly and the site loads.
• Check that uploads, themes, plugins, and configuration are all present.
• Time how long the restore takes, so you know what to expect in an emergency.
• Make sure you can decrypt the backups with the key stored in your password manager or vault.

Write the steps down. In a real incident you'll be stressed, and a checklist saves time and mistakes.

---

FAQ: Keeping Website Backups Safe

---

Conclusion

A backup only protects you if it survives the same attack that took down your site. Keeping backups safe from hackers comes down to a few principles: store them off the server and out of public folders, encrypt them, use limited credentials that can add backups but not delete them, and keep at least one immutable or offline copy with enough history to go back to a clean point.

None of these steps is difficult on its own, and together they turn your backups from a likely target into a reliable way out. Start with off-site storage and encryption, then add limited credentials and immutability, and schedule regular restore tests. When something does go wrong, you'll have a clean copy ready and no reason to negotiate with anyone.