SAN Data Recovery Norwich

Enterprise shelves shed drives by the handful rather than one at a time. Each drive has individual repair and imaging completed prior to group arithmetic resuming again.

The block device your servers were relying upon has gone. It will be rebuilt from the bottom up: RAID groups must be rebuilt prior to pool metadata, because doing so out of order does not prove anything.

The map between blocks and volumes has failed. It will be reconstructed using the raw structures on disk which it had been describing all along, and which are still there.

The management plane died during a flash while the data remained completely still behind it. Work proceeds directly against the disks and ignores the controller entirely.

Pairs fail at the same time much more readily than the datasheet suggested. Recovery goes drive-direct, which has the advantage of never having read the datasheet.

The virtualisation layer collapses first and takes everything that was in view with it. We break the datastores apart and each virtual disk is extracted and repaired individually.

Seconds to do and days to regret. Whatever survives depends on whatever has been written since; thus, locking down the platform improves the maths straight away.

If there is one broken link in the chain, it brings down all the volumes that depended upon it. The chain is rebuilt at image level, one link at a time.

If promised capacity exceeds real capacity, then every thin volume fed by the pool becomes corrupted at the moment it runs out. Rebuilt from the images, with the accounts able to stand up to inspection afterwards.

If cache batteries expire and a single outage occurs, parity will conflict with data across an entire group. However, at the image level, resolving the conflict will be affordable instead of destructive.

NetApp aggregates and EMC pools lose track of where their volumes reside. The rebuild climbs up from the RAID groups until they can locate them again.

The 520, 524 and 528 byte formats are designed to limit ordinary tooling. The lab fabric used here reads these natively rather than using improvised adapters.

HPE's small business staple arrives with its vDisk structures torn. A rebuild we've gone over in this workshop so many times now it has become very boring.

V3700 and V5000 units drop extents after a power event. The extents are remapped from the drives one at a time, until the volume is whole.

The box lost its target definition, and the volume behind it rarely dies with it. It is extracted and presented again over plumbing that can be trusted.

All references to all shared blocks fail at once when the index is corrupted. These are rebuilt until the shared blocks resolve properly again.

Both controllers were writing independently, as the handover was botched; therefore, there are now two versions of the same events. These are reconciled at image level, and both are timestamped and audited.

Arrays running beyond end of support fail with no official route left. The lab route does not have an expiry date, because data has never read a support contract.

Replacement drives with different firmware versions can misbehave in older groups, in ways which look like failed drives. Stabilise, image and then rebuild, in that order.

Masking or fabric edits blind all the hosts at once while the underlying volumes remain healthy. The mapping is rebuilt and the owners are given access again.

Drives from the same lot hitting an hours-counter firmware defect typically fail within days of one another, which is a known and embarrassing problem across the storage industry, and should not be confused with bad luck. The surviving drives are imaged quickly before they join in.

Nearline SATA drives connected through SAS interposer boards fail much more frequently at the adapter than at the drive itself. As such, we simply bypass the adapters and image the bare drives.

When the fast tier fails, every tiered volume loses the blocks it was using the most. The cold tiers do nothing to make sense of this on their own. Instead, the cold tiers together with the tiering metadata rebuild whatever the fast layer was holding.

A zoning slip without a clustered file system creates interleaved corruption from both sides. The two write histories are separated from images, operation by operation.

Service processor dead, credentials gone along with a contractor. The array will not communicate, but the drives have no such reservations, so data is extracted from them without a password.

The amount of space set aside for snapshots is limited. Most systems deal with this by automatically deleting the oldest snapshots when the space runs out. In many cases, the restore point somebody was counting on has been deleted before anyone knew about it. What is left is carved from unallocated space on the imaged member disks.

A failover test, a mislabelled site, a relationship resumed in the wrong direction, and the healthy copy is overwritten with the stale one at wire speed. The overwritten side will be imaged and the older structures recovered from underneath, and the sooner this is stopped, the better it will work.

Arrays that encrypt data at rest store their keys in either the controller or on a key manager. When you lose both, your drives are readable but meaningless. This is identified during the diagnostic and said openly; there's simply no honest way around this fact.

Shelves are daisy chained together, so if a cable fails, an expander fails, or a shelf is powered up in the wrong order, a whole tier of disks can disappear at once. It looks like catastrophic loss, but in many cases it is actually a cabling issue. Establishing which comes before anybody starts rebuilding anything.

A new server is given several volumes and a well-meaning administrator initialises the one that looked spare. A quick format leaves most of the original volume in place, as long as the host is disconnected before it starts writing to the space it thinks is now its own.