Dedicated Server Backup Strategies: RAID, Snapshots & Offsite Copies

"We have RAID 1, so we're backed up" is one of the most common — and most dangerous — misunderstandings in server administration. RAID protects against a single drive failing. It does nothing against a bad rm -rf, a ransomware encryption run, a bug that silently corrupts data over weeks, or the RAID controller itself failing and taking both mirrored drives down with it. A real backup strategy for a dedicated server needs three distinct layers, each protecting against a different failure mode, and this guide breaks down all three with the specific tools and commands to implement them.

A Real Story: Why This Distinction Matters in Practice

A common pattern we see in post-incident reviews: a team runs RAID 1 across their production database disks, feels appropriately protected, and then a junior engineer runs a migration script against the wrong database during a late-night deploy. The DELETE statements execute successfully, replicate instantly and faithfully across both mirrored disks exactly as RAID is designed to do, and the "backup" disk now contains the same deleted data as the primary. RAID did its job perfectly — it just was never the job that was needed in that moment. This is the single most common conceptual gap in backup planning, and it is why this guide leads with it before touching a single command.

Why RAID Alone Is Not a Backup

RAID (Redundant Array of Independent Disks) protects against physical drive failure by writing data across multiple disks, so losing one disk does not lose your data. That is genuinely valuable — but every failure mode below still destroys a RAID array exactly as easily as a single disk:

• Accidental deletion or a bad deploy script — RAID faithfully replicates the deletion across every mirrored disk instantly
• Ransomware or malicious encryption — same problem, replicated instantly and consistently
• Filesystem corruption from a kernel panic or bad shutdown — corrupts the logical volume regardless of the underlying RAID level
• Controller failure or firmware bug — can take out an entire array, including RAID 10, in one event
• Data center fire, flood, or theft — destroys every disk in the chassis simultaneously

RAID is about availability (staying online through a drive failure). Backups are about recoverability (getting your data back after logical loss, malicious action, or total site loss). You need both, and conflating them is how "we thought we were covered" disasters happen. For a full breakdown of RAID levels and which fits which workload, see our RAID configuration guide.

How Long Should You Retain Backups?

Retention policy is also a cost lever — every additional retained snapshot or archive consumes storage indefinitely until pruned, so match retention to genuine recovery scenarios rather than retaining everything forever "just in case," which mostly just inflates your storage bill without meaningfully improving recoverability.

The 3-2-1 Backup Rule, Applied to a Real Server

Layer 1: RAID for Hardware Fault Tolerance

Choose RAID 1 or RAID 10 for anything with a database or frequent writes — RAID 5's write penalty and rebuild-time vulnerability make it a poor fit for busy production workloads, though it remains reasonable for largely read-heavy file storage. A degraded RAID array (one disk already failed) is not "still protected" — replace the failed disk and let the rebuild complete before treating the array as healthy again, since a second failure during a degraded rebuild window is a leading cause of "our RAID 1 lost everything" incidents. Our RAID configuration guide covers the full level-by-level tradeoffs, including real rebuild-time numbers, in depth.

Monitoring RAID Health Is Part of Layer 1, Not Optional

A RAID array that has silently been running in degraded mode for weeks provides zero actual redundancy while looking, from the application's perspective, completely normal. Configure your RAID controller's monitoring tool (megacli/storcli for LSI/Broadcom controllers, mdadm --monitor for Linux software RAID) to email or page on any degraded-state event, and confirm that alert path actually works by testing it — pulling a disk in a lab environment, not in production — rather than assuming it is configured correctly.

Layer 2: Snapshots for Fast Point-in-Time Recovery

Filesystem-Level Snapshots (ZFS / Btrfs / LVM)

ZFS and Btrfs support near-instant, copy-on-write snapshots that cost almost nothing at creation time and let you roll back an entire filesystem to a prior point in seconds. A typical ZFS snapshot schedule:

zfs snapshot pool/data@hourly-$(date +%Y%m%d%H%M)
zfs snapshot pool/data@daily-$(date +%Y%m%d)
# retain: 24 hourly, 14 daily, 6 monthly

LVM snapshots work similarly on ext4/XFS setups that use LVM, though they carry more performance overhead under heavy write load than ZFS/Btrfs's native copy-on-write design.

Application-Consistent Snapshots for Databases

A raw disk snapshot taken mid-transaction can capture a database in an inconsistent state. Use the database's own consistent-backup tooling — mysqldump --single-transaction for MySQL/MariaDB with InnoDB, or pg_basebackup for PostgreSQL — either instead of or in addition to filesystem snapshots, so a restore does not require manual crash-recovery on top of a raw disk image.

Why Snapshots Alone Still Are Not Enough

Snapshots typically live on the same physical array as the data they protect. A controller failure, chassis-level event, or an attacker with root access who deletes the snapshots along with the live data defeats this layer entirely — which is exactly why layer 3 exists.

Snapshot Retention: Balancing Granularity Against Storage Cost

Copy-on-write snapshots are cheap at creation but not free forever — each retained snapshot holds onto the blocks it references, so a long retention window on a busy, high-churn filesystem can consume more space than expected. A commonly workable retention policy is 24 hourly snapshots, 14 daily, and 6 monthly, pruning older snapshots automatically via a cron job or zfs-auto-snapshot/sanoid rather than letting them accumulate indefinitely and eventually fill the pool.

Application-Level Backup Tools Worth Knowing

For a busy MySQL database, mysqldump is fine at small-to-medium data sizes but becomes slow and disruptive (it typically takes a global read lock unless using --single-transaction with a fully InnoDB schema) as data grows into tens of gigabytes — at that point, Percona XtraBackup's hot, non-blocking physical backup approach is worth the switch.

Layer 3: Offsite Copies for True Disaster Recovery

Object Storage (S3-Compatible)

Ship nightly encrypted archives to an S3-compatible bucket (AWS S3, Backblaze B2, Wasabi) using rclone or restic, both of which support incremental, deduplicated, encrypted backups so you are not re-uploading a full multi-gigabyte archive every night:

restic -r s3:s3.us-east-1.amazonaws.com/my-backup-bucket backup /var/www /etc /home
restic -r s3:s3.us-east-1.amazonaws.com/my-backup-bucket forget --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune

Second Data Center Replication

For larger deployments, replicate to a server in a genuinely different data center (not just a different rack in the same facility) so a regional power or network event does not take out both copies. This is the model most serious disaster recovery plans converge on once data volume outgrows what object storage backup windows can comfortably handle nightly.

Encrypting Offsite Backups Correctly

Both restic and borg encrypt client-side by default before data ever leaves the server, meaning the storage provider (and anyone who might compromise that provider) only ever sees ciphertext. Store the encryption passphrase or key file somewhere separate from both the server and the backup destination — a password manager entry, or a securely stored offline copy — since a backup you cannot decrypt because you also lost the key is functionally identical to having no backup at all.

Bandwidth and Backup Window Planning

Estimate your nightly backup window realistically: a 500GB dataset over a 100Mbps uplink takes roughly 11 hours for a full transfer at theoretical maximum throughput, which is why incremental, deduplicated tools like restic and Borg matter so much in practice — after the first full backup, nightly deltas are typically a small fraction of total data volume and complete in minutes rather than hours.

Backup Approach Comparison

Building a Backup Schedule That Actually Gets Tested

1. Hourly filesystem/LVM snapshots retained for 24-48 hours (fast rollback for "I just broke something")
2. Nightly application-consistent database dump plus full file archive shipped offsite
3. Weekly full-server image backup retained for at least a month
4. Quarterly full restore drill onto a spare or test server — a backup you have never restored is a hypothesis, not a backup

Recovery Point Objective and Recovery Time Objective, Explained Plainly

Two numbers should drive every decision in this guide, and most teams have never actually written either one down:

• RPO (Recovery Point Objective) — how much data can you afford to lose, measured in time. An RPO of 1 hour means you can tolerate losing up to an hour of the most recent writes; it directly dictates your backup frequency.
• RTO (Recovery Time Objective) — how long can you tolerate being down while you restore. An RTO of 4 hours means your restore process, tooling, and offsite bandwidth all need to support a full recovery within that window, not "eventually."

Work backward from both numbers to your actual backup design rather than picking a schedule that feels reasonable. A business that genuinely cannot tolerate more than 15 minutes of data loss needs continuous database replication, not nightly dumps — while a low-traffic internal tool with a 24-hour RPO tolerance is genuinely well served by the nightly schedule above without over-engineering a replication setup it does not need.

Ransomware-Specific Backup Considerations

Modern ransomware increasingly targets backup infrastructure deliberately, specifically searching for and encrypting or deleting connected backup repositories before triggering the visible encryption of production data, precisely because a working backup is what makes a ransom demand ignorable. Mitigate this with immutable or write-once backup storage (S3 Object Lock in compliance mode, or a backup target the production server has only append/write access to, never delete access), and keep at least one backup copy on a system or credential set that a compromised production server's credentials cannot reach or authenticate against at all.

Common Backup Mistakes

• Assuming RAID 1/5/10 covers you and skipping true backups entirely
• Backing up to a second disk in the same physical server (still lost in a chassis-level event)
• Never testing a restore, discovering a corrupted or incomplete backup only during an actual emergency
• No encryption on offsite backups, turning a backup leak into a data breach
• Storing backup credentials on the same server being backed up, so a compromise takes out both production and the backup access path simultaneously
• Backing up application files but forgetting configuration, cron jobs, SSL certificates, and firewall rules — restoring "the data" without "the environment" still leaves significant rebuild work

What to Include Beyond the Obvious Application Data

It is easy to back up the database and the web root and assume the job is done, but a genuinely complete restore also depends on capturing: cron tab entries and systemd timers, firewall rules (iptables-save output, or your CSF config directory), SSL/TLS certificates and their private keys, any custom nginx/Apache virtual host configs, and a record of installed system packages so a rebuilt server's environment actually matches the one that failed. A backup script that only tars /var/www and dumps the database looks complete right up until a real disaster recovery reveals everything it silently left out.

Buyer's Checklist

• Does your hosting provider offer automated snapshot or backup add-ons, or is this entirely self-managed?
• Is offsite storage priced per GB, flat-rate, or bundled — and does it fit your actual data volume?
• Can you restore a single file quickly, or only a full-server image (matters a lot for "oops I deleted one file" scenarios)?
• What is the actual recovery time objective (RTO) you need, and does your chosen approach meet it?
• Have you scheduled — and calendared, not just planned — a quarterly restore test?
• Is at least one backup copy immutable or otherwise unreachable from production credentials, protecting against ransomware targeting the backups themselves?
• Do you know your actual RPO and RTO numbers in writing, rather than an informal sense of "we back up regularly"?

Full-Server Image Backups vs File-Level Backups

Most solid backup strategies use all three layered together rather than picking one — a full-image backup weekly as the disaster-recovery baseline, file-level incremental backups nightly for granular recovery, and database-specific dumps on their own schedule matched to how write-heavy the database actually is.

Frequently Asked Questions

Is RAID 10 a good enough backup on its own?

No — RAID 10 protects against drive failure only. Deletion, corruption, ransomware, and controller failure all bypass RAID protection entirely, which is why a separate backup layer is required regardless of RAID level.

How often should I take backups?

Match your backup frequency to your tolerance for data loss (your recovery point objective): hourly snapshots for active development data, nightly for most production databases, and at minimum weekly full-server images.

Should backups be encrypted?

Yes, always, especially offsite copies — an unencrypted offsite backup is effectively a second, less-monitored copy of your entire dataset sitting in someone else's infrastructure.

What is the difference between a snapshot and a backup?

A snapshot is typically fast, local, and lives on the same storage system as your live data; a backup is a separate, ideally offsite copy that survives the loss of the original storage entirely.

How do I actually test a restore without risking production?

Restore onto a separate test server or a temporary VPS, verify application functionality and data integrity there, then tear it down — never test a restore procedure for the first time directly against production.

Does WebsNP offer backup add-ons for dedicated servers?

Yes — ask about snapshot and offsite backup options when ordering, so backup infrastructure is in place from day one rather than bolted on after a scare.

What is a reasonable recovery time objective (RTO) for a small business server?

A few hours is realistic and achievable for most small-to-medium deployments using object storage restores; sub-minute RTOs generally require active database replication and standby infrastructure, which is a meaningfully bigger investment reserved for workloads where minutes of downtime carry serious cost.

How much should I budget for offsite backup storage?

Object storage pricing is typically a few cents per GB per month (S3-compatible providers commonly land in the $5-20/TB/month range), so a modest business dataset of 100-500GB usually costs single-digit-to-low-double-digit dollars monthly for offsite retention — inexpensive relative to the cost of an unrecoverable data loss event.

Should backups be stored on the same cloud provider as my server?

No, ideally not exclusively — using a different provider or at minimum a different account/region for backup storage means a single compromised credential, billing dispute, or provider-side outage cannot simultaneously take out both your production server and your only backup copy.

What is the difference between a full backup and an incremental backup?

A full backup captures the entire dataset every time, which is simple to restore from but slow and storage-heavy to create repeatedly; an incremental backup only captures changes since the last backup, which is fast and space-efficient but requires the full chain of increments to restore correctly, making tools like restic and Borg (which handle this chain management transparently) strongly preferable to hand-rolled incremental scripts.

A solid backup strategy is only half the equation — the hardware underneath it matters too. Explore our dedicated server plans with RAID and backup add-ons, or contact us to design a 3-2-1 strategy for your specific data volume.