Backups stop ransomware from turning into a business-ending event. But backups that silently fail turn into expensive surprises when you need them. A monitoring plan catches those failures early.
You need seven components: automated backup execution, test restores, alert routing, versioned retention, off-site replication, access logging, and a quarterly drill. Each one plugs a gap attackers exploit.
What ransomware does to unmonitored backups
Ransomware operators study backup systems before they encrypt production data. They delete local snapshots, corrupt backup catalogs, and disable backup jobs days before launching the encryption payload. Without monitoring, you discover these problems after the attack.
I've seen support tickets where customers found their backup job had been failing for three months—discovered only after ransomware hit. The backup software logged errors to a file nobody checked. That's the gap we're closing.
Step 1: Schedule backups and verify they run
Start with a working backup job. Pick a tool that matches your environment: rsync and tar for Linux servers, Veeam or Acronis for Windows, or your hosting provider's snapshot API.
The backup must run automatically. Cron jobs work for Linux:
# Daily backup at 2 AM
0 2 * * * /usr/local/bin/backup-script.sh >> /var/log/backup.log 2>&1
That script should exit with status 0 on success and non-zero on failure—standard Unix convention. Your monitoring depends on accurate exit codes.
Verify the job runs by checking logs the morning after the first scheduled execution. Grep for error keywords:
grep -i "error\|fail\|warn" /var/log/backup.log
If you see output, investigate before moving forward. A backup job that runs but throws warnings will fail eventually.
Step 2: Test a restore within 24 hours
Backups you can't restore are just expensive log files. Test a restore immediately after the first successful backup completes.
Create a separate restore target—never overwrite production data during a test. For file backups, restore to /tmp or a test directory:
tar -xzf /backup/daily-backup.tar.gz -C /tmp/restore-test/
Compare a handful of restored files against the originals using diff or checksums:
sha256sum /var/www/html/index.php
sha256sum /tmp/restore-test/var/www/html/index.php
Matching checksums confirm the backup captured file contents correctly. For database backups, restore to a test database instance and run a SELECT query against a known table.
Document the restore procedure in a runbook. When ransomware hits, you won't have time to figure out syntax.
Step 3: Configure failure alerts
Backup jobs fail for dozens of reasons: full disks, network timeouts, credential expiration, file locks. You need alerts that wake you up when a backup doesn't complete.
For cron-based backups, wrap the job in a monitoring check. Healthchecks.io and similar services expect a ping URL hit after each successful run. If the ping doesn't arrive within the expected window, they send an alert.
Add the ping to your backup script:
#!/bin/bash
BACKUP_COMMAND="tar -czf /backup/daily.tar.gz /var/www"
HEALTHCHECK_URL="https://hc-ping.com/your-uuid"
if $BACKUP_COMMAND; then
curl -fsS --retry 3 $HEALTHCHECK_URL > /dev/null
else
curl -fsS --retry 3 "${HEALTHCHECK_URL}/fail" > /dev/null
exit 1
fi
Route alerts to a channel you actually check. Email gets lost in inbox clutter. SMS, Slack, or PagerDuty work better for critical alerts.
Test the alert by intentionally breaking the backup job—point it at a nonexistent directory or revoke credentials temporarily. You should receive an alert within your configured grace period.
Step 4: Keep multiple versions with different ages
Ransomware operators wait days or weeks after compromising backups before encrypting production systems. If you keep only one backup generation, that backup might already be infected or deleted when you need it.
Retain multiple backup versions across different time horizons:
- Daily backups: keep the last 7 days
- Weekly backups: keep the last 4 weeks
- Monthly backups: keep the last 3 months
This grandfather-father-son rotation gives you multiple recovery points. Implement it with timestamped backup files:
BACKUP_DATE=$(date +%Y%m%d)
tar -czf /backup/daily-${BACKUP_DATE}.tar.gz /var/www
# Keep only last 7 daily backups
find /backup -name "daily-*.tar.gz" -mtime +7 -delete
For weekly and monthly archives, use a separate script that copies a daily backup to the long-term storage location on the appropriate day.
Version retention protects against attacks that corrupt backups gradually. You can roll back to a known-good point before the compromise started.
Step 5: Replicate to an off-site location
Local backups get encrypted along with production data if ransomware gains root access. Off-site replication creates a recovery path even when the primary server is completely compromised.
The off-site target must be:
- Geographically separate (different data center or region)
- Write-only from the source server (attacker can't delete it)
- Not mounted as a standard filesystem (so ransomware can't traverse into it)
Object storage like S3 fits these requirements. Use a dedicated backup IAM user with PutObject permission but not DeleteObject:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:PutObject"],
"Resource": "arn:aws:s3:::your-backup-bucket/*"
}
]
}
Configure lifecycle rules in the bucket to move backups to cheaper storage tiers after 30 days and delete them after your retention period expires. This happens server-side, so compromised credentials can't accelerate deletion.
Sync backups after local verification passes:
if tar -tzf /backup/daily-${BACKUP_DATE}.tar.gz > /dev/null 2>&1; then
aws s3 cp /backup/daily-${BACKUP_DATE}.tar.gz \
s3://your-backup-bucket/daily/ \
--storage-class STANDARD_IA
fi
The integrity check (tar -tzf) ensures you don't replicate a corrupted archive off-site.
Step 6: Log and audit backup access
Ransomware operators delete backups through legitimate credentials they've stolen. Access logs help you detect reconnaissance activity before the encryption phase starts.
Enable CloudTrail for S3 backup buckets or equivalent audit logging for your off-site storage. Look for:
- DeleteObject API calls (should never happen with proper IAM policies)
- GetObject calls from unexpected IP addresses
- Multiple failed authentication attempts
- Access outside normal backup windows
For on-premises backup storage, use filesystem auditing. On Linux, auditd tracks file access:
auditctl -w /backup -p wa -k backup_access
That rule logs all writes and attribute changes in /backup. Review the audit log weekly:
ausearch -k backup_access -ts recent
Sudden spikes in backup access or access from unfamiliar user accounts deserve immediate investigation. In support tickets I handled, attackers often tested backup deletion on a Friday night before launching ransomware Monday morning.
Step 7: Run a full recovery drill quarterly
Monitoring and alerts give you confidence backups are running. Only a drill proves you can actually recover.
Schedule a quarterly drill that simulates a complete server loss. Spin up a fresh VM or test server and restore your backup from scratch—no access to the original system.
Time how long recovery takes. Document every step, including:
- How you accessed the off-site backup storage
- Which backup generation you selected
- Commands or tools used to restore
- Post-restore verification steps
- How long each phase took
If the drill uncovers problems—missing documentation, forgotten credentials, incompatible restore tools—fix them immediately. Update your runbook with the working procedure.
Drills also validate that your backup actually contains everything needed to rebuild the server. I've seen cases where the backup captured application code but not configuration files, or database dumps but not the users table. You discover these gaps during a drill, not during a real emergency.
How often should you review the monitoring plan?
Review alert configurations and retention policies every six months. Server environments change: new applications get deployed, data volumes grow, and compliance requirements shift.
Check that:
- Backup jobs still cover all critical data paths
- Retention periods align with recovery point objectives
- Alert routing still reaches on-call staff
- Off-site replication keeps pace with backup growth
- IAM policies and credentials haven't expired
If you've added new services or databases, extend backup coverage before they become a gap an attacker can exploit.
Check these components first
A ransomware prevention backup monitoring plan needs all seven steps working together. Backups without testing are untested hopes. Alerts without retention give you warnings but no recovery path. Off-site replication without access logging misses attacker reconnaissance.
Start with scheduled backups and a successful test restore. Add monitoring and alerts next. Build out versioned retention and off-site replication once the core loop works. Layer in access logging and quarterly drills last.
Walk through the entire recovery procedure at least once before you need it for real. Every minute spent on drills saves hours during an actual incident.