VPS Snapshots and Rollbacks: Your Safety Net for Server Changes

A snapshot captures your entire VPS at a point in time. If something goes wrong, roll back to the snapshot. It's an undo button for your server.

Snapshots vs Backups

| Feature | Snapshot | File Backup | |---------|----------|-------------| | Captures | Entire disk image | Selected files/databases | | Speed to create | Seconds-minutes | Minutes-hours | | Speed to restore | Minutes | Minutes-hours | | Storage cost | High (full disk copy) | Lower (incremental possible) | | Granularity | All or nothing | Individual files | | Best for | Before major changes | Daily protection |

Use both. Snapshots for safety before changes, backups for daily protection.

When to Take Snapshots

| Scenario | Risk Level | Snapshot Required? | |----------|-----------|-------------------| | Before OS upgrade | High | Yes | | Before major software update | High | Yes | | Before configuration changes | Medium | Recommended | | Before installing new software | Low-Medium | Recommended | | Before running unknown scripts | High | Yes | | Regular daily schedule | - | If available |

Snapshot Strategy

Pre-Change Snapshot

1. Take snapshot
2. Make change
3. Test thoroughly
4. If good: delete snapshot (save space)
5. If bad: restore snapshot

Scheduled Snapshots

| Frequency | Retention | Storage Need | |-----------|-----------|-------------| | Daily | 7 days | 7x disk size (max) | | Weekly | 4 weeks | 4x disk size (max) | | Monthly | 3 months | 3x disk size (max) |

Manual Backup Script

If your provider doesn't offer snapshots, create your own backup system:

#!/bin/bash
BACKUP_DIR="/backup"
DATE=$(date +%Y%m%d-%H%M)

# Create backup directory
mkdir -p $BACKUP_DIR

# Backup web files
tar czf $BACKUP_DIR/www-$DATE.tar.gz /var/www/

# Backup databases
mysqldump --all-databases > $BACKUP_DIR/db-$DATE.sql

# Backup configurations
tar czf $BACKUP_DIR/etc-$DATE.tar.gz /etc/

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

echo "Backup completed: $DATE"

Schedule with cron:

0 2 * * * /root/backup.sh >> /var/log/backup.log 2>&1

Off-Site Backups

Never keep all backups on the same server. If the server dies, so do your backups.

To Remote Server

rsync -avz /backup/ user@remote-server:/backups/vps1/

To Object Storage

# Using rclone to sync to any cloud storage
rclone sync /backup/ remote:vps-backups/

Disaster Recovery Plan

| Scenario | Recovery Method | Time | |----------|----------------|------| | Bad config change | Restore snapshot | 5-10 minutes | | Corrupted database | Restore from SQL dump | 10-30 minutes | | Hacked server | Restore snapshot + change all passwords | 30-60 minutes | | Hardware failure | Deploy new VPS + restore latest backup | 1-2 hours | | Accidental file deletion | Restore from file backup | 5-15 minutes |

Recovery Checklist

1. Assess what happened
2. Decide: snapshot restore or selective file restore?
3. If snapshot: restore and verify
4. If selective: restore specific files/databases
5. Test everything works
6. Investigate root cause
7. Prevent recurrence

Testing Your Backups

A backup you've never tested is a backup that might not work:

| Test | Frequency | |------|-----------| | Restore a random file from backup | Monthly | | Restore database and verify data | Monthly | | Full server restore to test VPS | Quarterly | | Verify backup script is running | Weekly |

Space-Node's VPS hosting uses NVMe SSD storage, making both snapshot creation and restoration fast. Combined with KVM virtualization, snapshots capture the complete machine state.