![Ransomware Protection Server: 5 Backup Strategies [2026]](/images/blog/ransomware-protection-server-5-backup-strategies-2026.jpg)
Ransomware groups now target backup infrastructure first. I've seen dozens of support tickets where attackers encrypted production databases and deleted every accessible backup before triggering the payload. A server backup isn't protection if the attacker can reach it from the compromised host.
The goal is building backup layers an attacker cannot touch from your primary server, even with root access. That means separating storage, revoking write permissions after the backup window closes, and proving you can actually restore before disaster strikes.
1. Offsite snapshots with network isolation
Your primary backup target should live outside the blast radius of the source server. Cloud object storage in a different region works. A second VPS in a different data center works. The critical requirement: the compromised server cannot delete or encrypt objects in the backup destination.
With AWS S3 or compatible providers, create a dedicated IAM user with PutObject permission but no DeleteObject or DeleteObjectVersion rights. The backup script can write new archives but cannot remove old ones. Store the credentials in a file readable only by root, then run backups through a cron job under a restricted service account.
# Backup script using s3cmd with write-only credentials
#!/bin/bash
set -euo pipefail
BACKUP_DATE=$(date +%Y%m%d-%H%M%S)
TMP_DIR="/var/backups/staging"
S3_BUCKET="s3://company-backups-offsite"
# Create archive
tar -czf "${TMP_DIR}/db-${BACKUP_DATE}.tar.gz" /var/lib/mysql
tar -czf "${TMP_DIR}/www-${BACKUP_DATE}.tar.gz" /var/www
# Push to S3 (credentials in /root/.s3cfg with PutObject only)
s3cmd put "${TMP_DIR}/db-${BACKUP_DATE}.tar.gz" "${S3_BUCKET}/"
s3cmd put "${TMP_DIR}/www-${BACKUP_DATE}.tar.gz" "${S3_BUCKET}/"
# Clean local staging
rm -f "${TMP_DIR}"/*.tar.gz
Schedule this script to run twice daily. If an attacker compromises the server, they can stop future backups but cannot destroy archives already in the bucket. Object versioning adds another layer—even if the attacker uploads a corrupted file over an existing backup name, the previous version remains retrievable.
Network isolation matters too. The backup destination should not be mounted as a filesystem or accessible via NFS/SMB from the production server. API-based object storage accessed over HTTPS through temporary credentials keeps the attack surface small.
2. Immutable retention policies
Write-only credentials help, but you also need retention locks. Immutable storage prevents anyone—including the bucket owner—from modifying or deleting an object for a defined period. S3 Object Lock, Wasabi immutability, and Backblaze B2 retention all implement this.
Set a retention period that covers your longest recovery window. Thirty days is a starting point. That way, if an attacker encrypts your data on day one and you don't notice until day seven, you still have three weeks of clean backups untouched.
Configure object lock at the bucket level, then apply a default retention mode to new uploads. Compliance mode is stronger than governance mode—compliance prevents deletion even by the root account until the retention period expires. Governance mode allows privileged users to override the lock, which is useful for testing but weaker against a compromised admin credential.
# Enable versioning and object lock on a new S3 bucket (AWS CLI)
aws s3api create-bucket --bucket company-immutable-backups --region us-east-2
aws s3api put-bucket-versioning --bucket company-immutable-backups \
--versioning-configuration Status=Enabled
aws s3api put-object-lock-configuration --bucket company-immutable-backups \
--object-lock-configuration 'ObjectLockEnabled=Enabled,Rule={DefaultRetention={Mode=COMPLIANCE,Days=30}}'
After the backup script uploads an archive, that file is locked for thirty days. An attacker who steals your AWS root credentials still cannot delete it. This buys time to detect the breach, contain it, and restore from a known-good snapshot.
Monitor your object storage logs. Unusual API calls—especially DeleteObject attempts that fail due to retention—signal that someone is trying to wipe your backups.
3. Air-gapped or append-only copies
Immutable cloud storage is strong, but adding a truly offline copy eliminates the remote-wipe risk entirely. An external drive that you physically disconnect after each backup run cannot be encrypted by ransomware.
Rotate two or three external drives on a weekly schedule. Monday's backup goes to drive A, which then gets unplugged and stored in a locked cabinet. Next Monday, plug in drive B, run the backup, unplug it. The offline drive is invisible to the network and to any attacker.
For larger environments, tape libraries with LTO drives provide append-only media. Once a tape is written and ejected, the data is immutable by design. Tape is slower and requires more hardware, but it's a proven archive medium that ransomware cannot touch remotely.
Another option: a secondary backup server that accepts writes via SSH but runs a script that immediately moves incoming files to an append-only directory using chattr +a on ext4 or XFS.
# On the backup destination server, mark the backup directory append-only
sudo chattr +a /backup/archives
Files can be added to /backup/archives, but existing files cannot be modified or deleted without first removing the append-only attribute—something an automated script or compromised SSH key cannot do. Only an administrator with physical or console access can run chattr -a to lift the restriction.
Schedule the primary server to rsync or scp archives to this append-only destination after each backup run. Even if the attacker pivots to the backup server, the immutable flag stops them from purging old backups.
4. Separate credentials and access controls
I've handled incidents where the attacker used the same root password across the web server, database server, and backup server. Once they owned one box, they owned the whole stack.
Backup infrastructure must have separate authentication. Use dedicated SSH keys, unique API tokens, and different passwords for each system. The backup destination should not trust the production server's credentials.
If you run a backup appliance or secondary VM, firewall it so that only the production server's IP can initiate connections, and only on the required port. Drop all inbound SSH from the internet. Require VPN or jump-host access for administration.
For database backups, create a read-only MySQL user with LOCK TABLES and SELECT privileges. The backup script does not need DELETE, DROP, or GRANT rights.
-- MySQL read-only backup user
CREATE USER 'backup'@'localhost' IDENTIFIED BY 'strong_random_password';
GRANT SELECT, LOCK TABLES, SHOW VIEW, EVENT, TRIGGER ON *.* TO 'backup'@'localhost';
FLUSH PRIVILEGES;
If ransomware encrypts the database server, the backup user can still dump a consistent snapshot, but an attacker who steals the backup user's credentials cannot drop tables or corrupt data at rest.
Rotate backup credentials every ninety days. Store them in a password manager or secrets vault, not in plaintext config files with world-readable permissions.
5. Automated restore testing
A backup you cannot restore is not a backup. I've seen organizations run nightly backups for years, then discover during an emergency that the archives are corrupted, the restore procedure is missing a step, or the backup script silently failed months ago.
Schedule a monthly restore drill. Spin up a disposable VM, pull the latest backup archive from offsite storage, and attempt a full restore. Verify that the database starts, the application serves traffic, and file permissions are correct. Time the process so you know how long a real recovery will take.
Automate this where possible. A simple script can provision a test instance, download the most recent backup, extract it, start services, and run a health check. If any step fails, send an alert.
#!/bin/bash
# Monthly restore validation script (outline)
set -euo pipefail
TEST_VM="backup-restore-test"
LATEST_BACKUP=$(s3cmd ls s3://company-backups-offsite/ | tail -1 | awk '{print $4}')
# Provision VM, download backup, extract, start services
# ...
# Health check
curl -f http://${TEST_VM}/health || { echo "Restore failed"; exit 1; }
echo "Restore validated successfully"
Document the restore steps in a runbook. Include commands, file paths, and expected output. When disaster strikes at 3 AM, you don't want to debug the procedure from memory.
Test your offsite and air-gapped backups too. Pull an archive from the external drive, pull another from the immutable S3 bucket, and confirm both restore cleanly. If the offsite copy is corrupted, you want to know before you need it.
What about incremental backups and deduplication?
Incremental backups save space and bandwidth. Tools like rsnapshot, Borg, and Restic store only changed blocks, then reconstruct full filesystems on demand. Deduplication shrinks storage costs further by identifying identical chunks across backups.
The risk: if the backup metadata or deduplication index is corrupted, you lose access to the entire chain. Ransomware that encrypts the backup repository can render every incremental snapshot useless, even if the underlying data blocks are intact.
If you use incremental backups, pair them with periodic full snapshots stored separately. Run a full backup every week and push it to immutable storage. Keep incrementals for fast daily recovery, but treat the weekly full backup as the guaranteed-good fallback.
Borg and Restic both support append-only mode, where the client can create new archives but cannot delete or prune old ones. Enable this on the backup server to protect the repository from a compromised source host.
# Borg repository in append-only mode
borg init --encryption=repokey --append-only /backup/borg-repo
Deduplicated backups also complicate restore testing. Confirm that the deduplication engine can rebuild a full filesystem from the repository, not just list archive names.
Monitoring and alerting
Backups fail silently more often than you'd expect. Disk full, network timeout, credential expiration, or a typo in the cron schedule all produce zero bytes and no alert.
Send a success ping after each backup run completes. Services like Healthchecks.io or a self-hosted cron monitor expect a POST request every X hours. If the request doesn't arrive, they alert you.
# Add to the end of your backup script
curl -m 10 --retry 3 https://hc-ping.com/your-unique-uuid
Log backup sizes and check for anomalies. If today's database dump is 10 MB and yesterday's was 500 MB, something broke. A sudden spike or drop in archive size often signals corruption or an incomplete backup.
Monitor the backup destination's disk usage. If it stops growing, backups aren't landing. If it grows faster than expected, check for runaway log files or an attacker uploading junk data to exhaust your storage quota.
Frequently Asked Questions
How many backup copies do I need?
Follow the 3-2-1 rule as a baseline: three copies of your data, on two different media types, with one copy offsite. For ransomware protection, add a fourth copy that's air-gapped or immutable.
Can I rely on filesystem snapshots like LVM or ZFS?
Local snapshots are fast and convenient for quick rollbacks, but they live on the same server. If ransomware encrypts the host or the attacker wipes the snapshot metadata, you lose everything. Use snapshots for short-term recovery and combine them with offsite backups.
What if my backup script itself gets compromised?
An attacker who modifies the backup script can exfiltrate data, skip the backup, or upload corrupted archives. Protect the script with file integrity monitoring (AIDE, Tripwire) and restrict write access to root only. Run the script from a read-only filesystem if possible.
How long should I keep old backups?
Retention depends on your RPO (recovery point objective) and compliance requirements. Thirty days covers most ransomware scenarios where the infection goes unnoticed for a week or two. Longer retention helps with accidental deletions and audits, but increases storage costs.
Don't wait for an incident to test your backups
Ransomware groups are patient. They'll sit in your environment for weeks, mapping shares, escalating privileges, and hunting for backup infrastructure. By the time they flip the encryption switch, they've already poisoned or deleted your recovery path.
Your backup strategy isn't done when the cron job runs. It's done when you've restored from offsite storage, confirmed the data is intact, and documented the process so anyone on your team can execute it under pressure. Run a drill this month if you haven't already.
Separate your backup storage from your production network. Lock down credentials and API tokens. Set retention policies that prevent deletion during the critical window. Test restores regularly, not just after disaster strikes. Those five layers—offsite snapshots, immutable storage, air-gapped copies, separate access controls, and automated restore validation—turn backups from a checkbox into actual ransomware protection.