Your VPS provider's backup
is not a real backup.

Why provider backups are not enough

Most VPS providers offer snapshots or automated backups as a paid add-on. These are useful for quick rollbacks but have real limitations: they are stored in the same datacenter, often unencrypted, controlled by the same account that controls your VPS, and inaccessible if your account is suspended or the provider has an outage.

Independent offsite backup means your backup is physically elsewhere, encrypted with a key only you have, and accessible regardless of what happens to your VPS provider.

What to back up from a VPS

• /etc:All system configuration - nginx, SSH, cron, fail2ban, firewall rules, DNS.
• /var/www:Web application files, static sites, and uploaded content.
• Database dumps:Postgres, MySQL, SQLite - dump to a file before the restic run.
• /home:User scripts, dotfiles, SSH keys, and project directories.
• /opt:Self-hosted applications and their data directories.

Backup script for a typical VPS

#!/bin/bash
set -euo pipefail
source /etc/restic/env

# Database dumps
pg_dumpall -U postgres > /tmp/pg_backup_$(date +%Y%m%d).sql 2>/dev/null || true
mysqldump -u root --all-databases > /tmp/mysql_backup_$(date +%Y%m%d).sql 2>/dev/null || true

# Back up everything
restic backup \
  /etc /var/www /home /opt \
  /tmp/pg_backup_*.sql \
  /tmp/mysql_backup_*.sql \
  --tag "$(hostname)" \
  --exclude="/var/www/*/node_modules" \
  --exclude="*/cache" \
  --exclude="*/.git"

# Clean dumps
rm -f /tmp/pg_backup_*.sql /tmp/mysql_backup_*.sql

# Retention
restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 3 \
  --tag "$(hostname)" \
  --prune

Set up credentials

sudo mkdir -p /etc/restic
sudo tee /etc/restic/env <<EOF
RESTIC_REPOSITORY=sftp:vaultuser@vault.servercrate.net:22150:/data
RESTIC_PASSWORD=your-strong-repository-password
EOF
sudo chmod 600 /etc/restic/env

restic init

What to back up from a VPS

A VPS running a typical web application or self-hosted service has a predictable set of data worth protecting:

• /etc:System and application configuration. Nginx, Apache, PHP, SSH keys, cron jobs, sudoers, and all service configs. Painful to reconstruct manually.
• /var/www or /opt:Application code, static assets, and uploaded user files. Anything that isn't in version control.
• Database dumps:PostgreSQL, MySQL, or SQLite dumps created before the backup run. Never back up live database files directly.
• /home:User dotfiles, SSH keys, project files, and scripts.
• SSL certificates:/etc/letsencrypt if using Certbot. Losing these isn't catastrophic (they can be re-issued) but restoring saves time.

VPS provider snapshots are not offsite backup

Most VPS providers offer server snapshots. These are useful for quick rollbacks after a bad deploy, but they are not a substitute for offsite backup. Provider snapshots are stored in the same infrastructure as your VPS - a provider-level incident, account compromise, or provider bankruptcy can take out both your VPS and all its snapshots simultaneously. A truly independent encrypted offsite backup using restic to a separate provider like ServerCrate is the only protection against provider-level failures.

Multi-VPS backup to one vault

ServerCrate's Standard and Pro plans support multiple devices (3 and 5 respectively). If you run multiple VPS instances - a web server, a database server, a monitoring host - they can all back up to the same ServerCrate vault using different paths within the repository. Restic deduplicates across all of them, so shared software files and configs store only once. Manage all backups from one portal and pay one flat monthly fee.

Automating VPS backup with systemd

On modern Linux VPS instances, systemd timers are the correct way to schedule unattended backups. Create a service unit that runs your backup script and a timer unit with Persistent=true to catch missed runs if the VPS reboots. See the systemd timer guide for copy-paste unit files. For older VPS images still using cron, a nightly cron entry works fine - just add logging so you can see when something fails.