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
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.
Verify the snapshot
Navigate to Project → Volumes → Snapshots. The snapshot displays with
status Available.
Snapshot is available and ready for restore or volume creation.
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.
Locate the snapshot
Navigate to Project → Volumes → Snapshots and find the snapshot to restore.
Create a volume from the snapshot
Click Actions → Create Volume next to the snapshot.
Attach and mount the restored volume
Attach the restored volume to the target instance:
Attach restored volume
The restored volume appears as a new block device and contains
the data from the snapshot point in time.
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