Servers rarely fail politely. A disk drops out unnoticed in the spring, a second goes in the autumn, the rebuild stalls at forty per cent and the backup that should have covered all of it turns out to have stopped running in March. This page covers what actually fails on a server, why the controller is not needed to rebuild the array, how databases and virtual machines are handled, and what it costs.
Server and array recovery starts at £500 + VAT and rises with the member count. A single server disk on its own is £300 + VAT. The diagnostic costs nothing and closes two working days after the disks are booked in, and the figure after it is fixed in writing.
A server rarely fails in one clean way. By the time somebody rings, two or three things have gone wrong in sequence, and the order they happened in matters more than any of them individually.
Alert mail routed to an address that left the company, an amber light at the back of a rack nobody walks past, a monitoring agent that stopped reporting after an update. The array carries on degraded for weeks, and the fault only becomes visible when the next disk goes and the volume disappears.
The disks are perfectly healthy and the thing joining them is not. A dead card, a failed backplane, a battery-backed cache that lost its contents in a power cut, or a card replaced with a different model that cannot read the old layout. None of that needs the disks opening, and all of it needs the array reconstructing from the data.
Growing an array onto a new disk, changing its level or replacing a member all involve rewriting the whole layout while users are still working. Interrupt that halfway with a power cut or a second failure and the volume is left half in the old geometry and half in the new one. It is recoverable, and it is careful work.
The hardware is fine and the file will not mount. SQL data files caught by a hard shutdown, an Exchange store in a dirty state, a Hyper-V or VMware guest whose virtual disk is inconsistent. The recovery is a file system and application problem rather than a disk problem, and it is worked on images all the same.
Everything opens and nothing reads. On a file server the practical route is rarely decryption; it is the originals the malware deleted rather than overwrote, previous versions, and shares it never reached. Priced as ordinary media, not as forensic work: from £500 + VAT for the array.
A LUN removed from the wrong host, a volume formatted during a migration, a virtual disk deleted from a storage pool, an array re-created to test whether it would come back. Almost all of it is undoable if the server is powered off promptly and nothing new is written.
Nearly every call starts with the same sentence and it covers three unrelated situations. The first is a machine that will not power on or post: a power supply, a mainboard, memory. That is a hardware fault and the storage inside it is usually untouched, so the answer is often to move the disks into another chassis or simply to read them here. The second is a machine that runs perfectly and cannot find its storage, which means the controller, the backplane or the array. The third is a machine that boots, sees its array and presents a volume that will not mount, which is a file system or application problem sitting on top of hardware that is fine.
Working out which one you have takes ten minutes and changes everything about what happens next. It is worth doing before anybody starts pulling disks, because the actions that help in one case are precisely the actions that hurt in another.
Hardware controllers from Dell, HP, LSI and Adaptec keep their configuration in a reserved area on the member disks and, in most families, that configuration travels with the disks. Software arrays — Linux md, Windows dynamic disks, Storage Spaces, ZFS and the various NAS implementations — keep an equivalent superblock in the same sort of place. Either way, the layout is written down somewhere on the disks themselves, which is why an array can be reconstructed here without the card that built it.
What matters more than the brand is the level. A mirror gives you two independent copies and the friendliest recovery in the trade. A striped set with no parity has no redundancy at all, so a single member failure needs every disk imaged before anything can be assembled. Parity sets tolerate one absent disk, dual-parity sets tolerate two, and the nested sets used for databases behave like a stack of mirrors under a stripe. Each has its own arithmetic and its own worst day, and the diagnostic reports which one you actually have rather than which one the paperwork claims.
A hot spare is a disk sitting idle in the chassis waiting to be conscripted the moment a member fails. It is genuinely useful, because it starts the rebuild immediately instead of waiting for somebody to notice. It is also the reason a fair number of arrays arrive here in a worse state than they needed to be, since an automatic rebuild begins that heavy end-to-end read of every surviving member without a human being deciding whether that is wise, and it may begin at three in the morning on a set of disks that are all the same age.
The same warning applies to a spare that has been sitting unpowered in a warm rack for four years. It has aged. It is not a fresh disk, and a proportion of them fail during the rebuild they were bought for.
Recovering the files is often the easy half. A SQL data file pulled back from a formatted volume is only useful if its log file comes with it and the two are consistent; an Exchange store recovered in a dirty shutdown state has to be brought to a clean one before anything will mount it; a virtual machine is a file that contains an entire file system of its own, so the guest has to be worked as a second recovery inside the first. All of that is normal work here, and it is the reason server jobs take longer than a single laptop drive.
Where a guest sits on a failed array, you have two problems stacked: the array has to be reconstructed correctly before the virtual disk is even readable, and only then can the file system inside it be repaired. Getting the array geometry slightly wrong produces a virtual disk that opens and is full of rubbish, which is why the parameters are proved against the data rather than trusted from the controller.
The disks travel and the chassis stays with you. Pull the member drives, write the bay number on each one in the order they sat in the front of the unit, and photograph the front of the chassis before anything comes out. Leave the controller card, the rails, the caddies where practical, the power supplies and the cabling behind — none of them are used at this end. If the caddies will not release without tools, send the disks in the caddies rather than forcing them; that is the one exception worth making.
Tell us what you know, on paper, in the box. The controller model, the array level if you know it, which disk failed first, whether a rebuild was attempted and how far it got, and what the volume held. Two lines of that history routinely save hours of work, and hours of work on a multi-disk job are the difference between a Tuesday and a Thursday.
Post it tracked and insured, or bring it in. The bench takes drop-offs at Compass House, Vision Park, Chivers Way, Cambridge CB24 9AD, Mon–Fri 9:00am–5:30pm. From Leicester that is about 70 miles, the M1 south to J19 and then east on the A14, roughly an hour and a half, and the unit sits two minutes off Junction 32. There is no office in Leicester and nobody collects, which is worth knowing before you plan your morning around it.
No lab in this country can tell you on the phone how long a server job will take, and anybody who does is guessing. What is real: the diagnostic is free, it closes two working days after the disks are booked in, and it produces a fixed written figure and a realistic date at the same time. A job can be flagged as urgent before the parcel even lands, which pulls it to the front of the diagnostic queue rather than the back. Single drives finish in two to four working days once authorised. Arrays take longer, because five members mean five images.
What is not real is a twenty-four hour hotline, an engineer arriving at your rack, or a same-day promise made before anyone has seen the disks. This is a bench operation with published prices, working Mon–Fri 9:00am–5:30pm, and it is better to say so than to have you plan a recovery around a service that does not exist.
Servers and arrays start at £500 + VAT and go up with the member count. A single server disk outside an array is £300 + VAT. A recorder drive out of a CCTV system is £400 + VAT, as is an encrypted volume where the key can be supplied. Forensic work is £800 + VAT with a written report and £400 + VAT for a binary image with deleted-file extraction and no report — that second figure sits at the same point as the recorder band rather than being a tier of its own. Ransomware, on a server or anywhere else, is priced as ordinary media.
Logical work — deleted volumes, corrupt file systems, failed arrays with healthy members, ransomware — carries no fix, no fee. The exclusions are electronic failure, mechanical failure, chip-level work, DVR jobs and forensic jobs, and physical work takes 50 per cent of the quoted figure upfront. Nothing starts without your authorisation, and the figure you authorise is the figure you pay.
Accountancy and legal practices in the city centre, manufacturers around Loughborough and Coalville, logistics operations at Magna Park and the estates along the M69, design and print firms in the Cultural Quarter, GP practices, schools and academy trusts across the county. The common thread is not the sector. It is that the server was doing its job so reliably that nobody had checked the backup in eighteen months, and the restore turned out to be the second thing that failed.
Most server jobs arrive having been made harder by an hour of well-meant troubleshooting. Ring first, then pull the disks in bay order.
Multi-disk jobs travel as a set of bare drives in one box, and they travel by post far more often than by car. Tracked and insured is the sensible choice for a parcel holding four disks of company data, and something handed over in Leicester before the last collection is normally logged in at Cambridge the next working day.
The general rule is the drive travels and the machine stays behind — out of the laptop, out of the tower, out of the iMac, out of the recorder under the counter. This bench does not dismantle equipment, and a repair shop will do it while you wait. Three things are the other way round, and getting them wrong costs you the recovery: an external drive stays sealed in its own case, a NAS comes as a complete unit, and a WD My Passport or My Book travels whole with its cable, because on those the encryption key is held on the bridge board rather than on the disk — separate the two and the data becomes unreadable even to us. A Fusion Mac needs both of its drives, each labelled. The one thing nobody can work round is flash soldered onto the mainboard, as on Apple Silicon machines: if it will not come off, there is nothing to post.
↓ Print the shipping & booking-in form (PDF)
Address it to Cambridge Data Recovery. It is about seventy miles from Leicester if you fancy driving it — M1 south to Junction 19, then the A14 east — and the lab is two minutes off Junction 32 with parking at the door. Posting costs you a stamp and a day instead. Whichever you choose, you hear from us the moment it is booked in, and the free diagnostic closes two working days after that.
Not certain what belongs in the box? Ring 0800 689 0668 before you tape it up, or let the free online diagnostic ask the questions for you.