VPS Snapshots

Complete guide to creating, managing, and restoring VPS snapshots for backup and cloning purposes.

What are Snapshots?

Snapshots are point-in-time copies of your VPS instance, including:

  • Operating system and all files
  • Applications and configurations
  • Data stored on the instance
  • Complete system state at capture time

Snapshots vs Backups

FeatureSnapshotsTraditional Backups
SpeedVery fast (minutes)Slower (hours)
DowntimeNone requiredMay require downtime
RestoreComplete system restoreFile-level restore
Use CaseSystem cloning, migrationsData recovery
StorageBlock-levelFile-level

Why Use Snapshots?

Backup Before Changes

Take a snapshot before:

  • System updates
  • Application upgrades
  • Configuration changes
  • Installing new software
  • Database migrations

Disaster Recovery

  • Quick recovery from failures
  • Protection against mistakes
  • Rollback bad deployments
  • Restore corrupted systems

Cloning & Scaling

  • Create identical instances
  • Scale horizontally
  • Test environments
  • Development copies

Migration

  • Move to a different host
  • Upgrade instance size
  • Change configurations
  • Platform migration

Automated Snapshots

Every running VPS is snapshotted automatically on a daily schedule — no setup required. Automated snapshots:

  • Run only while the instance is running, so you're never charged for wasted backups of stopped instances
  • Are kept for a rolling retention window and cleaned up automatically once they age out
  • Appear alongside your manual snapshots (tagged automated) and can be restored or cloned the same way
  • Get a second copy in the platform backup store (see below)

You can still take manual snapshots anytime before risky changes — those are kept until you delete them.

Second copies

Beyond the primary snapshot stored with your instance, snapshots are exported to the platform backup store, a separate storage system in the same datacenter. That is a second copy, not an offsite one: the protection label on a snapshot says second copy, and it reads as verified once the hourly check has confirmed the copy is there. That offsite export is also what makes cloning a snapshot into a brand-new instance possible. If an export fails, you can retry it from the Snapshots page.

Creating Snapshots

Via Dashboard

  1. Navigate to Pods (VPS)
  2. Click on your instance name
  3. Go to Snapshots tab
  4. Click Create Snapshot
  5. Enter snapshot details:
    • Name: Descriptive name
    • Description: Purpose and context
  6. Click Create

Creation Time: 2-5 minutes depending on disk size

Snapshot Naming Best Practices

Good Names:

Text
pre-update-2024-10-11
before-nginx-upgrade
production-backup-daily
staging-clone-v2
migration-source

Poor Names:

Text
snapshot1
backup
test
my-snapshot

Naming Convention

Text
[environment]-[purpose]-[date]
prod-pre-deploy-2024-10-11
staging-backup-2024-10-11
dev-clone-2024-10-11

Snapshot Details

What's Included

✅ Operating System: All OS files
✅ Applications: Installed software
✅ Configurations: All config files
✅ Data: Application data, databases
✅ Users: User accounts and permissions
✅ Logs: System and application logs

What's NOT Included

❌ RAM Contents: Active memory state
❌ Network Connections: Active connections
❌ Temporary Files: /tmp contents may vary
❌ Process State: Running processes

Best Practices Before Snapshot

  1. Stop Services (optional but recommended):

    Bash
    # Stop database
sudo systemctl stop mysql

# Stop application
sudo systemctl stop nginx

  2. Flush Caches:

    Bash
    # Sync filesystem
sync

# Drop caches
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

  3. Database Backup:

    Bash
    # MySQL
mysqldump -u root -p --all-databases > backup.sql

# PostgreSQL
pg_dumpall > backup.sql

  4. Document State:

    • Running services
    • Important processes
    • Configuration details

Managing Snapshots

View Snapshots

  1. Go to VPS instance page
  2. Click Snapshots tab
  3. See all snapshots:
    • Name and description
    • Creation date
    • Size
    • Status

Snapshot Statuses

  • Creating: Snapshot in progress
  • Available: Ready to use
  • Restoring: Being restored
  • Deleting: Being removed
  • Error: Failed creation/restore

Snapshot status and progress update live on the page — no refresh needed — including offsite export progress.

Delete Snapshot

Warning: Deletion is permanent!

  1. Go to Snapshots tab
  2. Click Delete next to snapshot
  3. Confirm deletion
  4. Snapshot removed immediately

Note: You're charged for snapshot storage until deleted.

Restoring from Snapshots

Replace the Existing Instance

Warning: This puts the snapshot's data back into your current instance; everything written after the snapshot is lost.

You can start it from either the per-instance Backups tab or the Backups & recovery page. When replacing is open for your account, the action opens the restore wizard in replace mode: a safety snapshot of the current disk is taken first unless you decline it, the review states the data-loss cutoff, and you type the instance name to confirm. The wizard uses the local snapshot while it is intact, otherwise the exported copy.

  1. Back up current data if needed
  2. Go to the Backups tab on the instance page, or open Backups & recovery in the sidebar
  3. Choose Replace existing next to the snapshot
  4. Review the impact, type the instance name, and start the restore
  5. Follow the operation page; a restore takes 5-10 minutes from a local snapshot and longer from the exported copy

What Happens:

  • The VM is stopped if running
  • Disk data is replaced with the snapshot contents
  • The VM is restarted automatically
  • Any data created after the snapshot will be lost

Create New Instance from Snapshot (Clone)

Safer option - doesn't affect the existing instance.

Cloning a VPS from a snapshot uses the export-based clone workflow, which requires the snapshot's exported copy to be completed first.

Prerequisites:

  • Snapshot status must be Ready
  • Export (the second copy) must be Completed
  • No other clone operation in progress for this snapshot

Steps:

  1. Go to the Snapshots tab on the instance page, or navigate to Snapshots in the sidebar
  2. Click the Clone button (copy icon) next to an eligible snapshot
  3. Enter a name for the new VPS instance (lowercase letters, numbers, and hyphens; 3-32 characters)
  4. Click Clone Instance

Clone Process: The clone operation downloads the snapshot data from offsite storage, decompresses it, and deploys a new VPS. You can track progress through these stages:

  • Preparing - Setting up the clone operation
  • Downloading - Retrieving snapshot data from S3 storage
  • Decompressing - Extracting the disk image
  • Importing - Creating the new disk volume
  • Deploying - Launching the new VPS instance

What the New VPS Inherits:

  • Operating system and all files from the snapshot
  • Disk size and resource profile from the original instance

What's New:

  • New IPv4 (and optionally IPv6) address
  • New MAC address
  • New instance name

Duration: 10-30 minutes depending on disk size.

Centralized Snapshots Page

Navigate to Snapshots in the sidebar to access the centralized snapshots page at /snapshots. This page shows all snapshot types (VPS, Cache, Database) in a single view.

Features:

  • Filter by instance type (VPS, Cache, Database), status, and automated/manual
  • Search by instance name
  • Restore any snapshot to its parent instance
  • Clone to create a new instance from a snapshot
  • Delete snapshots that are no longer needed
  • Retry failed offsite backups

After Restore

  1. Verify System:

    Bash
    # Check system status
uptime
df -h
free -h

# Verify services
sudo systemctl status nginx
sudo systemctl status mysql

  2. Update Configurations:

    • Update IP addresses
    • Update DNS records
    • Update environment variables
    • Update API endpoints

  3. Start Services:

    Bash
    sudo systemctl start nginx
sudo systemctl start mysql
sudo systemctl start your-app

Snapshot Use Cases

Use Case 1: Safe System Updates

Scenario: Ubuntu system update

Bash
# 1. Create snapshot via dashboard
# Name: "pre-update-2024-10-11"

# 2. Perform update
sudo apt update
sudo apt upgrade -y
sudo apt dist-upgrade -y

# 3. Test system
# If problems occur, restore from snapshot
# If all good, keep running

# 4. Delete old snapshot after confirmed working

Use Case 2: Application Deployment

Scenario: Deploy new application version

Bash
# 1. Create snapshot
# Name: "pre-deploy-v2.0"

# 2. Deploy new version
git pull origin main
npm install
npm run build
sudo systemctl restart app

# 3. Test thoroughly
# If issues, restore snapshot
# If successful, keep and delete old snapshot

Use Case 3: Development Environment

Scenario: Create dev copy of production

  1. Create snapshot of production instance
  2. Restore to new instance
  3. Rename new instance to "dev-environment"
  4. Update configurations:
    • Change database credentials
    • Update API keys (use test keys)
    • Disable production integrations
    • Update application URLs

Use Case 4: Horizontal Scaling

Scenario: Add more web servers

  1. Prepare one server perfectly:

    • Install all software
    • Configure everything
    • Test thoroughly

  2. Create snapshot "web-server-template"

  3. Create multiple instances from snapshot:

    • web-server-01
    • web-server-02
    • web-server-03

  4. Configure load balancer to distribute traffic

Use Case 5: Migration

Scenario: Move to larger instance

  1. Create snapshot of current instance
  2. Create new instance from snapshot
    • Choose a larger profile
  3. Test new instance
  4. Update DNS to point to new instance
  5. Delete old instance
  6. Delete old snapshot

Automation with API

VPS snapshots have their own endpoints, under https://danubedata.ro/api/v1/snapshots/vps. The API token needs snapshot:read to list snapshots, snapshot:write to create them and snapshot:delete to delete them.

Create Snapshot

Python
import requests
from datetime import datetime

headers = {
    "Authorization": "Bearer YOUR_TOKEN",
    "Content-Type": "application/json"
}

data = {
    "vps_instance_id": "vps-abc123",
    "name": f"auto-backup-{datetime.now().strftime('%Y-%m-%d')}",
    "description": "Automated daily backup"
}

response = requests.post(
    "https://danubedata.ro/api/v1/snapshots/vps",
    headers=headers,
    json=data
)

snapshot = response.json()["snapshot"]
print(f"Snapshot created: {snapshot['id']}")

List Snapshots

The list covers every VPS in your team, newest first, a page at a time. Each snapshot names its vps_instance_id.

Python
response = requests.get(
    "https://danubedata.ro/api/v1/snapshots/vps",
    headers=headers,
    params={"per_page": 200}
)

snapshots = response.json()["data"]
for snap in snapshots:
    if snap["vps_instance_id"] == "vps-abc123":
        print(f"{snap['name']}: {snap['created_at']}")

Automated Daily Backup Script

Python
#!/usr/bin/env python3
import requests
import os
from datetime import datetime, timedelta, timezone

API_TOKEN = os.environ['DANUBEDATA_API_TOKEN']
VPS_ID = "vps-abc123"
RETENTION_DAYS = 7

headers = {
    "Authorization": f"Bearer {API_TOKEN}",
    "Content-Type": "application/json"
}

# Create new snapshot
data = {
    "vps_instance_id": VPS_ID,
    "name": f"daily-backup-{datetime.now().strftime('%Y-%m-%d')}",
    "description": f"Automated backup - {datetime.now()}"
}

response = requests.post(
    "https://danubedata.ro/api/v1/snapshots/vps",
    headers=headers,
    json=data
)

if response.status_code == 201:
    print(f"Snapshot created successfully")
else:
    print(f"Error: {response.json()}")
    exit(1)

# Delete old snapshots of this VPS. The oldest are on the last pages.
snapshots = []
page = 1
while True:
    response = requests.get(
        "https://danubedata.ro/api/v1/snapshots/vps",
        headers=headers,
        params={"per_page": 200, "page": page}
    )
    body = response.json()
    snapshots += body["data"]
    if page >= body["pagination"]["last_page"]:
        break
    page += 1

cutoff_date = datetime.now(timezone.utc) - timedelta(days=RETENTION_DAYS)

for snap in snapshots:
    if snap['vps_instance_id'] != VPS_ID:
        continue
    snap_date = datetime.fromisoformat(snap['created_at'].replace('Z', '+00:00'))
    if snap_date < cutoff_date and snap['name'].startswith('daily-backup'):
        print(f"Deleting old snapshot: {snap['name']}")
        requests.delete(
            f"https://danubedata.ro/api/v1/snapshots/vps/{snap['id']}",
            headers=headers
        )

Schedule with Cron:

Bash
# Add to crontab
0 2 * * * /usr/local/bin/backup-vps.py

Snapshot Pricing

Storage Costs

  • Price: €0.073 per GB per month
  • Billed: Hourly (prorated)
  • Size: Based on used disk space

Cost Examples

Instance SizeUsed SpaceMonthly Cost
20 GB disk10 GB used€0.73
40 GB disk25 GB used€1.83
80 GB disk40 GB used€2.92
160 GB disk80 GB used€5.84

Cost Optimization

  1. Delete old snapshots regularly
  2. Clean disk before snapshot:
    Bash
    sudo apt clean
sudo journalctl --vacuum-time=7d
docker system prune -a
  3. Keep only necessary snapshots
  4. Use compression before snapshot
  5. Remove unused files

Best Practices

Regular Snapshots

Daily Production:

  • Before any changes
  • Automated nightly backups
  • Keep 7 days

Weekly Development:

  • End of sprint
  • Before major updates
  • Keep 4 weeks

Pre-Change Always:

  • Before system updates
  • Before deployments
  • Before configuration changes

Naming Strategy

Text
[frequency]-[environment]-[date]
daily-prod-2024-10-11
weekly-staging-2024-10-11
pre-deploy-prod-2024-10-11

Testing Restores

Monthly: Test restore process

  1. Create test instance from snapshot
  2. Verify all services work
  3. Confirm data integrity
  4. Document restore time
  5. Delete test instance

Documentation

Keep a snapshot log:

Text
Date       | Name              | Purpose           | Retention
-----------|-------------------|-------------------|----------
2024-10-11 | pre-update-v2     | Before Ubuntu 24  | 30 days
2024-10-11 | daily-prod        | Daily backup      | 7 days
2024-10-10 | pre-deploy-api    | Before API v3     | 14 days

Troubleshooting

Snapshot Creation Fails

Check:

  1. Disk space available
  2. Instance is running
  3. No other operations in progress
  4. Account limits not exceeded

Solution:

Bash
# Free up space
sudo apt clean
sudo journalctl --vacuum-time=7d
rm -rf /tmp/*

# Check disk
df -h

Restore Fails

Possible Causes:

  • Insufficient resources
  • Snapshot corrupted
  • Network issues

Solution:

  1. Try again
  2. Contact support
  3. Use different snapshot
  4. Check system logs

Slow Snapshot Creation

Factors:

  • Disk size
  • Data amount
  • Disk activity
  • Network speed

Optimization:

  • Stop services temporarily
  • Reduce disk I/O
  • Schedule during low-traffic
  • Clean disk before snapshot

Limitations

Size Limits

  • Maximum snapshot size: Based on disk size
  • Storage per account: Check account limits

Quantity Limits

  • Snapshots per instance: 50 (default)
  • Request increase if needed

Region

  • Snapshots are stored redundantly in the same region (Falkenstein, Germany)
  • For offsite copies, download or export the snapshot

Time Limits

  • Creation time: 2-10 minutes
  • Restore time: 5-15 minutes
  • Depends on size

Security Considerations

Data Protection

⚠️ Not Encrypted at Rest: The local snapshot is stored unencrypted, like the disk it copies. Encrypt sensitive data inside the server if it must be encrypted at rest
✅ Access Control: Only account members can access
✅ Isolated Storage: Separate from instance storage
✅ Backup Redundancy: Multiple copies maintained

Sensitive Data

Before Snapshot:

  1. Review for sensitive data
  2. Remove temporary secrets
  3. Clear logs with sensitive info
  4. Document included credentials

After Restore:

  1. Rotate credentials
  2. Update API keys
  3. Change passwords
  4. Verify access controls

Next Steps

Need help with snapshots? Contact support through the dashboard.