Overview
XSDS offers two data protection strategies: replication and erasure coding. The appropriate choice depends on your durability requirements, acceptable storage overhead, and the latency sensitivity of your workload.Prerequisites
- An active Xloud account with project member access
- Contact your storage administrator to provision erasure-coded pools — they are configured at the cluster level by an administrator. Your administrator can configure this through XDeploy.
Protection Strategy Comparison
Replication
Replication stores multiple complete copies of every object across separate OSDs. The default replication factor is 3 — three full copies are maintained at all times.- How It Works
- Selecting a Replicated Pool
When data is written to a replicated pool, XSDS simultaneously writes it to the
number of OSDs defined by the replication factor. Each copy is placed on a
different host according to the CRUSH map, ensuring that host-level failures
do not cause data loss.
Characteristics:
- Lower read/write latency compared to erasure coding
- Higher raw storage overhead (3× capacity for factor-3)
- Recovery is faster after an OSD failure
- Best suited for latency-sensitive workloads (databases, boot volumes)
Erasure Coding
Erasure coding divides data into data chunks and parity chunks, distributing them across OSDs. The data can be reconstructed from any sufficient subset of chunks, providing durability at significantly lower storage overhead than replication.- How It Works
- Using Erasure-Coded Pools
In an erasure-coded profile
k+m, data is split into k data chunks and m
parity chunks. The pool can tolerate the loss of any m OSDs and reconstruct
the data from the remaining k chunks.Characteristics:
- Significantly lower storage overhead compared to replication
- Higher CPU and network overhead for encoding/decoding
- Best suited for large objects: backups, archives, cold data
- Recovery after failure takes longer than replication
Validation
Confirm your volume is using the expected protection policy:- Dashboard
- CLI
Navigate to Project → Volumes → Volumes and click on the volume name.
The Volume Type field shows which pool backs this volume. Contact your
storage administrator to confirm the protection scheme for that pool type. Your administrator can configure this through XDeploy.
Best Practices
Production Workloads
Use replication factor 3 for all production databases, application volumes, and
frequently-accessed data. The lower latency outweighs the higher storage cost for
latency-sensitive workloads.
Backup & Archive
Use erasure-coded pools (4+2 or 6+2) for backup targets and archives. The storage
efficiency savings are significant at scale, and higher latency is acceptable for
infrequent access patterns.
Development Environments
Replication factor 2 is sufficient for non-critical development and test volumes.
Reduces storage consumption while maintaining single-failure protection.
Pre-Maintenance Snapshots
Combine data protection pools with regular snapshots for layered protection. Pools
protect against hardware failures; snapshots protect against logical corruption and
accidental deletion.
Next Steps
Snapshots
Create point-in-time snapshots to complement pool-level data protection
Storage Tiers
Route workloads to NVMe, SSD, or HDD tiers based on access patterns
XSDS Admin — Pool Management
Create and configure replicated and erasure-coded pools (administrator)
XSDS Admin — CRUSH Maps
Configure failure domains and device class rules (administrator)