IBM Storage Virtualize and SAN Volume Controller (SVC) Data Recovery
SAN Volume Controller sits in front of other vendors' arrays and virtualises them into one pool, so when SVC configuration is lost the back-end arrays may be perfectly healthy while every volume is unreadable. This page covers the virtualisation layer itself — the same Spectrum Virtualize software that runs inside FlashSystem and Storwize.
Platform Lineage and Naming
IBM launched SAN Volume Controller in 2003 as an in-band storage virtualisation appliance. Its software later became the operating system for Storwize and then FlashSystem, and was branded Spectrum Virtualize before becoming IBM Storage Virtualize.
SVC engine generations include the CG8, DH8, SV1, SV2, SV3 and current models. The same volume, pool and Data Reduction Pool structures appear across SVC, Storwize and FlashSystem, so recovery methodology carries across all three.
- SVC — SAN Volume Controller
- IBM Spectrum Virtualize / IBM Storage Virtualize
- Storage Virtualize for Public Cloud
- mdisk (back-end LUN), mdiskgrp (pool), vdisk (volume)
- HyperSwap and Enhanced Stretched Cluster topologies
Generations and Models We Evaluate
- SVC engines: 2145-CG8, 2145-DH8, 2145-SV1, 2145-SV2, 2145-SV3, SA2 / SV3 hardware
- Same software on arrays: FlashSystem 5000/7000/9000, Storwize V5000/V7000
- Virtualised back ends: IBM, Dell EMC, HPE, Hitachi, NetApp, Pure and other supported arrays
- Structures: mdisks, storage pools, child pools, vdisks, Data Reduction Pools, FlashCopy maps
Architecture and Data Layout
SVC clusters present virtual volumes to hosts while consuming LUNs (mdisks) from back-end arrays. The mapping between a vdisk's extents and the mdisks that hold them lives in the SVC cluster configuration and in on-disk metadata written into the managed mdisks.
Data Reduction Pools add a further log-structured layer with compression, deduplication and a directory that maps volume addresses to physical locations inside the pool. DRP metadata damage is one of the most common causes of total volume inaccessibility on this platform.
Recovery is performed by taking images of the back-end LUNs or the drives behind them, rebuilding the extent and DRP mapping, and reassembling the virtual volumes before recovering the host file systems inside them.
- SVC does not apply RAID itself in classic configurations — protection comes from the back-end arrays, or from DRAID when SVC manages internal drives on FlashSystem hardware.
- Volume mirroring (two copies in different pools) and stretched clusters mean a surviving copy is sometimes the fastest recovery source; establishing which copy is current is part of the evaluation.
Logical Failures
- Cluster configuration lost — back-end arrays healthy but volumes unmapped
- T3 / T4 recovery run incorrectly, or a cluster recreated over managed mdisks
- Data Reduction Pool metadata corruption or out-of-space condition
- Deleted vdisks, pools or FlashCopy relationships
- mdisks removed, unmapped or reassigned on the back-end array
- Failed IBM Storage Virtualize (Spectrum Virtualize) code upgrade
- Stale volume copy chosen after a split-brain in a stretched cluster
Hardware Failures
- Loss of both nodes in an I/O group
- Node boot drive or battery failure preventing cache destage
- Back-end array failure removing mdisks from the pool
- SAN fabric failure isolating nodes from back-end storage
- Simultaneous power loss across the cluster with dirty cache
Encryption and Keys
IBM Storage Virtualize supports software encryption at the pool level with USB key files or an external key server. Those keys are required — an encrypted pool cannot be reconstructed from the back-end LUNs alone.
Frequently Asked Questions
Our back-end arrays are fine but SVC lost its configuration. Is data recoverable?
Frequently yes. The extent mapping is also written into the managed mdisks, so reconstruction from back-end LUN images is often possible even when the cluster configuration is gone.
Should we recreate the cluster to get back online?
Recreating a cluster over managed mdisks can overwrite the metadata a recovery would use. Preserve the current state and have it evaluated first.
Does this apply to FlashSystem and Storwize too?
Yes — they run the same software. Use this page for virtualisation-layer and DRP problems; use the hardware pages for drive, canister and enclosure failures.
Related
- IBM FlashSystem — /services/enterprise-storage/ibm/flashsystem
- IBM Storwize Data Recovery — /services/ibm-storwize-data-recovery-services
- IBM Data Recovery Services — /services/make/data-recovery-from-ibm
- SAN Data Recovery — /services/other-data-recovery-services/san-recovery