⭐ Featured

VPS Backup and Disaster Recovery Guide 2026: Don't Trust Your Provider With Your Data

What happens when your VPS provider loses your data? A complete guide to building a bulletproof backup strategy with restic, Borg, B2, and more.

July 22, 2026 | 15 min read | 335 views

What Happens When Your VPS Provider Loses Your Data

In July 2026, raindog308 over at LowEndBox asked a question that every VPS user should think about but most never do: what happens when your provider's storage gets corrupted? The answer, predictably, depends on how much you're paying and who you're paying it to.

Here's the uncomfortable reality. If you're running a $2/month VPS from a LowEnd provider and the underlying storage array dies, your data is probably gone. Not temporarily unavailable. Gone. Most budget providers explicitly state in their Terms of Service that they don't offer backups. Some will provision you a fresh empty VM and wish you luck. A few might have in-house backups and get you back online in a week or so. And a tiny minority have snapshots that can restore you in minutes.

The cheapest plan you can find is a bet that nothing will go wrong. Backups are how you hedge that bet.

Then there's the AWS side of the coin. Also in July 2026, Amazon sent some customers bills ranging from $2.5 billion to $58 billion due to a bug in their billing estimation system. Nobody actually owed that money, but it's a stark reminder that even the biggest cloud providers have catastrophic failures. Your VPS provider is not immune.

Understanding How VPS Storage Actually Works

Before you can build a backup strategy, you need to understand what's between you and data loss.

The Storage Stack

Your VPS doesn't sit on a single hard drive. Here's what the typical stack looks like on a modern KVM provider:

Physical drives: Usually NVMe SSDs in a hardware RAID or JBOD configuration. Some budget providers still use SATA SSDs or even spinning disks for storage VPS plans.
RAID layer: Hardware RAID controllers or Linux mdadm software RAID. This protects against single drive failure but not against controller failure or logical corruption.
Hypervisor storage: LVM, ZFS, or a distributed system like Ceph. This is where thin provisioning, snapshots, and deduplication happen.
Your VM's filesystem: ext4, XFS, Btrfs, ZFS. The layer you actually control.

Any of these layers can fail. A drive dies. A RAID controller firmware bug corrupts the array. A sysadmin runs the wrong command. A datacenter tech pulls the wrong drive during maintenance. A hypervisor bug corrupts the virtual disk image. Malware encrypts everything.

What RAID Does and Does Not Do

RAID is not a backup. Say it again. RAID is not a backup. RAID protects against hardware failure by spreading data across multiple drives, so if one drive dies, the others keep running. But RAID does not protect against:

Logical corruption: If the filesystem gets corrupted, RAID faithfully replicates the corruption across all drives.
Accidental deletion: If you run rm -rf /, RAID ensures the deletion is perfectly mirrored.
Malware or ransomware: RAID doesn't help if an attacker encrypts your files.
Provider-level disaster: If the entire node catches fire, all RAID drives are destroyed together.

RAID buys you uptime. Only backups buy you recovery.

The Three Tiers of Provider Recovery Response

When storage fails at your provider, you'll typically see one of three responses. Knowing which tier your provider falls into helps you plan accordingly.

Tier 1: Snapshot Recovery (Minutes to Hours)

Premium providers like DigitalOcean, Vultr, and Hetzner maintain storage snapshots at the infrastructure level. When a drive fails, they restore your VM from a snapshot onto healthy storage and reboot it. You might lose a few minutes of writes, but your data is intact. This is the gold standard, and it's one reason these providers charge more than $2/month.

Tier 2: In-House Backup Recovery (Hours to Days)

Some mid-tier providers maintain their own backups separate from the primary storage. When disaster strikes, they provision a new VM and restore data from their backup system. This takes longer because they're potentially restoring terabytes for many affected customers simultaneously. raindog308 recounts a case from about a decade ago where a provider's faulty power supply zapped a batch of servers, and after about a week, his VM was restored from their backups. For a $5/month plan, that's acceptable.

Tier 3: Fresh VM, Your Problem (You Lose Everything)

Most LowEnd providers fall here. When storage fails, you get a brand new empty VM. Your old data is gone. The provider's Terms of Service almost certainly say something like "we are not responsible for data loss" and "you are responsible for maintaining your own backups." This sounds harsh, but when you're selling VMs at $2/month with razor-thin margins, maintaining a backup infrastructure for every customer isn't economically feasible.

If you're paying $2/month for a VPS, you are the backup system. Plan accordingly.

Building a Real Backup Strategy

A real backup strategy has three properties: it's automated, it's off-provider, and it's tested. Skip any one of these and you don't have a backup strategy. You have a backup fantasy.

Rule 1: Automate Everything

Manual backups don't work. You'll do it diligently for the first week. By week three, you'll skip it because you're busy. By month two, you'll forget the backup script exists. Then the drive fails and you realize your last backup is from six weeks ago.

Every backup tool worth using has a scheduling mechanism. Use it. Set up a cron job that runs your backup script every night, every hour, or whatever frequency matches your data change rate. Monitor the cron job. If it fails, make sure you find out.

Rule 2: Get Your Data Off the Provider

This is the single most important rule. A backup stored on the same provider is not a backup. If the provider's datacenter burns down, both your primary data and your backup are destroyed. The 3-2-1 rule from the backup world applies perfectly to VPS:

3 copies of your data (primary plus two backups)
2 different storage media (different providers, different physical locations)
1 copy stored off-site (completely different provider or physical location)

Practically: if your main VPS is at Provider A in New York, your backup should go to Provider B in Amsterdam, or to Backblaze B2, or to a NAS in your office. Completely unrelated to the primary provider.

Rule 3: Test Your Restores

An untested backup is a hypothesis, not a fact. You'd be amazed how many people discover, at the worst possible moment, that their backup script has been silently failing for months. Or that the backup files are there but corrupted. Or that the backup captures the wrong directory.

Once a month, do a test restore. Spin up a fresh VPS, restore your backup to it, verify the data is intact and the application starts correctly. This takes 20 minutes and it's the most boring, most valuable thing you can do.

Choosing Your Backup Tools

The Linux ecosystem has excellent backup tools. Here are the ones worth knowing about.

rsync: The Old Reliable

rsync has been around since 1996 and it's still the backbone of many backup systems. It does incremental file synchronization, meaning after the first full copy, it only transfers the changed portions of files. A basic rsync backup looks like this:

rsync -avz --delete /var/www/ user@backup-server:/backups/www/

Simple, fast, and reliable. The downside is that rsync doesn't do encryption, compression, deduplication, or versioning on its own. You'd typically wrap it in a script that handles rotation (keeping the last N copies).

restic: Modern, Fast, Encrypted

restic is a Go-based backup tool that handles encryption, deduplication, and versioning out of the box. It supports local storage, SFTP, and S3-compatible backends (including Backblaze B2, MinIO, Wasabi). Backups are encrypted client-side, so even if your backup provider is compromised, your data is safe.

A typical workflow: initialize a repository on B2, run restic backup /var/www on a cron schedule, and restic handles everything else. Snapshots are incremental, deduplicated, and you can restore any historical version. Retention policies let you keep 7 daily, 5 weekly, 12 monthly, and 10 yearly snapshots without manual cleanup.

Borg Backup: Deduplicated, Compressed, Verified

Borg (formerly BorgBackup) is similar to restic in philosophy but written in Python with C extensions for speed. It's particularly popular in the self-hosted community. Borg's deduplication is excellent, meaning that backing up 100GB of data that changes slightly each day can result in very small incremental backups.

Borg requires an SSH-accessible destination (typically a storage VPS or a dedicated backup server). It doesn't natively support S3, but tools like borgmatic can wrap Borg and add scheduling, monitoring, and reporting.

rclone: The Cloud Storage Swiss Army Knife

rclone isn't a backup tool per se. It's a command-line program that can sync files to and from 40+ cloud storage providers. Think of it as rsync for cloud storage. You can use rclone to sync your VPS data to Backblaze B2, Wasabi, Google Drive, Dropbox, or any S3-compatible provider.

rclone is particularly useful as a transport layer. You can combine it with other tools: take a database dump, compress it with gzip, encrypt it with rclone's crypt remote, and sync it to B2. All in a cron job.

Where to Store Your Backups: Cost Comparison

Storage costs vary wildly between providers. Here's a practical comparison for storing 100GB of backup data as of mid-2026:

Backblaze B2: $0.00695/GB/month ($6.95/TB, July 2026 rate) = $0.70/month for 100GB. Download is free through the Cloudflare Bandwidth Alliance. This is probably the best deal for VPS backups.
Wasabi: $0.00799/GB/month ($7.99/TB, July 2026 rate) = $0.80/month for 100GB. No egress fees, but minimum 90-day retention requirement means you pay for deleted objects.
Storage VPS: Many providers offer storage VPS plans at roughly $5/TB/month. For 100GB, that's $0.50/month. Gives you full control but requires maintenance.
Amazon S3 Standard: $0.023/GB/month = $2.30/month for 100GB. Plus egress fees at $0.09/GB. Expensive for backups, but S3 Glacier Deep Archive is $0.00099/GB/month if you rarely need to restore.
Hetzner Storage Box: Starts at €3.29/month for 100GB. Located in Germany or Finland. Includes SSH, SFTP, Samba, and Borg support built in. Excellent value if you already use Hetzner.

Backblaze B2 through Cloudflare's Bandwidth Alliance is the sweet spot for most VPS users. $0.70/month for 100GB with zero download fees ($6.95/TB, July 2026 rate).

The Hidden Cost: Restore Bandwidth

Storage price is only half the equation. When disaster strikes, you need to download your backup, and that's where some providers hit you. Amazon S3 charges $0.09/GB for egress. If you need to restore 500GB from S3, that's $45 in download fees alone.

Backblaze B2 normally charges $0.01/GB for downloads, but through the Cloudflare Bandwidth Alliance, if you access B2 through Cloudflare, egress is free. For a 500GB restore, that saves you $5. For larger restores, the savings scale linearly.

Database Backups: Special Handling Required

File-level backups work great for documents, images, and static files. But databases need special treatment. Copying a live database file while the database is running can give you a corrupted backup that looks fine until you try to restore it.

The Right Way: Logical Dumps

For MySQL/MariaDB, run mysqldump --single-transaction --routines --triggers dbname > backup.sql before your file backup runs. For PostgreSQL, use pg_dump or pg_dumpall. These produce a consistent text representation of the database that can be reliably restored.

Compress the dump, encrypt it if it contains sensitive data, and ship it to your off-site backup destination. This process is fast: a 10GB database typically dumps in 2-5 minutes and compresses to 1-3GB.

The Better Way: Physical Backups with Consistency

If your database is large (100GB+), logical dumps become slow and resource-intensive. In this case, use your database's built-in physical backup tools:

MySQL: Percona XtraBackup for hot physical backups without locking tables.
PostgreSQL: pgBackRest for fast, parallel, compressed physical backups with point-in-time recovery.
MongoDB: mongodump for smaller databases, or filesystem snapshots with the WiredTiger journal enabled for larger ones.

Schedule database dumps before file-level backups. The typical cron sequence is: dump database, compress, encrypt, then let restic/rsync pick up the dump file as part of the regular file backup.

Container and Application Backups

Docker Volumes

If you're running Docker containers, your data lives in Docker volumes. Backing up the container image is pointless. You need to back up the volumes. The standard approach is to run a temporary container that mounts the volume and copies its contents to a tar file:

docker run --rm -v myapp_data:/data -v /backups:/backup alpine tar czf /backup/myapp_data.tar.gz /data

Then sync that tar file to your off-site destination.

Configuration Files

Don't forget configuration. Your application code can be redeployed from Git, but your nginx configs, environment variables, cron jobs, systemd units, and custom kernel parameters are easy to forget. Keep a config directory under version control (Git) and back it up alongside everything else.

The Checklist Approach

For a typical VPS running a web application, your backup checklist should include:

Database dumps (MySQL, PostgreSQL, MongoDB, Redis, as applicable)
Application uploads and user-generated content
Configuration files (nginx, Apache, systemd, app configs)
SSL certificates and keys
Crontab entries and custom scripts
SSH keys and authorized_keys files
Firewall rules (iptables/nftables/UFW)
Docker compose files and volume data

If you can restore all of the above to a fresh VPS and have your application running within 30 minutes, you have a solid disaster recovery plan.

Speeding Up RAID Recovery If You Self-Host Storage

If you're running your own storage VPS with software RAID, a drive replacement means a RAID resync that can take days. In June 2026, raindog308 documented on LowEndBox how a 48TB RAID 5 array was estimated to take 4.5 days to resync after adding a drive. With a few kernel tweaks, that time dropped by about 15%.

RAID Resync Tuning

Three sysfs and proc settings make the biggest difference:

Increase speed limits: echo 600000 > /proc/sys/dev/raid/speed_limit_max and echo 100000 > /proc/sys/dev/raid/speed_limit_min. The defaults are conservative to avoid impacting normal I/O. During a resync-only period, crank these up.
Grow the stripe cache: echo 4096 > /sys/block/md2/md/stripe_cache_size. Default is often 512 or 1024. A larger cache lets the kernel process bigger chunks at a time. This is per-RAID-device, so check your md device name.
Stop other I/O: If the box is only doing a resync, shut down databases, web servers, and anything else competing for disk I/O. This alone can double resync throughput.

Don't leave these settings permanently. Revert after the resync completes.

Monitoring: Knowing When Backups Fail

A backup that fails silently is worse than no backup at all, because it gives you false confidence. Here's how to make sure you know when things go wrong.

Cron Job Health Checks

Every backup cron job should ping a health monitoring service when it completes successfully. If the monitor doesn't receive a ping within the expected window, it alerts you. Popular options include Healthchecks.io (free for up to 20 checks), Cronitor, and self-hosted alternatives like Uptime Kuma.

The pattern is simple. At the end of your backup script, add:

curl -fsS --retry 3 https://hc-ping.com/your-uuid-here > /dev/null

If the script crashes before reaching that line, no ping is sent, and the monitoring service notifies you after the grace period expires.

Log and Report

Your backup script should log what it did: how many files, how much data transferred, how long it took, and whether it succeeded. Email or message yourself a summary. If you use a tool like restic or Borg, their stats and check commands give you repository health information. Run restic check weekly to verify that your backup repository isn't corrupted.

Putting It All Together: A Sample Setup

Here's what a solid, affordable backup setup looks like for a typical small-to-medium VPS workload in 2026:

Primary VPS: Your application server ($5-20/month at any provider)
Backup destination: Backblaze B2 (about $0.70/month for 100GB at current rates)
Backup tool: restic with a cron job running nightly
Monitoring: Healthchecks.io free tier
Test restore: Monthly, on a cheap $2/month temporary VPS

Total backup cost: under $1/month for storage, plus a few minutes of your time each month for testing. That's less than the cost of a coffee, and it's the difference between an annoying inconvenience and a business-ending catastrophe when your provider's storage decides to corrupt itself on a random Tuesday.

You can either spend $1/month on backups or spend a sleepless week trying to rebuild everything from memory. Your choice.

Data loss isn't a question of if. It's a question of when. Storage fails. Providers make mistakes. Sysadmins fat-finger commands. Power supplies fry entire racks. The providers who do snapshots well charge more because maintaining that infrastructure costs real money. The providers who charge $2/month can't afford to be your backup system, and they'll tell you so in their Terms of Service if you bother to read them.

The good news is that building your own backup system is neither expensive nor complicated. A restic cron job to B2 costs about $1/month. The hard part isn't the technology. It's the discipline to set it up before you need it, automate it so you don't have to think about it, and test it so you trust it when the worst happens.