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
- Take snapshot
- Make change
- Test thoroughly
- If good: delete snapshot (save space)
- 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
- Assess what happened
- Decide: snapshot restore or selective file restore?
- If snapshot: restore and verify
- If selective: restore specific files/databases
- Test everything works
- Investigate root cause
- 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.
