Overview
Snapshots capture the state of a volume at a specific point in time. They are space-efficient — only changed blocks are stored after the initial snapshot is taken. Snapshots can be used to restore a volume to a previous state or to create new volumes pre-populated with the same data.Prerequisites
- An active Xloud account with project member access
- Source volume must exist and be accessible
- Sufficient snapshot quota in your project (check with your administrator)
Creating Snapshots
- Dashboard
- CLI
Navigate to Volumes
Log in to the Xloud Dashboard (
https://connect.<your-domain>) and navigate to
Project → Volumes → Volumes.Create a snapshot
In the volume list, click the Actions dropdown next to the target volume and
select Create Snapshot.
| Field | Description |
|---|---|
| Snapshot Name | Descriptive name including date or context |
| Description | Optional — notes about the purpose of this snapshot |
Restoring from Snapshots
- Create Volume from Snapshot
- CLI Restore
Create a new volume pre-populated with the snapshot data. This is the primary
restore method — the original volume is preserved.
Create a volume from the snapshot
Click Actions → Create Volume next to the snapshot.
| Field | Value |
|---|---|
| Volume Name | Descriptive name for the restored volume |
| Size | Must be equal to or larger than the snapshot size |
| Volume Type | Select the appropriate storage tier |
Managing Snapshots
- Dashboard
- CLI
Navigate to Project → Volumes → Snapshots to manage all project snapshots.Available actions:
- Create Volume — create a new volume from the snapshot
- Edit Snapshot — update the name or description
- Delete Snapshot — permanently remove the snapshot
Consistency Considerations
Crash-consistent snapshots
Crash-consistent snapshots
By default, XSDS snapshots are crash-consistent — they capture the on-disk state
at the moment of the snapshot request. This is equivalent to pulling the power cord
from the machine and is safe for most file systems (ext4, XFS) that use journaling
for recovery.However, for databases and stateful applications, crash-consistent snapshots may
capture in-flight transactions in an inconsistent state. The database will recover
on next startup, but some in-flight transactions may be lost.
Application-consistent snapshots
Application-consistent snapshots
For databases and transactional applications, coordinate the snapshot with
application-level freeze/thaw procedures:
PostgreSQL: flush and freeze
MySQL: flush tables with read lock
Next Steps
Data Protection
Pool-level replication and erasure coding for hardware failure protection
Disaster Recovery
Replicate volumes to a DR site for site-level failure protection
Block Storage Snapshots
Full lifecycle management for block volume snapshots
Troubleshooting
Diagnose snapshot creation failures and stuck snapshot states