VPS Backup Strategy: Automated Backups Guide

rsync is the standard tool for VPS file backups due to its efficiency. It only transfers changed files and preserves permissions, timestamps, and symlinks. A basic offsite rsync command: `rsync -avz --delete /var/www/ user@backup-server:/backups/www/`. The `-a` flag preserves all metadata, `-z` compresses in transit, `--delete` removes files from the backup that were deleted from source. Be careful with `--delete` - a misconfigured source path can delete your entire backup. Automate backups with cron. Create `/etc/cron.d/backup` with entries for each backup job. Daily web content backup at 2AM: `0 2 * * * root rsync -az --delete /var/www/ user@backup-server:/backups/www/ >> /var/log/backup.log 2>&1`. Weekly full system backup (excluding `/proc`, `/sys`, `/dev`): `0 3 * * 0 root rsync -az --delete --exclude=/proc --exclude=/sys --exclude=/dev / user@backup-server:/backups/full/ >> /var/log/backup.log 2>&1`. Use SSH key authentication for the backup user so rsync can run non-interactively. Create a dedicated backup user on the destination server with `adduser backupuser` and restricted shell (consider `rssh` or `rrsync` wrapper). Store multiple backup generations to handle the case where corruption existed in source files for several days before you noticed. Implement a rotation scheme: keep 7 daily, 4 weekly, 3 monthly snapshots.

Database backups require different handling than file backups because databases are constantly writing. Never rsync a live database directory - you will get a corrupted backup. Use the database's own dump tools which ensure consistency. For PostgreSQL: `pg_dump -U postgres -d yourdatabase -F c -f /backups/db/yourdb-$(date +%Y%m%d).pgdump`. The `-F c` flag creates a compressed custom format that supports parallel restore and selective table restoration. For all databases: `pg_dumpall -U postgres > /backups/db/all-$(date +%Y%m%d).sql`. Schedule daily with cron and keep 30 days of database dumps. Database dump files compress extremely well (70-90% reduction) so storage cost is low. For MySQL/MariaDB: `mysqldump -u root -p'password' --all-databases --single-transaction --routines --triggers > /backups/db/mysql-$(date +%Y%m%d).sql`. The `--single-transaction` flag is critical for InnoDB tables - it creates a consistent snapshot without locking tables for the duration of the dump. Compress with gzip immediately: pipe the output through `gzip > /backups/db/mysql-$(date +%Y%m%d).sql.gz`. For large databases, consider `mydumper` for parallel multi-threaded dumps that complete much faster.

Local backups protect against accidental deletion but not against server failure, datacenter fire, or ransomware that encrypts your backups. Offsite storage is mandatory for production data. Options include: another VPS in a different datacenter (rsync via SSH), object storage like Backblaze B2 or Wasabi (use `rclone` to sync), or a home server with a dedicated backup account. B2 and Wasabi are particularly cost-effective at $0.006-$0.007/GB/month for backup-class storage. Configure `rclone` for object storage backups: `rclone config` to set up your provider, then `rclone sync /backups b2:your-bucket-name/hostname/ --transfers 4`. Add this to cron to run after your local rsync jobs complete. Encrypt sensitive backups before uploading with `rclone crypt` or `gpg`. Never store unencrypted database dumps containing personal data in cloud storage without encryption. The most important backup rule: test restores regularly. A backup that has never been restored is a theory, not a backup. Schedule monthly restore tests where you spin up a temporary VPS, restore a recent backup, and verify the application works correctly. Document the restore procedure in a runbook. When a real emergency happens is not the time to figure out restore syntax. Set up backup monitoring - have your backup cron job send a success notification and alert if it does not arrive within a time window.