Scality RING Data Recovery
Scality RING is a distributed object storage platform built around a peer-to-peer ring architecture, where object locations are resolved through a distributed hash table rather than a central index. Recovery work typically focuses on keyspace and ring health, the configured erasure coding or replication class of service for affected data, and the connector layer through which data is accessed.
Platform Lineage and Naming
Scality developed RING as a scale-out object storage platform using a peer-to-peer ring topology inspired by distributed hash table designs, allowing nodes to be added incrementally while data location is resolved algorithmically rather than through a centralised metadata server, reducing single points of failure at that layer.
Scality later introduced ARTESCA, a more lightweight, Kubernetes-native object storage product aimed at edge and smaller-footprint deployments, positioned alongside RING for larger-scale environments; the two share S3 API compatibility but differ in underlying architecture and intended deployment scale.
- Scality RING — the core scale-out object storage platform
- Scality ARTESCA — Scality's lighter-weight, Kubernetes-native object storage product
- sproxyd — Scality's internal object access protocol
- S3 Connector — Scality's S3-compatible access layer for RING
Generations and Models We Evaluate
| Generation / family | Models |
|---|---|
| Core platform | Scality RING scale-out object storage clusters |
| Related product | Scality ARTESCA (separate, lighter-weight architecture) |
| Access layers | sproxyd (native), CDMI, S3 Connector |
Architecture and Data Layout
RING nodes participate in a distributed hash table that maps object keys to storage locations across the ring, allowing the cluster to route requests to the correct node(s) without a centralised lookup service; this keyspace design underpins how RING scales and rebalances as nodes are added or removed.
Data protection within RING is provided through a combination of the ARC (advanced resiliency and chunking, Scality's erasure coding scheme) and configurable replication, both exposed to administrators as classes of service that trade capacity efficiency for fault tolerance depending on the data's importance.
Client access historically went through sproxyd, Scality's native object access protocol, with CDMI support for standards-based access; modern deployments predominantly use the S3 Connector, which translates S3 API calls into RING's internal object operations.
Protocols and formats: S3 (via S3 Connector), sproxyd (native protocol), CDMI, NFS/SMB via optional gateway components
- ARC erasure coding splits objects into data and parity fragments distributed across nodes, while replication-based classes of service instead keep multiple full copies; the class of service assigned to a bucket or object determines which scheme applies and how many node or drive failures it tolerates.
- The distributed hash table keyspace determines physical placement algorithmically; keyspace inconsistency after a disruptive ring change can affect the cluster's ability to locate otherwise intact object fragments.
Failure Scenarios
Logical failures
- Distributed hash table / keyspace inconsistency following a disruptive ring topology change
- Accidental bucket or object deletion via the S3 Connector or native API
- Class of service misconfiguration leaving data under-protected relative to actual node/drive failure risk
- Failed RING software upgrade affecting node-to-node keyspace communication
Hardware failures
- Multiple node or drive failures exceeding the configured ARC erasure coding or replication class of service
- Network partition disrupting distributed hash table communication between nodes
- Concentrated hardware failures during an active ring rebalance or node addition
What Not To Do Before an Evaluation
- Do not run rebuilds, reconstructions or re-initialisations against an array that has already lost more drives than its protection level allows.
- Do not recreate pools, aggregates, disk groups, storage pools or clusters — these operations write new metadata over the structures a recovery needs.
- Do not swap drives between slots, and do not reorder shelves. Record the original slot and shelf positions before removing anything.
- Do not run file-system repair tools against production volumes before the underlying storage layer has been evaluated.
- Do not restore a backup or replication set over the affected volumes until the recovery scope has been assessed.
- Do not eradicate deleted volumes or empty recycle/destroyed states on platforms that hold deleted data for a retention window.
Our Evaluation and Recovery Process
- Intake and platform identification — array model, generation, firmware, protection layout and the sequence of events that led to the failure.
- Read-only evaluation of the media and array structures, including assessment of drive health and the extent of any physical damage.
- Forensic imaging of all contributing media, with cleanroom work where drives require it. Originals are preserved unaltered.
- Reconstruction of the storage layer — pools, aggregates, parity groups, chunklets, extent groups or objects — from the images.
- Extraction of the layers above: file systems, virtual machines, databases, mailboxes and shares.
- Verification against a file list and customer-nominated critical data, followed by secure return on encrypted media.
Frequently Asked Questions
Can objects be recovered if some RING nodes are lost?
It depends on the class of service (erasure coding or replication) assigned to the affected data and how many nodes were lost relative to that configuration; an evaluation of the ring's remaining fragments or copies is needed.
Is Scality ARTESCA recovery the same as RING recovery?
No. ARTESCA uses a different, more lightweight architecture from RING's peer-to-peer distributed hash table design, so the two require separate evaluation approaches despite sharing S3 compatibility.
Does the access method (S3 Connector vs sproxyd) affect recoverability?
The access protocol mainly determines how clients read and write objects; recoverability depends more on the underlying keyspace and class-of-service state than on which access layer was used.