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
| Strategy | Storage Overhead | Latency | Failure Tolerance | Best For |
|---|---|---|---|---|
| Replication (factor 3) | 3× raw capacity | Low | 2 simultaneous OSD failures | Databases, boot volumes, latency-critical |
| Erasure Coding (4+2) | 1.5× raw capacity | Higher | 2 OSD failures | Backups, archives, large object stores |
| Erasure Coding (8+3) | 1.375× raw capacity | Higher | 3 OSD failures | Very large datasets requiring maximum efficiency |
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:
| Replication Factor | Copies | Survives Simultaneous Failures | Storage Overhead |
|---|---|---|---|
| 2 | 2 copies | 1 OSD failure | 2× |
| 3 (default) | 3 copies | 2 OSD failures | 3× |
| 4 | 4 copies | 3 OSD failures | 4× |
- 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
Characteristics:
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.| Profile | Data Chunks (k) | Parity Chunks (m) | Overhead | Failure Tolerance |
|---|---|---|---|---|
| 4+2 | 4 | 2 | 1.5× | 2 OSD failures |
| 6+2 | 6 | 2 | 1.33× | 2 OSD failures |
| 8+3 | 8 | 3 | 1.375× | 3 OSD failures |
- 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)