IBM Storage Scale and GPFS Data Recovery
Storage Scale — previously Spectrum Scale, and GPFS before that — is IBM's parallel file system, used for HPC, research computing, media workflows and analytics. Cases here are file-system-level: a lost file system descriptor, NSDs that went away with their array, or a cluster that will not reach quorum.
Platform Lineage and Naming
GPFS (General Parallel File System) originated in IBM Research in the 1990s and became the backbone of many of the world's largest HPC installations. It was rebranded IBM Spectrum Scale in 2015 and IBM Storage Scale in 2023.
It is deployed both as software over third-party block storage and as IBM Elastic Storage Server / Elastic Storage System (ESS) building blocks, where IBM supplies POWER servers, enclosures and GPFS Native RAID (declustered RAID) as an integrated unit.
- GPFS — General Parallel File System
- IBM Spectrum Scale, IBM Storage Scale
- ESS — Elastic Storage Server / Elastic Storage System
- NSD — Network Shared Disk
- GNR — GPFS Native RAID / declustered RAID (on ESS)
Generations and Models We Evaluate
- Software deployments: Storage Scale on x86 and POWER Linux, AIX and Windows nodes over SAN or SAS-attached LUNs
- ESS building blocks: ESS 3000, ESS 3200, ESS 3500, ESS 5000, GL/GS-series models
- Structures: NSDs, failure groups, storage pools, filesets, file system descriptor (FSDesc) quorum
- Back-end storage: IBM FlashSystem, DS series, and third-party arrays presenting LUNs as NSDs
Architecture and Data Layout
A Storage Scale file system is built from NSDs — block devices contributed by servers or arrays — grouped into failure groups and storage pools. Metadata may live on dedicated NSDs, and a file system descriptor replicated across a quorum of NSDs describes the whole file system.
Data and metadata can be replicated across failure groups (replication factor 1, 2 or 3). Whether a recovery is possible after losing NSDs depends heavily on the replication settings and which failure groups were lost.
On ESS, GPFS Native RAID declusters parity across all drives in an enclosure, so reconstruction requires interpreting GNR structures rather than conventional RAID stripes.
- Data and metadata replication is per storage pool and per fileset; a file system with replication 1 has no redundancy at the GPFS layer and depends entirely on the underlying array.
- GPFS Native RAID on ESS uses 8+2p / 8+3p declustered arrays with distributed spare space across every drive in the enclosure.
Logical Failures
- File system descriptor quorum lost after NSDs were removed
- Accidental mmdelfs, mmdeldisk or mmcrfs run over a live file system
- NSDs deleted or reassigned on the back-end array
- Failed Storage Scale upgrade or node reinstall wiping cluster configuration
- Metadata NSD loss where metadata replication was set to 1
- Fileset or snapshot deletion
- AFM cache/home relationship resynchronised over current data
Hardware Failures
- Back-end array failure taking out an entire failure group
- Multiple drive failures inside an ESS declustered array
- Enclosure, SAS chain or expander failures on ESS building blocks
- Server node failures causing cluster quorum loss
- Fabric failures isolating NSD servers from their LUNs
Encryption and Keys
Storage Scale supports file-level encryption with an external key server (IBM Guardium Key Lifecycle Manager or KMIP), and the underlying arrays may add their own encryption. Both sets of keys must be available for encrypted filesets to be readable.
Frequently Asked Questions
We lost a whole storage array holding several NSDs. Can the file system be recovered?
It depends on replication. With replication 2 across failure groups, the surviving group may hold a full copy; with replication 1, recovery depends on rebuilding the lost NSDs from the array's own drives.
Someone ran mmcrfs over an existing file system. Anything left?
Often yes — creating a file system writes structures but does not overwrite the bulk of the data area. Stop all cluster activity immediately and have the NSDs evaluated.
Do you work on ESS hardware directly?
ESS enclosures use GPFS Native RAID, so reconstruction works from images of the enclosure drives combined with the cluster's GNR configuration. That is established during the evaluation.
Related
- IBM FlashSystem — /services/enterprise-storage/ibm/flashsystem
- IBM Data Recovery Services — /services/make/data-recovery-from-ibm
- Unix & Linux Data Recovery — /services/data-recovery-services/file-systems/unix-linux-data-recovery-services
- Enterprise Storage Data Recovery — /services/enterprise-storage-data-recovery