> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xloud.tech/llms.txt
> Use this file to discover all available pages before exploring further.

# Data Protection

> Configure replication and erasure coding in XSDS to protect your data against hardware failures with the right balance of durability and storage efficiency.

## 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.

<Note>
  **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](/deployment).
</Note>

***

## 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.

<Tabs>
  <Tab title="How It Works" icon="copy">
    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.

    | 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×               |

    **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)
  </Tab>

  <Tab title="Selecting a Replicated Pool" icon="gauge">
    Volume types in the Xloud Dashboard map to specific storage pools. Replicated pools
    appear as volume types with names such as `ceph-ssd` or `ceph-nvme`.

    <Steps titleSize="h3">
      <Step title="Check available volume types" icon="list">
        ```bash title="List available volume types" theme={null}
        openstack volume type list
        ```

        Contact your storage administrator to determine which volume types are backed
        by replicated pools versus erasure-coded pools. Your administrator can configure this through [XDeploy](/deployment).
      </Step>

      <Step title="Create a volume on a replicated pool" icon="plus">
        ```bash title="Create volume on SSD-replicated pool" theme={null}
        openstack volume create \
          --size 100 \
          --type ceph-ssd \
          prod-database-data
        ```

        <Check>Volume is created with the specified type and the replication factor
        defined by the pool configuration.</Check>
      </Step>
    </Steps>

    <Tip>
      Use replication factor 3 for all production block volumes and actively-accessed
      object data. Reserve factor 2 only for non-critical development environments.
    </Tip>
  </Tab>
</Tabs>

***

## 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.

<Tabs>
  <Tab title="How It Works" icon="code">
    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.

    | 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    |

    **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
  </Tab>

  <Tab title="Using Erasure-Coded Pools" icon="gauge">
    Erasure-coded pools are configured by your storage administrator. Once provisioned,
    they appear as volume types or object storage containers using that pool.

    <Note>
      Erasure coding is enabled at the pool level during pool creation by an
      administrator. Contact your storage administrator to provision an erasure-coded
      pool for your project. Your administrator can configure this through [XDeploy](/deployment). See the [XSDS Admin Guide](/services/sds/admin-guide/pool-management)
      for pool creation procedures.
    </Note>

    To verify which pool a volume type uses:

    ```bash title="Show volume type details" theme={null}
    openstack volume type show <TYPE_NAME> -c extra_specs
    ```

    The `volume_backend_name` extra spec maps to the storage pool on the backend.
  </Tab>
</Tabs>

***

## Validation

Confirm your volume is using the expected protection policy:

<Tabs>
  <Tab title="Dashboard" icon="gauge">
    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](/deployment).
  </Tab>

  <Tab title="CLI" icon="terminal">
    ```bash title="Show volume type" theme={null}
    openstack volume show <VOLUME_NAME> -c volume_type
    ```

    ```bash title="Show pool backing the volume type" theme={null}
    openstack volume type show <VOLUME_TYPE> -c extra_specs
    ```

    <Check>The `volume_backend_name` extra spec confirms which storage pool and
    protection scheme is active for your volume.</Check>
  </Tab>
</Tabs>

***

## Best Practices

<CardGroup cols={2}>
  <Card title="Production Workloads" icon="server" color="#197560">
    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.
  </Card>

  <Card title="Backup & Archive" icon="archive" color="#197560">
    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.
  </Card>

  <Card title="Development Environments" icon="flask-conical" color="#197560">
    Replication factor 2 is sufficient for non-critical development and test volumes.
    Reduces storage consumption while maintaining single-failure protection.
  </Card>

  <Card title="Pre-Maintenance Snapshots" icon="copy" color="#197560">
    Combine data protection pools with regular snapshots for layered protection. Pools
    protect against hardware failures; snapshots protect against logical corruption and
    accidental deletion.
  </Card>
</CardGroup>

***

## Next Steps

<CardGroup cols={2}>
  <Card title="Snapshots" href="/services/sds/user-guide/snapshots" color="#197560">
    Create point-in-time snapshots to complement pool-level data protection
  </Card>

  <Card title="Storage Tiers" href="/services/sds/user-guide/performance" color="#197560">
    Route workloads to NVMe, SSD, or HDD tiers based on access patterns
  </Card>

  <Card title="XSDS Admin — Pool Management" href="/services/sds/admin-guide/pool-management" color="#197560">
    Create and configure replicated and erasure-coded pools (administrator)
  </Card>

  <Card title="XSDS Admin — CRUSH Maps" href="/services/sds/admin-guide/crush-maps" color="#197560">
    Configure failure domains and device class rules (administrator)
  </Card>
</CardGroup>