How to Take VPS Snapshots and Restore: Backup Strategy for Hong Kong VPS (2026)

A VPS without tested backups is a server waiting to fail catastrophically. Database corruption, accidental rm -rf commands, ransomware, hardware failures, and botched updates all happen — the question is not whether, but when. A working backup and restore strategy is the difference between a recoverable incident and a business-ending data loss event.

This guide covers every backup option available for a Hong Kong VPS: provider-level snapshots, file-system backups with restic, database-specific backups, and the operational disciplines that ensure your backups are actually usable when you need them.

Understanding Your Backup Options

The right answer is all of the above — they complement each other and cover different failure scenarios. Provider snapshots cover catastrophic failures; file backups cover accidental deletion; database dumps cover data corruption.

Layer 1: Provider-Level Snapshots

A VPS snapshot is a point-in-time disk image taken by the hypervisor — the fastest path to full server recovery because it captures the entire system state (OS, configuration, installed software, all data) in a single operation.

When to take snapshots

• Before major changes: System upgrades, configuration changes, software migrations — take a snapshot immediately before, so you can roll back instantly if something breaks
• Before deploying new application versions: Especially for changes touching database schema or configuration files
• Weekly scheduled snapshots: A recent full-system restore point independent of your application-level backups

Snapshot limitations

• Snapshots capture a point in time — a snapshot taken yesterday does not protect against data entered today
• Snapshots are typically stored in the same provider infrastructure — not independent of provider-level failures
• Most providers charge for snapshot storage — size your retention policy accordingly

Layer 2: Automated File Backup with Restic

Restic provides encrypted, incremental, deduplicated backups to any S3-compatible storage — Cloudflare R2, Backblaze B2, or AWS S3. It is the recommended tool for application-level VPS backup.

apt install -y restic

Configure backup to Cloudflare R2

nano /root/backup-config.env

export AWS_ACCESS_KEY_ID=your_r2_access_key
export AWS_SECRET_ACCESS_KEY=your_r2_secret_key
export RESTIC_REPOSITORY=s3:https://YOUR_ACCOUNT_ID.r2.cloudflarestorage.com/your-backup-bucket
export RESTIC_PASSWORD=your_strong_encryption_password

chmod 600 /root/backup-config.env

# Initialise the repository (first time only)
source /root/backup-config.env
restic init

Create the backup script

nano /root/backup.sh

#!/bin/bash
set -e
source /root/backup-config.env

LOG="/var/log/restic-backup.log"
echo "=== Backup started: $(date) ===" >> $LOG

# Backup key directories
restic backup \
  /etc \
  /home \
  /var/www \
  /root \
  --exclude /home/*/.cache \
  --exclude /var/www/*/node_modules \
  --exclude /var/cache \
  --tag "daily" \
  --verbose 2>> $LOG

# Database backups — dump first, then include in file backup
echo "Backing up databases..." >> $LOG
mkdir -p /tmp/db-backups

# MySQL/MariaDB
mysqldump --all-databases --single-transaction \
  > /tmp/db-backups/all-databases-$(date +%Y%m%d).sql 2>> $LOG

# PostgreSQL (if installed)
if systemctl is-active postgresql >/dev/null 2>&1; then
  sudo -u postgres pg_dumpall > /tmp/db-backups/postgres-$(date +%Y%m%d).sql 2>> $LOG
fi

# Include DB dumps in backup
restic backup /tmp/db-backups --tag "database" 2>> $LOG

# Clean up temporary dumps
rm -rf /tmp/db-backups

# Apply retention policy
restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6 \
  --prune 2>> $LOG

# Verify backup integrity
restic check 2>> $LOG

echo "=== Backup completed: $(date) ===" >> $LOG

chmod 700 /root/backup.sh

# Test the backup manually first
source /root/backup-config.env
/root/backup.sh

# List snapshots to verify
restic snapshots

Schedule automated backups

crontab -e
# Add:
0 2 * * * /root/backup.sh >> /var/log/restic-backup.log 2>&1

Layer 3: Database-Specific Backup

Database backups deserve special attention — they capture the most critical, frequently-changing data and require specific handling for consistency:

MySQL/MariaDB — consistent hot backup

#!/bin/bash
# Individual database backup with compression
BACKUP_DIR="/var/backups/mysql"
MYSQL_USER="backup_user"
MYSQL_PASS="backup_password"
DATE=$(date +%Y%m%d_%H%M)

mkdir -p $BACKUP_DIR

# List all databases and back up each individually
mysql -u $MYSQL_USER -p$MYSQL_PASS -e "SHOW DATABASES;" \
  | grep -Ev "Database|information_schema|performance_schema|sys" \
  | while read db; do
      mysqldump -u $MYSQL_USER -p$MYSQL_PASS \
        --single-transaction \
        --routines \
        --triggers \
        "$db" | gzip > "$BACKUP_DIR/${db}_${DATE}.sql.gz"
      echo "Backed up: $db"
  done

# Remove backups older than 7 days
find $BACKUP_DIR -name "*.sql.gz" -mtime +7 -delete

PostgreSQL — pg_dump with compression

#!/bin/bash
BACKUP_DIR="/var/backups/postgres"
DATE=$(date +%Y%m%d_%H%M)
mkdir -p $BACKUP_DIR

# Backup all databases in custom format (most flexible for restore)
sudo -u postgres pg_dumpall -Fc > "$BACKUP_DIR/all_databases_${DATE}.dump"
gzip "$BACKUP_DIR/all_databases_${DATE}.dump"

# Remove old backups
find $BACKUP_DIR -name "*.dump.gz" -mtime +7 -delete

Layer 4: Recovery Planning and Testing

Define your RPO and RTO

• RPO (Recovery Point Objective): Maximum acceptable data loss. Daily backups → RPO = 24 hours. Hourly database backups → RPO = 1 hour. Streaming replication → RPO = seconds.
• RTO (Recovery Time Objective): Maximum acceptable downtime during recovery. Provider snapshot restore → RTO = 15–30 minutes. File-by-file restore → RTO = 1–4 hours depending on data size.

Monthly restore test procedure

# Test restic restore to a temporary directory (non-destructive)
source /root/backup-config.env

# List available snapshots
restic snapshots

# Restore specific snapshot to test location
restic restore latest --target /tmp/restore-test

# Verify the restored files match expectations
ls -la /tmp/restore-test/home/deploy/apps/
diff -r /home/deploy/apps/ /tmp/restore-test/home/deploy/apps/ | head -50

# Test database restore to a test database
mysql -u root -p -e "CREATE DATABASE restore_test;"
zcat /var/backups/mysql/myapp_db_20260401_0200.sql.gz | mysql -u root -p restore_test

# Verify row counts match production
mysql -u root -p -e "SELECT COUNT(*) FROM restore_test.users;"
mysql -u root -p -e "SELECT COUNT(*) FROM myapp_db.users;"

# Clean up test restore
rm -rf /tmp/restore-test
mysql -u root -p -e "DROP DATABASE restore_test;"

Critical rule: A backup you have never restored from is not a backup — it is an optimistic assumption. Test your restore procedure monthly. Document the exact steps. Time the restore. Know your actual RTO before you need it.

Conclusion

A complete Hong Kong VPS backup strategy combines provider snapshots (full-system recovery), restic file backups (application-level recovery with retention policy), and database-specific dumps (data recovery). The entire automated backup stack costs pennies per day in storage — a fraction of the cost of recovering from unprotected data loss.

Implement backups on your Server.HK Hong Kong VPS today — before you need them. Cloudflare R2 provides zero-egress-fee backup storage, making off-site backup economically trivial for any size deployment.

Frequently Asked Questions

How often should I take VPS snapshots?

Take provider snapshots before any major change (not on a fixed schedule). Schedule weekly automated snapshots for a general restore point. For databases with frequent writes, application-level database dumps every 1–4 hours provide a much tighter RPO than weekly snapshots alone. The combination of weekly snapshots + hourly database dumps covers most failure scenarios.

Is Cloudflare R2 a good backup destination for a Hong Kong VPS?

Yes. R2 provides S3-compatible object storage with zero egress fees — you pay only for storage ($0.015/GB/month) not for reading your backups back. For a 50 GB backup set, that is $0.75/month in storage with no retrieval cost. R2’s global edge network also means your backups are distributed across multiple geographic locations automatically.

What happens if I need to restore my entire Hong Kong VPS from scratch?

If your VPS becomes completely unrecoverable (hardware failure, ransomware), the recovery process is: (1) provision a new VPS from your provider, (2) restore the latest provider snapshot if available, or (3) install the OS fresh and restore files from restic backup, then restore databases from dumps. Document this procedure and estimate your actual RTO — most VPS deployments can be fully restored within 2–4 hours from a complete file backup.