How to Back Up Your VPS Correctly to Prevent Data Loss

Why You Must Manage VPS Backups Yourself

One key difference between a VPS and shared hosting is who is responsible for backups. On shared hosting, the provider typically runs automated backups for you. On a VPS, because you have Full Root Access and full control of the environment, backup responsibility falls entirely on you.

Hardware failures, security breaches, and human error all happen. A solid backup strategy is what lets you recover quickly no matter what goes wrong.

Method 1: Manual Backup with tar/gzip

The most basic approach is to compress your web files and database dumps manually.

Back Up Web Files

Back Up MySQL Databases

Create the /backup directory first and ensure you have sufficient disk space available.

Method 2: rsync to a Remote Server

rsync efficiently synchronises files to a remote destination, transferring only changed data to save time and bandwidth:

Use SSH key authentication so rsync can run unattended inside a cron job without requiring a password prompt.

Popular Backup Tools for Linux VPS

Beyond tar and rsync, several specialised tools make backup management more reliable and easier to maintain at scale.

Duplicati

Duplicati is an open-source backup tool with a web-based GUI. It supports over 30 destination types including SFTP, Amazon S3, Google Drive, and Backblaze B2. All data is encrypted before upload, so even if your storage account is compromised the backup files remain unreadable.

# Install Duplicati on Ubuntu/Debian
apt-get install mono-runtime libmono-2.0-dev
wget https://github.com/duplicati/duplicati/releases/download/v2.0.8.1/duplicati_2.0.8.1-1_all.deb
dpkg -i duplicati_2.0.8.1-1_all.deb
systemctl enable duplicati && systemctl start duplicati

BorgBackup (borg)

BorgBackup specialises in block-level deduplication — it stores only the chunks of data that have actually changed. This makes it extremely storage-efficient for large databases that change partially every day.

# Install and initialise a Borg repository
apt-get install borgbackup
borg init --encryption=repokey /backup/borg-repo

# Create a daily archive
borg create /backup/borg-repo::backup-{now:%Y-%m-%d} /var/www/html /etc

# List all archives
borg list /backup/borg-repo

Rclone — Sync to Cloud Storage

Rclone synchronises files from your VPS to more than 40 cloud storage providers including AWS S3, Google Cloud Storage, Wasabi, and Cloudflare R2. It is the recommended tool for satisfying the "offsite" requirement of the 3-2-1 backup rule.

# Install Rclone
curl https://rclone.org/install.sh | sudo bash

# Configure a remote (e.g. S3-compatible)
rclone config

# Sync backup directory to a bucket
rclone sync /backup s3:your-bucket-name/vps-backup/ --progress

Method 3: Snapshots (If Your Provider Supports It)

A snapshot captures the entire state of your VPS at a point in time, including the OS, applications, and all data. This allows you to restore everything in one operation.

• Ideal for full-system recovery after a major incident
• Consumes more storage than file-level backups
• Check with your VPS provider whether snapshots are available

Method 4: Automated Cron Jobs

Manual backups are easy to forget. Automate them with cron so they run on a schedule without any intervention:

Backing Up MySQL Databases Correctly

Your database is the hardest asset to recover. Unlike static HTML files that can be rebuilt from source, data such as orders, user accounts, and application state is irreplaceable once lost.

Full MySQL Dump

# Dump all databases in one operation
mysqldump -u root -p --all-databases --single-transaction \
  --routines --triggers --events \
  > /backup/full-db-$(date +%Y%m%d_%H%M).sql

# Compress immediately to save disk space
gzip /backup/full-db-$(date +%Y%m%d_%H%M).sql

Per-Database Backup

# Backup a single database
mysqldump -u root -p --single-transaction \
  my_wordpress_db | gzip > /backup/wp-db-$(date +%Y%m%d).sql.gz

# Restore it
gunzip < /backup/wp-db-20260608.sql.gz | mysql -u root -p my_wordpress_db

Create a Dedicated MySQL Backup User

Rather than using the root account in your backup scripts, create a dedicated MySQL user with only the permissions needed for backups. This limits exposure if the script or its credentials are ever compromised.

CREATE USER 'backup_user'@'localhost' IDENTIFIED BY 'StrongPassHere';
GRANT SELECT, LOCK TABLES, SHOW VIEW, EVENT, TRIGGER ON *.* TO 'backup_user'@'localhost';
FLUSH PRIVILEGES;

Automatically Delete Old Backups

Without cleanup, backup files will eventually fill your disk. Add a cron entry to delete files older than 30 days:

Backup Alerting and Monitoring

A backup that fails silently is as dangerous as no backup at all. Adding alerts ensures you know immediately when something goes wrong with your backup routine.

Email Notification from Your Backup Script

#!/bin/bash
# backup-with-alert.sh
BACKUP_FILE="/backup/web-$(date +%Y%m%d).tar.gz"
ADMIN_EMAIL="[email protected]"

tar -czf "$BACKUP_FILE" /var/www/html 2>&1

if [ $? -eq 0 ]; then
    SIZE=$(du -sh "$BACKUP_FILE" | cut -f1)
    echo "Backup succeeded: $BACKUP_FILE ($SIZE)" | \
      mail -s "[VPS] Backup OK $(date +%Y-%m-%d)" "$ADMIN_EMAIL"
else
    echo "Backup FAILED — please investigate immediately." | \
      mail -s "[VPS] BACKUP FAILED $(date +%Y-%m-%d)" "$ADMIN_EMAIL"
fi

Validate Backup File Size

A backup that is suspiciously small likely indicates an error. Add a size check to catch these cases early:

#!/bin/bash
BACKUP_FILE="/backup/web-$(date +%Y%m%d).tar.gz"
MIN_SIZE=1048576  # 1MB in bytes

if [ -f "$BACKUP_FILE" ]; then
    ACTUAL_SIZE=$(stat -c%s "$BACKUP_FILE")
    if [ "$ACTUAL_SIZE" -lt "$MIN_SIZE" ]; then
        echo "Warning: backup file is unusually small ($ACTUAL_SIZE bytes)" | \
          mail -s "[VPS] Backup size warning" [email protected]
    fi
fi

Test Your Restores Regularly

A backup you have never tested is a backup you cannot trust. Perform a test restore on a staging environment at least once a month to verify your backup files are intact and the restore procedure works correctly.