Backups for VPS Customers — Snapshots, rsync, restic, Off-Site

Unlike shared hosting where JetBackup handles everything automatically, a self-managed VPS requires you to design your own backup strategy. Get this right and you can recover from disk failures, mistakes, ransomware, or a botched config change. Get it wrong and “I’ll set up backups tomorrow” becomes a recurring source of disaster. This guide covers practical VPS backup options, from simplest to most robust.

The three-layer backup model

A solid VPS backup strategy combines three layers:

• Layer 1 — Provider snapshots: full-disk snapshots taken by your VPS host. Fast to take, fast to restore, but tied to the same infrastructure.
• Layer 2 — File-level backups to a separate location: incremental backups of important data pushed to a different server or service. Survives provider-level disasters.
• Layer 3 — Off-site / cold storage: monthly or quarterly archive in completely separate infrastructure (different provider, different geography). The ultimate “last resort” copy.

Most sites need at least Layer 1 + Layer 2. Layer 3 is for genuinely important data (business-critical sites, customer data, anything you couldn’t easily recreate).

Layer 1: Provider snapshots

iWebVault VPS plans typically include snapshot capability. Available via:

• Client area → Services → your VPS → Snapshots / Backups section.
• VPS control panel (SolusVM, Virtualizor, or other depending on plan).

Snapshots capture the entire disk state. Restore brings the entire VPS back to that point. Strengths:

• Fast — typically seconds to minutes for snapshot creation.
• Complete — captures everything (OS, config, data, secrets).
• Restore is straightforward — one click usually.

Limitations:

• Stored on or near the same infrastructure as your VPS — provider-wide problems can affect both.
• Coarse-grained — restoring loses everything since the snapshot.
• Limited retention typically; old snapshots get cleaned up.

Best used for: before risky operations (kernel upgrade, major config change). Take a snapshot, do the change, restore if it fails. Cheap insurance.

Layer 2: File-level backups

File-level backups capture specific data (databases, application files, configs) and push them somewhere else for safekeeping. Tools:

rsync — simple, ubiquitous

Copies files to a remote server, only transferring what’s changed:

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

Put in cron, runs daily. Add MySQL dump first:

# /usr/local/bin/daily-backup.sh
#!/bin/bash
mysqldump --all-databases | gzip > /var/backups/mysql-$(date +%F).sql.gz
rsync -avz --delete /var/www/ backup-user@backup-server:/backups/vps01/var-www/
rsync -avz /var/backups/mysql-*.sql.gz backup-user@backup-server:/backups/vps01/mysql/
find /var/backups -name 'mysql-*.sql.gz' -mtime +7 -delete

Cron: 0 3 * * * /usr/local/bin/daily-backup.sh.

Strengths: standard, well-understood, works with SSH. Limitations: no encryption by default (use SSH for transport, but files at rest on the backup server are plain), no built-in retention/rotation.

restic — modern, encrypted, deduplicated

Better-engineered alternative. Backups are encrypted, deduplicated, and stored in a repository that can live on local disk, S3, Backblaze B2, SFTP, or others.

# Initial setup
apt install restic
export RESTIC_PASSWORD='your-very-strong-password'
restic init -r s3:s3.amazonaws.com/your-bucket-name

# Daily backup
restic backup /var/www /etc /var/backups -r s3:s3.amazonaws.com/your-bucket-name

# Retention: keep daily for 7 days, weekly for 4 weeks, monthly for 12 months
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune -r s3:s3.amazonaws.com/your-bucket-name

Strengths: encryption at rest, deduplication (small storage cost even over many backups), retention policies built in, restores granular (single file or whole tree). The clear winner for modern VPS backup unless you have a specific reason otherwise.

borgbackup — restic’s main alternative

Similar feature set, different architecture. Particularly popular for self-hosted setups. Both restic and borg are excellent — choose either.

Application-aware backups

For WordPress, plugins like UpdraftPlus or BlogVault back up at the application level and push to your choice of remote storage. Works alongside system-level backups; gives finer recovery (a single post, a single setting).

Where to store remote backups

• Object storage: AWS S3, Backblaze B2, Wasabi, Cloudflare R2 — durable, cheap, designed for backups. Backblaze B2 is often the best price for the durability.
• SFTP server: a separate cheap VPS (different provider, ideally different geography) acting as backup target.
• Cloud storage: Hetzner Storage Box, Contabo Object Storage — affordable backup-focused services.
• Personal NAS: works if your NAS has a public-facing endpoint (Tailscale, WireGuard, or similar VPN for security).

The principle: backups must be somewhere your VPS provider can’t accidentally destroy. If your VPS and backups are both at the same provider, a single billing issue or account compromise could wipe both.

Layer 3: Off-site / cold storage

Monthly or quarterly: pull a full archive to completely independent storage.

• Different geography (US backup if VPS in EU, vice versa).
• Different provider entirely.
• Maintained outside automation (manual decision to refresh) — protects against an automation script accidentally deleting backups.

For most VPS customers, monthly download of a current restic snapshot to your local computer’s encrypted drive is enough. For business-critical sites, dedicated cold storage at a third party (offline external HDDs, glacier-class object storage).

Verifying backups work

Untested backups are unreliable backups. Quarterly:

• Restore a recent backup to a test VPS (spin up cheap VPS, restore, verify content).
• Try a specific-file restore from production — pick a known file, restore from backup, confirm it matches.
• Verify your restoration documentation is current — passwords needed, repository paths, encryption keys all accessible.

The most common backup failure mode: backups have been running for months but restore was never tested, and when needed it turns out to be broken in some subtle way.

What to back up

Not everything — that’s wasteful. The right list:

• /var/www or wherever your sites live.
• Database dumps (mysqldump output, NOT the raw MySQL data directory).
• /etc — your configuration. Small, frequently changing, critical.
• /home — user data if you have non-root users.
• Application data directories (Redis dumps, custom application state).
• Mail directories if you self-host mail.

Don’t back up:

• /proc, /sys, /tmp, /dev — virtual or temporary filesystems.
• /var/cache — regeneratable cache data.
• Raw MySQL /var/lib/mysql — use mysqldump instead for consistency; raw files mid-transaction are unreliable.
• OS files — reinstalling the OS is faster than restoring from backup, and your configs in /etc are what really matter.

Common VPS backup mistakes

Backups stored on the VPS itself. If the VPS fails, both are gone. Always push backups to another location.

Backup running mid-traffic. Heavy I/O slows your site. Schedule for low-traffic hours (3-5 AM local time).

No retention policy. Daily backups indefinitely = unmanageable storage. Use restic/borg’s forget commands or scripted cleanup.

Forgetting database dumps. Filesystem backup of MySQL data files is unreliable. Always mysqldump first.

Encryption keys with the backups. Defeats the purpose. Keep the key elsewhere (your password manager, offline copy).

Never testing. Backups not tested for 12+ months almost always have surprises when you need them.

What’s next

• Hardening before deploying apps: VPS day-1 hardening.
• If something does go wrong: Recovery workflow.
• Reverse DNS for mail-sending VPS: Reverse DNS guide.

The first time you actually need a backup, you’ll be relieved you set it up. Spend an hour now to save a week of pain later. restic + a Backblaze B2 bucket + a daily cron is the modern minimum — set it up once, runs automatically thereafter.