Effective VPS Backup Strategy: Never Lose Data Again

June 2026 · 7 min read

No one has ever regretted having too many backups, but many regret not starting backups sooner. This article covers a comprehensive backup strategy that protects your data across multiple layers.

Why Provider Snapshots Aren't Enough

Many VPS providers offer snapshot features, but they have important limitations you should know about:

Most snapshots are stored in the same datacenter as your server — if the datacenter goes down, both your VPS and snapshots disappear together
Some providers charge for snapshots based on storage space used
You often can't restore individual files — you must restore the entire disk or nothing

This is why you need a multi-layered backup strategy instead.

Layer 1: Database Backup with mysqldump

Databases change fastest and should be backed up most frequently.

#!/bin/bash
DATE=$(date +%Y%m%d_%H%M)
BACKUP_DIR="/backup/mysql"
mkdir -p $BACKUP_DIR
mysqldump -u root -p"yourpassword" --all-databases \
  | gzip > "$BACKUP_DIR/all-db-$DATE.sql.gz"
# Keep only the last 7 days
find $BACKUP_DIR -name "*.sql.gz" -mtime +7 -delete

Add this to your crontab to run every night:

0 2 * * * /usr/local/bin/backup-mysql.sh

Layer 2: Web Files with rsync

rsync -avz --delete /var/www/html/ \
  backup-server:/backup/webfiles/$(hostname)/

rsync only transfers files that have changed, saving both bandwidth and time compared to transferring everything every backup cycle.

Layer 3: Offsite Backup to Object Storage

Backup files stored on your main server are still at risk. You should send them offsite as well.

Use rclone to sync to S3-compatible storage like Backblaze B2, Cloudflare R2, or AWS S3:

# Install rclone
curl https://rclone.org/install.sh | bash
rclone config  # Configure remote storage

# Sync backup folder to cloud
rclone sync /backup/ remote:my-bucket/backup/

Test Your Restore Process

A backup you've never tested is a backup you can't trust. Test restore at least every 3 months:

Pick your most recent backup file
Restore it to a separate test environment (local Docker or test VPS)
Verify that databases come up correctly and all files are intact

The 3-2-1 Rule: Keep 3 copies of your data, in 2 different storage formats, with at least 1 copy offsite. This is a proven best practice used by professional backup teams worldwide.

Automated Daily Backup with Unified Script

This script combines database backup + file backup + cloud upload in a single operation:

#!/bin/bash
# /usr/local/bin/daily-backup.sh
set -euo pipefail

DATE=$(date +%Y%m%d_%H%M)
BACKUP_DIR="/backup/${DATE}"
mkdir -p "$BACKUP_DIR"

# 1. Database backup
mysqldump -u root -p"${MYSQL_PASS}" --all-databases \
  --single-transaction --quick \
  | gzip > "${BACKUP_DIR}/all-db.sql.gz"

# 2. Web files
rsync -az --delete /var/www/html/ "${BACKUP_DIR}/webroot/"

# 3. Config files
tar -czf "${BACKUP_DIR}/configs.tar.gz" \
  /etc/nginx/ /etc/php/ /etc/mysql/ /etc/letsencrypt/ 2>/dev/null || true

# 4. Upload to cloud
rclone sync "$BACKUP_DIR" "remote:backup/${DATE}/" --progress

# 5. Delete backups older than 14 days
find /backup -maxdepth 1 -type d -mtime +14 -exec rm -rf {} \;
rclone delete "remote:backup/" --min-age 30d --rmdirs

echo "Backup ${DATE} completed" | mail -s "Backup OK: $(hostname)" [email protected]

Add to crontab to run at 3 AM every night:

0 3 * * * MYSQL_PASS="yourpass" /usr/local/bin/daily-backup.sh >> /var/log/backup.log 2>&1

Verify Your Cloud Backups

# List all backups in remote storage
rclone ls remote:backup/ --max-depth 2

# Check total storage size
rclone size remote:backup/

# Test downloading your most recent backup
rclone copy "remote:backup/$(date +%Y%m%d)_0300/" /tmp/restore-test/ --progress

Check Server and Domain Health Before Backing Up

Before you finalize your backup plan, you should know if your website has any issues first — such as expiring SSL certificates, DNS errors, or missing security headers. A tool like dnsxray.com can check your domain health for free and catch small problems before they become big ones.

For Thailand-based VPS with uptime guarantees and quality support, compare packages at asiagb.com, which offers both Linux and Windows VPS options.

Common Issues & Troubleshooting

mysqldump fails: "mysqldump: Got error: 1045: Access denied"

# Check your MySQL user and password
mysql -u root -p -e "SELECT user, host FROM mysql.user;"

# Alternatively, use .my.cnf to store credentials
cat ~/.my.cnf
# [client]
# user=root
# password=yourpassword

rclone fails to upload because authentication expired

Some providers' tokens expire. Re-authenticate:

rclone config reconnect remote:
# Or delete config and set up again
rclone config

Web file backup is extremely slow because there are too many files

Use --exclude to skip unnecessary files:

rsync -az --delete \
  --exclude="*.log" \
  --exclude="cache/" \
  --exclude="tmp/" \
  /var/www/html/ "${BACKUP_DIR}/webroot/"

After restore, database won't start and character encoding is corrupted

Specify the character set during restore:

gunzip -c all-db.sql.gz | mysql --default-character-set=utf8mb4 -u root -p

Frequently Asked Questions

How often should I back up?

It depends on how frequently your data changes. For websites updated daily, once-per-day backups are usually sufficient. For e-commerce sites with constant transactions, you should back up your database hourly or set up binary log replication to a standby server for faster recovery.

What's the difference between provider backups and my own backups?

Provider snapshots are typically full disk images that restore quickly, but you either get everything or nothing — you can't restore individual files. They're usually stored in the same datacenter as your server. Custom backups let you restore specific files and can be stored offsite for better disaster protection. You should have both.

Should I use Backblaze B2 or Cloudflare R2?

Cloudflare R2 has no egress fees, making it better if you restore frequently. Backblaze B2 is slightly cheaper for storage and offers a free 10 GB tier. If you restore across regions often, R2 saves money. If storage is your main cost, B2 might be cheaper.

How do I know if my backup hasn't been corrupted?

Test restores regularly, at least quarterly. Check file checksums: md5sum backup.sql.gz and keep the hash recorded. Verify the checksum again before restoring to ensure the file is still intact.

Summary

Good backups require multiple layers, actually testable restores, and copies stored in different locations. Spending an hour now to set up a solid backup system can save you days or weeks of recovery time in the future.