Panasas ActiveStor Data Recovery
Panasas ActiveStor is a parallel file system appliance built for high-performance computing, combining ActiveStor Director (ASD) and storage nodes running PanFS with the DirectFlow protocol for direct, parallel client access. Because PanFS distributes files as objects across many storage devices using per-file protection, recovery generally has to work at the level of the object-based storage devices and blade sets rather than individual drives.
Platform Lineage and Naming
Panasas introduced ActiveStor as a scale-out storage appliance purpose-built for HPC workloads, progressing through the ActiveStor 11, 12, 14, 16, 18 and 20 generations before introducing ActiveStor Ultra with denser, higher-performance hardware. Across generations, the underlying PanFS parallel file system and DirectFlow client protocol have remained the architectural constant.
ActiveStor systems are built from ASD-100 director blades, which manage metadata and system services, alongside storage node blades that hold data as objects; together these blades form bladesets that PanFS organises into one or more managed volumes.
- ActiveStor 11, 12, 14, 16, 18, 20
- ActiveStor Ultra
- PanFS (parallel file system)
- DirectFlow protocol
- ASD-100 director blades
- Object-based storage devices (OSDs)
Generations and Models We Evaluate
| Generation / family | Models |
|---|---|
| ActiveStor generations | ActiveStor 11, 12, 14, 16, 18, 20 |
| Later generation | ActiveStor Ultra |
| Components | ASD-100 director blades, storage node blades |
Architecture and Data Layout
PanFS stores each file as a set of objects distributed across multiple object-based storage devices (OSDs), rather than as a contiguous block range on a single volume, with per-file RAID or erasure coding applied individually to each file according to its size and importance. This per-file approach means protection level can vary file by file within the same bladeset.
DirectFlow is the client-side protocol that lets compute nodes talk directly and in parallel to the relevant storage nodes for a given file, bypassing a single metadata bottleneck for data transfer, while ASD-100 director blades handle metadata, namespace and system management functions.
Storage node blades and director blades are organised into bladesets, which PanFS uses as the unit of capacity and fault-domain management; reconstructing data after a serious fault generally requires understanding which OSDs and blades a given file's objects and parity were spread across.
Protocols and formats: DirectFlow (Panasas parallel client protocol), NFS, SMB/CIFS (gateway access)
- Per-file RAID/erasure coding means individual files can have different protection levels within the same bladeset, unlike a single array-wide RAID scheme.
- Object-based storage devices hold file objects rather than raw blocks, requiring PanFS-aware reconstruction rather than generic block-level RAID recovery.
Failure Scenarios
Logical failures
- Deleted files or directories from the PanFS namespace
- Metadata corruption on ASD-100 director blades
- Failed PanFS software upgrade
- Bladeset or volume configuration errors
- Client-side corruption written through DirectFlow to otherwise healthy storage
Hardware failures
- Multiple OSD or storage blade failures exceeding a given file's per-file protection tolerance
- ASD-100 director blade failure affecting metadata availability
- Bladeset interconnect or chassis faults
- Power-loss events across multiple blades simultaneously
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
Why can't PanFS be recovered like a normal RAID array?
PanFS stores files as objects spread across many object-based storage devices with per-file protection, so reconstruction needs to work at the file/object level and understand which OSDs and blades were involved, rather than rebuilding a single fixed RAID set.
Does losing a director blade mean data is lost?
Not necessarily — director blades primarily manage metadata and namespace services, so their loss affects access and file lookups, but recovery depends on whether the metadata itself can be reconstructed or was otherwise protected.
Can different files have different protection levels on the same system?
Yes. PanFS applies per-file RAID or erasure coding individually, so it is normal for protection level to vary between files even within the same bladeset.