VPS Disaster Recovery Planning: Backup Strategies, Restore Procedures, and Uptime Guarantees

Every VPS operator knows they should have backups. Few have ever tested a restore. The difference between a disaster and an inconvenience is not the backup — it is the recovery plan. A well-documented disaster recovery (DR) plan turns a panic-inducing server failure into a predictable, timed procedure. This guide covers the essential components of VPS disaster recovery: backup strategies, restore procedures, automation, and periodic testing.

If you are still choosing a VPS provider, compare VPS hosting plans to find one with automated snapshots, redundant storage, and reliable restore capabilities.

1. The Backup Strategy: 3-2-1 Rule for VPS

The 3-2-1 backup rule is the gold standard: three copies of your data, on two different media types, with one copy offsite. For a VPS, this translates to:

• Copy 1 (primary): Live data on your VPS
• Copy 2 (local): Daily VPS snapshots or local backup files on a separate volume
• Copy 3 (offsite): Encrypted backups sent to object storage (Backblaze B2, Wasabi, or S3)

Your backup tooling should support encryption (both in transit and at rest), incremental backups to minimize storage costs, and automated verification. Restic, BorgBackup, and Duplicati are popular open-source choices that meet all three criteria.

2. Choosing the Right Backup Tool

Tool	Encryption	Incremental	Deduplication	Best For
Restic	Yes (AES-256)	Yes	Yes	Object storage, multi-cloud
BorgBackup	Yes (AES-256)	Yes	Yes (strong)	Local/remote SSH targets
rsync + cron	Via SSH	Differential	No	Simple file-level backups
Duplicati	Yes (AES-256)	Yes	Yes	Web UI, cloud targets

3. Automating Backups with Restic and Backblaze B2

Restic combined with Backblaze B2 provides a cost-effective, encrypted, offsite backup solution. Typical costs are under $1/month for 10 GB of backups.

Step 1: Install Restic

sudo apt install -y restic

Step 2: Initialize a Repository

export B2_ACCOUNT_ID="your-b2-key-id"
export B2_ACCOUNT_KEY="your-b2-application-key"

restic init --repo b2:your-bucket-name:/vps-backups

Step 3: Create a Backup Script

#!/bin/bash
# /usr/local/bin/vps-backup.sh
set -e

export B2_ACCOUNT_ID="your-b2-key-id"
export B2_ACCOUNT_KEY="your-b2-application-key"
export RESTIC_PASSWORD="your-strong-encryption-password"

# Backup critical directories
restic backup     --repo b2:your-bucket-name:/vps-backups     /etc     /var/www     /home     --exclude="/home/*/.cache"     --exclude="/var/www/*/node_modules"     --tag nightly

# Check the backup integrity
restic check     --repo b2:your-bucket-name:/vps-backups     --read-data-subset=5% 2>&1 | tail -5

# Prune old snapshots (keep 7 daily, 4 weekly, 6 monthly)
restic forget     --repo b2:your-bucket-name:/vps-backups     --keep-daily 7     --keep-weekly 4     --keep-monthly 6     --prune

Step 4: Schedule with Cron

sudo chmod +x /usr/local/bin/vps-backup.sh
sudo crontab -e

# Add this line for daily backups at 2 AM
0 2 * * * /usr/local/bin/vps-backup.sh >> /var/log/vps-backup.log 2>&1

4. Database Backup Strategy

File-level backups are insufficient for databases. You must use database-specific dump tools to ensure consistent snapshots:

MySQL/MariaDB

# Dump all databases
mysqldump --all-databases --single-transaction --routines --triggers > /tmp/db-dump.sql

# Compress and encrypt (if not using restic)
gzip /tmp/db-dump.sql
# restic will handle the backup of this file

PostgreSQL

# Dump all databases
pg_dumpall > /tmp/pg-dump.sql

# Or for a single database
pg_dump -Fc mydb > /tmp/mydb.dump

5. The Restore Procedure

A backup that has never been restored is worthless. Document this procedure step by step and test it quarterly:

Full Server Restore (on a new VPS)

1. Provision a new VPS with the same OS version and region.
2. Install Restic and configure repository credentials.
3. Restore the latest snapshot: restic restore latest --target / --repo b2:your-bucket:/vps-backups
4. Reinstall the bootloader and regenerate initramfs if restoring system files.
5. Restore databases from the latest dump files.
6. Update DNS records to point to the new VPS IP.
7. Verify all services are running and accessible.

Single File/Directory Restore

# List available snapshots
restic snapshots --repo b2:your-bucket:/vps-backups

# Restore a specific file from a specific snapshot
restic restore b2:your-bucket:/vps-backups --target /tmp/restore     --path /etc/nginx/nginx.conf     --snapshot latest

# Or restore interactively with the mount command
restic mount /mnt/restic

6. Types of VPS Disasters and Their Recovery Plans

Disaster Scenario	RTO (Target)	Recovery Steps
Accidental file deletion	< 1 hour	Restore single file from latest snapshot
Application misconfiguration	< 2 hours	Roll back config files, restart service
Data corruption	< 4 hours	Restore database from latest dump, replay binlog
OS-level failure	< 6 hours	Provision new VPS, full restore from backup
Provider outage	< 12 hours	Provision new VPS at different provider, restore

7. Automating Disaster Recovery Tests

Manual testing is better than no testing, but automation is better still. Use a script that performs a restore to a temporary directory and verifies file integrity:

#!/bin/bash
# /usr/local/bin/test-restore.sh
set -e

export RESTIC_PASSWORD="your-encryption-password"
TEST_DIR="/tmp/restore-test"

# Clean up from last test
rm -rf "$TEST_DIR"

# Restore latest snapshot
restic restore latest     --target "$TEST_DIR"     --repo b2:your-bucket:/vps-backups     --path /etc/nginx

# Verify critical files exist
if [ -f "$TEST_DIR/etc/nginx/nginx.conf" ]; then
    echo "PASS: nginx.conf restored successfully"
else
    echo "FAIL: nginx.conf missing"
    exit 1
fi

# Clean up
rm -rf "$TEST_DIR"
echo "Restore test completed successfully"

8. Provider-Level Snapshots

Most VPS providers offer automated snapshots at the hypervisor level. These are not a replacement for offsite backups, but they provide the fastest recovery path for hardware failures. Configure your provider’s snapshot schedule to run daily at minimum, and ensure snapshots are retained for at least 7 days.

Provider snapshots restore in minutes, compared to hours for a full file-level restore. However, they are typically stored on the same infrastructure as your VPS — a provider-wide outage takes snapshots with it. This is why you still need offsite backups.

9. Documenting Your DR Plan

A DR plan is only useful if someone other than you can follow it. Write it down in a shared location (not on the VPS itself). Include:

• Provider dashboard login URLs and credentials
• Backup repository credentials and encryption passwords
• Step-by-step restore instructions for each scenario
• Contact information for the provider’s support team
• DNS provider login and instructions for updating A records
• Quarterly test schedule and sign-off checklist

Store the DR document in a password manager or encrypted cloud storage. Print a physical copy for your office — if the VPS is down and your password manager is also down, you need a fallback.

Putting It All Together

VPS disaster recovery is not a one-time setup — it is a practice. The three investments that pay off most are: (1) automated offsite backups with encryption, (2) a documented and tested restore procedure, and (3) provider-level snapshots for rapid recovery. Start with a basic Restic setup and a two-page DR document, then iterate as you discover what breaks in practice. For help choosing a VPS provider that supports automated snapshots and reliable infrastructure, visit our VPS hosting comparison page.