Backup Strategies That Actually Work: The 3-2-1 Rule and Beyond

In 2022, we got a call from a small accounting firm in Bijeljina. Ransomware had encrypted every file on their server - client records, tax documents, financial reports spanning eight years of operation. "No problem," we said, "let us restore from your backup." There was a long pause on the line. They had a backup solution in place. It had been running nightly for three years. Nobody had ever checked whether it was actually working. It was not. The backup agent had failed silently 14 months earlier, and the last viable backup was from October 2020.

That firm lost two years of client data. Some of it was reconstructable from email attachments and paper records. Most of it was gone permanently. The financial cost exceeded 35,000 KM in recovery efforts and lost billable hours. Two clients left because their records could not be produced for a tax audit.

We tell this story not to blame anyone - the firm's IT setup was typical for a small business. We tell it because it illustrates the fundamental truth of backup strategy: an untested backup is not a backup. It is a hope.

The 3-2-1 Rule: The Foundation

The 3-2-1 backup rule has been the standard framework for data protection since photographer Peter Krogh coined it in the early 2000s. It is simple, effective, and still the minimum viable backup strategy for any business:

• 3 copies of your data (the original plus two backups)
• 2 different storage media types (e.g., local disk + cloud storage, or SSD + tape)
• 1 copy stored off-site (physically separate location)

The logic behind each number:

Three copies because the probability of two independent storage systems failing simultaneously is extremely low. If your primary data and one backup both fail, the third copy saves you. A single backup is a single point of failure - you have not actually removed risk, just moved it.

Two media types because different storage technologies have different failure modes. A RAID array and a single hard drive in the same server can both be destroyed by a power surge, a ransomware attack, or a motherboard failure. But a local RAID array and a cloud storage bucket share almost no failure modes.

One off-site copy because local disasters - fire, flood, theft, electrical damage - can destroy everything in a single physical location simultaneously. We have seen it happen. A lightning strike in Doboj in 2023 took out a client's server and the external hard drive sitting on the desk next to it. The only reason they recovered was a cloud backup that synced six hours earlier.

Beyond 3-2-1: The Modern 3-2-1-1-0 Approach

The 3-2-1 rule was designed before ransomware became the dominant threat to business data. Modern backup strategy has evolved to address this:

3-2-1-1-0:

• 3 copies
• 2 media types
• 1 off-site
• 1 immutable or air-gapped copy
• 0 errors (verified through restore testing)

The additional "1" is critical. Immutable backups cannot be modified or deleted for a defined retention period - not by administrators, not by ransomware, not by a disgruntled employee. Air-gapped backups are physically disconnected from any network, making them unreachable by any software-based attack.

The "0" is what the accounting firm in Bijeljina was missing. Zero unverified backups. Every backup should be tested regularly to confirm it can actually be restored.

Practical Backup Architecture

Here is the backup stack we deploy for managed VPS and dedicated server clients. It is not the only valid approach, but it covers the bases and has been battle-tested across hundreds of servers over the past decade.

Layer 1: Automated Server Snapshots

We run filesystem-level snapshots every 6 hours using LVM snapshots or ZFS snapshots, depending on the server configuration. These snapshots are point-in-time copies of the entire filesystem - not just files, but permissions, configurations, symlinks, everything.

Snapshots are fast to create (typically under 30 seconds for a 100GB volume) and fast to restore. They are your first line of defense against accidental deletions, misconfigured updates, and application-level errors.

Retention: We keep snapshots for 72 hours on a rolling basis. Four snapshots per day times three days gives you 12 recovery points. If a client discovers an issue within three days, we can roll back to any of those points.

Limitation: Snapshots live on the same physical storage as the original data. They protect against software problems but not hardware failure. This is why they are layer 1, not the entire strategy.

Layer 2: Daily Incremental Backups with Restic

For the primary backup layer, we use Restic - an open-source backup program that supports encryption, deduplication, and multiple storage backends. Alternatives like BorgBackup are equally capable; we chose Restic for its native support of cloud storage backends.

The daily backup workflow:

# Daily backup to local backup server
restic -r /backup/repository backup /var/www /etc /home \
    --exclude-caches \
    --exclude='*.log' \
    --exclude='node_modules' \
    --tag daily

# Prune old snapshots (keep 30 daily, 12 monthly, 5 yearly)
restic -r /backup/repository forget \
    --keep-daily 30 \
    --keep-monthly 12 \
    --keep-yearly 5 \
    --prune

Key decisions in this configuration:

Incremental backups only transfer data that has changed since the last backup. A full 50GB website backup might complete in under 2 minutes on subsequent runs because only the changed blocks are transferred. This makes frequent backups practical without consuming excessive bandwidth or storage.

Deduplication means identical data blocks are stored only once, even across multiple backup snapshots. A 50GB site backed up daily for 30 days does not consume 1.5TB of backup storage - it typically consumes 60-80GB because most data does not change between backups.

Encryption ensures that backup data is unreadable without the encryption key. This matters for off-site and cloud backups where you do not control the physical storage.

Layer 3: Off-Site Cloud Replication

Every night, after the local backup completes, we replicate to a geographically separate cloud storage bucket. We use Backblaze B2 for most clients due to its pricing ($6/TB/month, significantly cheaper than AWS S3), but the same approach works with any S3-compatible storage.

# Sync local backup repository to off-site cloud
restic -r b2:client-backups:/repository copy \
    --from-repo /backup/repository

The off-site copy protects against local disasters: datacenter fire, flooding, hardware theft, or a cascading storage failure that takes out both the primary server and the local backup server.

Layer 4: Immutable Retention

For clients with compliance requirements or heightened ransomware risk, we configure object lock on the cloud storage bucket. This makes backups immutable for a defined period - typically 30 days. Even if an attacker gains administrative access to the backup system, they cannot delete or modify backups within the immutability window.

Backblaze B2 and AWS S3 both support object lock natively. The cost increase is negligible - you are paying for the same storage, just with a deletion policy enforced at the infrastructure level.

The Part Everyone Skips: Restore Testing

We perform automated restore tests every week. The process:

1. Spin up an isolated virtual machine
2. Restore the most recent backup to that VM
3. Run automated checks: can the web server start, can the database accept queries, do config files contain expected values, do file checksums match
4. Record the results and tear down the VM
5. If any check fails, alert the team immediately

This sounds like overkill until you need a restore and it works flawlessly in under 20 minutes because you have done it 50 times before. The accounting firm in Bijeljina would still have their data if anyone had tested a restore even once in those 14 months.

Here is a minimal restore test script we use for WordPress sites:

#!/bin/bash
# Weekly restore verification

RESTORE_DIR="/tmp/restore-test"
TIMESTAMP=$(date +%Y%m%d)

# Restore latest snapshot
restic -r /backup/repository restore latest --target $RESTORE_DIR

# Check critical files exist
for file in wp-config.php wp-login.php index.php; do
    if [ ! -f "$RESTORE_DIR/var/www/html/$file" ]; then
        echo "FAIL: Missing $file" | mail -s "Backup Test Failed" alerts@example.com
        exit 1
    fi
done

# Test database dump integrity
mysql_dump="$RESTORE_DIR/var/backups/database.sql"
if [ -f "$mysql_dump" ]; then
    mysql --defaults-file=/etc/mysql/test-restore.cnf test_db < "$mysql_dump" 2>/dev/null
    if [ $? -ne 0 ]; then
        echo "FAIL: Database restore failed" | mail -s "Backup Test Failed" alerts@example.com
        exit 1
    fi
fi

echo "PASS: Restore test successful - $TIMESTAMP"
rm -rf $RESTORE_DIR

Adapt this to your environment. The specific checks matter less than the principle: your backups should prove themselves viable on a regular schedule.

Backup Scheduling Strategy

How often you back up depends on how much data you can afford to lose. This is formally called your Recovery Point Objective (RPO).

Ask yourself: if everything disappeared right now, what is the maximum amount of work or data you could accept losing?

Most small and medium businesses fall into the 6-24 hour range. If losing a full day of changes is unacceptable, increase your backup frequency. The incremental approach keeps the cost and performance impact minimal even at hourly intervals.

Also consider your Recovery Time Objective (RTO) - how quickly you need to be back online after a failure. This determines whether you need hot standby servers (RTO: minutes), pre-staged recovery environments (RTO: 1-2 hours), or can tolerate a manual restoration process (RTO: 4-8 hours).

The Tools We Trust

After testing dozens of backup solutions over the years, here is what we actually deploy:

Restic: Our primary backup tool. Encrypted, deduplicated, supports local disk, SFTP, S3, B2, and Azure out of the box. The restic check command verifies repository integrity without performing a full restore - useful for quick daily validation.

BorgBackup: Excellent alternative to Restic with slightly better deduplication ratios but fewer native cloud backends. We use Borg for clients with large datasets where storage efficiency is the primary concern.

rsync: Still the best tool for simple file-level synchronization. We use it for auxiliary tasks - syncing configuration files, replicating static assets between servers, maintaining warm standby copies.

mysqldump / pg_dump: For database backups specifically. We always back up databases as both a logical dump (SQL file) and as part of the filesystem snapshot. Having both gives you flexibility during recovery.

Proxmox Backup Server: For clients running virtualized infrastructure, PBS provides image-level backups with incremental, deduplicated storage and a clean web interface for management.

What We Have Learned the Hard Way

Twenty years of managing backups has taught us things no documentation covers:

Backup the backup configuration. We have seen situations where the server was restored successfully but the backup jobs were not reconfigured on the new system, leaving the client unprotected again. Document your backup configuration and store it separately.

Monitor backup completion, not just backup scheduling. A cron job running is not the same as a backup completing successfully. Check exit codes. Monitor for error outputs. Set up alerts for missed backup windows.

Keep at least one backup generation beyond your retention policy. If your retention is 30 days and a subtle data corruption occurred 31 days ago, you want that extra margin. We keep an additional quarterly archive beyond our standard retention.

Encrypt your backups, but protect your encryption keys more carefully than the backups themselves. Encrypted backups with lost keys are as useless as no backups at all. Store encryption keys in a password manager and print a physical copy for a secure location.

The accounting firm in Bijeljina eventually rebuilt their records. It took four months of painstaking work. They now have automated, tested, off-site backups with immutable retention. The total monthly cost of their backup infrastructure is 28 KM. The cost of the lesson that convinced them to invest: 35,000 KM and two lost clients.

Do not be the business that learns this lesson the hard way. Set up proper backups, test them regularly, and sleep well knowing that when - not if - something goes wrong, you can recover.