SAN Data Recovery Coventry

Half a dozen servers report the same fault within a minute of one another and none of them can see the volume they boot from. That is what a lost LUN looks like from above. Underneath it, the cause is far more often a mapping or a metadata fault than a shelf of dead drives, and the drives are usually in good order.

Enterprise arrays keep a description of themselves — which extents belong to which volume, where each one starts, what has been thin-provisioned and what has not. Damage there makes perfectly healthy disks present nothing at all. Rebuilding that description from the members is the substance of most of the work on this bench.

Backplanes, expanders and power supplies take groups of drives out together, and on the console that reads as a catastrophe. It usually is not. The disks themselves are commonly undamaged, and every one of them is imaged and the pool put back from the copies regardless of what the array said about them.

Dual-controller shelves are updated one head at a time so service continues, and an update that goes badly on the second head leaves the whole thing dark. None of the recovery depends on either controller working, because the layout is derived from the disks. The urge to fit a third head from somewhere is the risk here.

VMFS has its own structures and its own ways of breaking, and a datastore that will not mount is very often intact underneath the error. The virtual disks are pulled straight out of an image of the LUN. The layer above that, inside each guest, has a page to itself on this site.

Somebody was reclaiming space, or tidying, and a LUN that turned out to be in use went with it. What that writes is configuration rather than content, so a shelf taken out of service quickly is usually recoverable whole. What costs is the days it keeps serving other traffic afterwards.

Thin volumes advertise more capacity than physically exists, which works until the pool behind them fills. Writes then fail in ways the hosts were never written to expect, and file systems on top go inconsistent within minutes. It is recoverable, and it is one of the commoner reasons shared storage stops without a single disk having failed.

Snapshots refer back to blocks in earlier states, so a broken chain can make the current view unreadable while every block involved still exists somewhere on the disks. Putting the chain back together from the metadata is the job, and where it succeeds it usually returns the lot.

Where one copy of a block is referenced from a thousand places, damage to the index takes out far more than its own size suggests. Rebuilding those reference tables is the difference between a shelf full of readable disks and a shelf full of readable nonsense, and on a dedupe appliance it is the whole of the work.

Automatic tiering keeps busy blocks on flash and idle ones on spinning disks, so a volume lives on both at once. Lose the flash and what goes missing is a slice out of nearly every file rather than a list of files. Send both tiers, and mark which drives came from which.

A shelf that has disappeared from every host is not necessarily a shelf with a fault. Switch failures, address clashes and an undocumented network change all look identical from the server end. Ruling that out before anything is unplugged costs nothing and now and then ends the matter there.

Fabric changes remove a host's view of a volume without touching a byte of it. From the host it is indistinguishable from a dead array. Confirming the configuration first is worth the ten minutes, because it is easily the cheapest possible outcome and it is not a rare one.

Pulling a shelf out of a running pool leaves the array with half its members and a volume that no longer adds up. Plugging it back in afterwards does not always restore matters, because the array may have written in the interval. Both shelves travel, both labelled.

Layered arrangements need unpicking one storey at a time, and each storey has its own mapping to reconstruct. It is slower rather than harder. What it does need is a description on the booking form, because guessing at how the layers were stacked costs a day that need not be spent.

Years of service without a media scan leave every drive in a shelf with its own scatter of dead patches. Not one reads the whole way through, so the surviving ground on all of them is stitched into a single complete picture. That is a normal week here.

Reconstruction reads every remaining member at full rate for hours, and that is precisely the load a second marginal disk fails under. Once one has stalled, neither the array nor the person who owns it can give an accurate account of what state the pool is in. Halt it, then pull the power.

The LUN mounts, the datastore appears, and the virtual machines are broken. That is a second problem with its own tools. Virtual disk files are repaired one at a time after the volume underneath them is readable, and a guest whose file system was mid-write when the storage went is repaired inside as well.

Databases are held open and written to constantly, which makes them the first thing a storage failure ruins and one of the more repairable. Transaction logs frequently carry enough to bring the file forward, and older consistent copies survive in unallocated space more often than anybody expects.

Shelves from firms that were bought, merged or wound up turn up here regularly, along with kit that went out of support a decade ago. None of the reconstruction depends on a live contract or on the manufacturer still trading, because it works from the disks. Age is rarely the obstacle it looks like.

Self-encrypting drives and array-level encryption both put a key between the platters and the data. Get the key back off a head unit or out of a key manager and the volume opens as normal. Where it has truly gone, you hear so at the examination and not after an invoice.

A compromised host with a LUN attached passes the attack straight through to the storage, and the array itself is physically untouched afterwards. Where the compromised account was not privileged enough to delete snapshots, those come through untouched. This is ordinary array work at £500 + VAT and upward, not an investigation.

Disks that have spun without interruption for six or seven years often carry wear that only declares itself when they are stopped and started again. A relocation, or a long power cut, is regularly the last event before several members give up at once. The restart exposed it; the journey did not cause it.

Some platforms record their own position and cope. Others do not, and a shelf that has been reordered can end up rewriting its metadata to match. Take a photograph of every enclosure front before a drive moves, and write the slot on each one. The order can be reasoned out from parity afterwards, and there is no sense paying for that when a phone camera settles it.

Purpose-built backup targets are arrays with a deduplication layer over them, so a failure costs an organisation its storage and its safety net in the same event. Those are rebuilt here, and the reference tables usually are the job rather than a detail of it.

Put into service before the initial synchronisation completed, or interrupted during it, an array can carry parity that does not match its own data. Everything behaves until a member fails, at which point reconstruction produces convincing rubbish. This is identified during the assessment rather than found out halfway through.

One expander failing takes an entire enclosure out of view, which on the management screen is indistinguishable from total loss. The drives are typically fine. This is among the more encouraging findings on the page, and it is a common one on older shelves.

The person who built it left, the documentation left with them, and what remains is hardware nobody can describe. That is a routine arrival rather than a hopeless one. The arrangement comes out of the disks. Records make it quicker; their absence does not make it impossible.

Without a clustered file system, two hosts writing the same blocks damage each other's work quickly and thoroughly. Some of it is repairable from the structures that survive. How much depends entirely on how long both machines were live and how busy they were.

Second opinions on enterprise storage are ordinary here and a good share of them come good. Set out what was tried, in what order, and how each attempt ended, because that is what decides where this bench begins. Looking costs nothing on a fourth attempt just as it does on a first.

Not a fault, a priority. Warehousing and distribution across the parks off the M6 and M69 run on systems nobody dares restart, and when the storage under one goes, the bay stops with the paperwork. Mention it when you ring and the drives go to the front. Two working days for the free examination applies regardless.