Segal Volumes

Keep block storage persistent across the lifecycle of a compatible compute instance.

The supported upstream service is Block Storage. Segal supplies the branded application and support boundary; activation depends on the approved customer configuration and applicable provider terms.

Request and resource flow

1. Create a volume with the required size and storage class.
2. Attach it to a compatible regional instance.
3. Format, mount and back it up within the workload’s operating procedure.

Configuration responsibilities

• Volume attachment and filesystem mounting are separate operations.
• Snapshots have their own retention and storage footprint.
• Capacity planning includes IOPS and throughput requirements.

Supported scope

Project-scoped volumes and compatible regional attachments. Backups and snapshots must be specified separately.

• Instance and volume must satisfy regional and attachment constraints.
• Deleting a VM must not silently delete retained customer data.
• A snapshot is not a substitute for an application-consistent backup.

Read your organization’s inventory

Open the Volumes workspace after signing in. The server resolves your active organization and its allowed OVHcloud resources. It does not accept a provider project ID from the browser.

The authenticated endpoint is GET /api/infrastructure/volumes. Supply an allowed region where needed, and a zero-based page for inventory pagination. Each response reports the requested region and the next page when one exists. Project-wide inventories may contain resources from more than one region; an unreported resource region is not inferred from a seed catalog.

The endpoint uses the Segal browser session. Demonstration sk_segal_ keys do not grant production access. Provider credentials stay server-side. A missing connection returns an explicit error rather than sample resources.

Submit a configuration

POST /api/infrastructure/volumes accepts requestId (UUID), operation: "create", acknowledgeCharges: true and a parameters object containing name, region, size (GB), type.

An organization owner or administrator must submit the operation from the same origin. The operator must first activate provisioning and confirm reseller terms. An atomic database operation record claims the request ID before the upstream mutation. Reusing that ID does not submit a second mutation; a conflicting payload is rejected.

An accepted response means the provider accepted the request, not that the resource is ready. If a response is lost, use GET /api/infrastructure/operations/REQUEST_UUID and ask engineering to reconcile the state. Do not issue a new request ID as an automatic retry.

Activation and service evidence

Follow provider setup before enabling live access. Demo resources, website imagery and documentation examples do not verify capacity, certification, latency or delivery. Confirm regional availability, contract scope, recovery ownership and final customer pricing before production use.

Read the product architecture. Upstream technical reference: Block Storage (reviewed 24 October 2026).