Cloud Server Snapshot and Backup Strategies

Your server's disk failed, you were hit by a ransomware attack, or you accidentally deleted the production database - if any of these scenarios occur and you don't have a current backup, data loss is inevitable. A cloud server backup strategy goes beyond the question "are we backing up?" to answer "how quickly can we recover?" In this guide, we cover the difference between snapshots and backups, the 3-2-1 rule, RPO/RTO calculation, and automated backup setup.

Why Is Backup Critical?

The most common causes of data loss are: hardware failure, human error (wrong command, accidental file deletion), software bugs, cyber attacks (ransomware), and natural disasters. Without backups, your chances of recovery in any of these scenarios are close to zero.

RPO and RTO: Define Your Recovery Objectives

Before creating a backup strategy, you need to determine two critical metrics:

For an e-commerce site, RPO might be 5 minutes and RTO 15 minutes, while for a personal blog, RPO of 24 hours and RTO of a few hours may be acceptable. These values determine your backup frequency and method.

Difference Between Snapshot and Backup

The 3-2-1 Backup Rule

The industry-standard 3-2-1 rule has been expanded to 3-2-1-1-0 in modern infrastructure:

• 3 copies The original data + 2 backup copies. A single backup isn't enough because the backup itself can become corrupted.
• 2 different media For example: server disk + S3-compatible object storage. Two copies on the same disk type are vulnerable to the same failure mode.
• 1 offsite (remote location) At least one copy should be in a different data center or geographic region. A fire/flood in the same data center can destroy both copies.
• 1 immutable copy Against ransomware attacks, at least one copy should be write-protected (immutable). S3 Object Lock or WORM storage is used for this purpose.
• 0 errors (verified restore) Regular restore testing from backups should be performed. An untested backup doesn't count as a backup.

Backup Automation Setup

Incremental Backup with rsync

rsync is ideal for incremental backups since it only transfers changed files. You can perform secure backups to a remote server over SSH.

#!/bin/bash
DATE=$(date +%Y-%m-%d_%H-%M)
BACKUP_DIR="/backup"
REMOTE="backup-user@backup-server:/backups/myserver"

# Database backup
mysqldump --all-databases --single-transaction \
  --routines --triggers | gzip > "${BACKUP_DIR}/db-${DATE}.sql.gz"

# File backup (incremental - only changed files)
rsync -avz --delete \
  --exclude='node_modules' \
  --exclude='.cache' \
  /var/www/ "${BACKUP_DIR}/files/"

# Send to remote server (offsite copy)
rsync -avz -e "ssh -p 2222" \
  "${BACKUP_DIR}/" "${REMOTE}/"

# Clean up local backups older than 30 days
find "${BACKUP_DIR}" -name "db-*.sql.gz" -mtime +30 -delete

echo "[$(date)] Backup completed" >> /var/log/backup.log

# Run backup every night at 03:00
crontab -e
0 3 * * * /opt/scripts/backup.sh >> /var/log/backup-cron.log 2>&1

For more detailed information about database backup automation, you can review the official MySQL mysqldump documentation.

Backup Testing and Verification

An untested backup doesn't count as a backup. Perform a restore test from your backups at least once a month:

# 1. Restore database backup on test server
gunzip -c db-2026-03-20.sql.gz | mysql -u root -p test_restore_db

# 2. Verify table count and record count
mysql -u root -p -e "SELECT COUNT(*) FROM test_restore_db.users;"

# 3. Check file integrity
find /backup/files/ -type f | wc -l
find /var/www/ -type f | wc -l

You can easily implement your backup strategy on Hosted Cloud cloud servers. With the snapshot feature, you can take instant images before critical changes, and monitor the performance impact of backup processes with our resource monitoring guide.

Frequently Asked Questions

Conclusion

A backup strategy starts with your RPO and RTO objectives. Apply the 3-2-1-1-0 rule: keep backups on different media, in different locations, immutable, and tested. Use snapshots for quick rollback and rsync/mysqldump-based backups for disaster recovery. Most importantly: perform regular restore tests.