Open, and looking at it costs nothing · 9am–5:30pm, Mon to Fri Ring instead, it is quicker: 0115 8220606
NDR Nottingham Data Recovery 0115 8220606 Get my quote
NDR / Devices and media / SQL Server database recovery

Specialist · SQL Server on arrays that have failed

SQL Server recovery, Nottingham. A SUSPECT database is usually a storage fault wearing a database error.

Servers and RAID sets start at £500 + VAT. There is no cost for the assessment, so you'll get your figure written down without spending a single chargeable minute. Underneath, almost all SQL jobs here take a single form: an .mdf with its .ldf, on an array that has been quietly short of a member for weeks; a replacement was added and a rebuild began, and while the rebuild ran a second carrier went amber. All that appears at the top is a database that cannot attach, or one sitting in SUSPECT or RECOVERY PENDING, and this is three levels above the real problem. So each disk is cloned read-only separately; from those images we recover how the controller arranged the set, then build the volume above them, and the database files are copied off and opened on copies. Sets arrive from Nottingham, Derby, Leicester, Lincoln, Loughborough and Newark-on-Trent.

Only pay if we recover your data, on most jobs Free diagnosis first, then a single price, in writing Parcels come in from Derby, Lincoln and Loughborough

Ask an engineer and the first look is free
0115 8220606

What a SQL Server symptom points to.

Not yours? Open the fault finder →
What is happeningWhat usually causes itWhat that means for you
The database will not attach and reads as SUSPECTPages the array can no longer deliver cleanly. This is not a fault within SQL ServerStop the instance and cut the power
A rebuild started and then halted part-wayThere was already one member down when a second started to failTake the chassis off power
The controller reports a foreign configurationIt has lost its own description of the set after a power cutDo not import it; ring us first
Only the .mdf remains, while the .ldf is missingEither a log file was removed, or it sat on a volume that did not come backSend both volumes if either survives
Plugged into a PC, a disk reads as if nothing exists on itA SAS member will not connect to a desktop SATA port. A disk taken from a storage array may be formatted at 520 bytes per sector, and ordinary controllers refuse that formattingInterface or formatting, not a fault. Send them
The full backup restores, but the log chain will notA gap in the chain, which only shows up on the day it is neededSend the array as well as the backup disk
How to pack and post it: first get a quote, by phone on 0115 8220606 or using the quote form. Then pack the drives securely so they do not shift in transit, and value the parcel at what the data is worth to you, not what the hardware cost. Choose a tracked service to send it to our intake lab in Manchester. Alternatively, you may drop it off at the lab Monday to Friday, 9am to 5:30pm (no appointment necessary). We pay for postage back to you. Would you like an engineer to walk you through the packing? Call us before sealing the box. Everything is set out on our packing and postage guide.

Where a SQL Server job actually stops.

The .mdf, the .ndf and the .ldfA SQL Server database consists of a data file, sometimes several, plus a log file alongside, and the whole group has to agree with itself. The log is what makes the data file usable again after an "unclean" shutdown, so a job with the .ldf intact runs quite differently from one without it. Please send both the data files and the log file where both exist, and say which disks each was living on.
SUSPECT, RECOVERY PENDING and the restThe state a database comes up in describes what SQL Server could not read. It is not a diagnosis. RECOVERY PENDING generally means a file could not be found or opened at all, while SUSPECT means a file was opened but SQL Server could not rely on it. Either way, the cause lies beneath the file system, which is where this job begins rather than ends.
Controllers, and 520-byte membersEach RAID controller keeps its own description of a set on the disks themselves (the order of the members, how wide the stripe is, how parity moves among the disks and the point at which data starts), so a volume can be reassembled from images at this end, with no RAID card and no chassis. Disks from storage arrays (NetApp, EMC, HPE 3PAR) are often formatted at 520 or 528 bytes per sector rather than the usual 512. The extra bytes carry an integrity checksum, which explains why an ordinary controller will not read them. The issue is formatting, not physical damage.
What we never doNo rebuild is started, nothing is imported, no configuration is cleared, no member disk is forced back online, and no repair is run against any database you send us. Each of these actions is a write, and each write removes an option. Your members are read once and set aside; the repairs happen against images, where a wrong turn costs an afternoon at this end and costs you nothing.

From the parcel arriving to the files going home.

01

Booked in the day it arrives, and the first look is on us Free

Your case number is assigned when the item is received. Then an engineer works out what went wrong (no charge). At this point, you receive a basic summary of which parts are recoverable and which are not. You also receive a single written quote for the price of the recovery. Accept the quoted price or turn it down, and there is no obligation to pay anything.

The first look is freeOne fixed figure, in writingNo charge at this point
02

Copies before the array is asked anything

With a write blocker in place, every member disk is fully cloned before the set is even put together: both the healthy disks and whichever one the controller gave up on. Troublesome areas are copied in short runs and left until everything else is safely down. Not a single byte ever goes back onto the drives you posted.

Each member imaged firstNothing goes back onto your disks
03

The volume rebuilt from the members themselves

Since a controller stores its description of a set on the disks and not on itself, neither the card nor the enclosure needs to travel. How the members were ordered, how wide the stripe was, how parity moved across them and the point at which data actually starts are all worked out from the images, compared with the file system above, and only then is the volume built over these copies and brought up read-only.

The set read back off copiesOpened as read-only
04

The database files, and then the database

With the volume up, the .mdf, any .ndf files and the .ldf are taken off and worked on as copies. If the log is good, the database is attached and checked; if it is not, the data file is used on its own and the tables pulled from it. Any damage found is identified as such, page by page, instead of delivering a file that may open fine now but give trouble later.

Database files taken as copiesDamage named, page by page
05

The file list comes before the bill

A complete file list will be provided before any invoicing. Simply say "yes" or "no" to what we found: yes means it is billed, no means it is not, and in most cases you only pay if we recover your data. What we find is posted to you on media purchased specifically for your case, at no additional cost to you. We consider the process complete once you have opened those files yourself on your own computer.

Nothing is charged until you agree the figureNew media, bought in for your jobWe pay to send it home

What comes in most often

  • SUSPECT is a storage message, not a database one: SQL Server uses SUSPECT when the engine cannot depend on what it reads back. Usually the cause sits below the level of the file system rather than within it. Working on the database while the array is still unresolved fixes nothing and eats into what margin is left.
  • A rebuild is the heaviest load placed on any group of drives. A rebuild requires every surviving drive to read every sector. Those drives came from the same batch and were installed at the same time, carrying the same hours. Thus a disk failing during a rebuild is not coincidence. It is simply the weakest survivor taking on the greatest burden of its lifetime.
  • Do not detach a database that won't come up: of everything people do on a bad day, forcing a SUSPECT database into EMERGENCY mode (SQL Server doesn't allow detachment otherwise) and then detaching it is the surest way to turn a workable job into an awkward one, since it removes the state SQL Server needs to attach it again. Leave it alone. Stop the instance, and let the array be copied first.
  • The volume holding the log is part of the job: many installations keep the .ldf on different disks from the .mdf, and here the two are read together. Send both. Also tell us anything already run: a rebuild, an import, a configuration cleared, a member forced back online, DBCC with repair allowed. No other piece of information does as much to set the order of the work.

What decides one of these jobs: how much of each member will still read; whether the virtual disk was re-created after it failed; how long a rebuild ran; whether repairs were allowed to discard pages; and whether the volume was encrypted. Turn off a server with all disks still in place, and the options stay wide. Fit a replacement disk, run a rebuild, import a configuration and restart it for two nights, and the options shrink substantially, though you are still told which tables sit in the gaps before there is anything to pay. Encryption requires a key from you. We specialise in storage recovery and do not take phones or tablets. The starting price for servers and RAID sets is £500 + VAT, given in writing after the free assessment. In most cases you only pay if we recover your data.

One of these, from start to finish.

NG · NTG-2026-2007ON THE LOG ✓

A rebuild that halted, and a SQL database that would not attach

A food manufacturing company in Leicester kept its batch and QA records on a six-bay server that had silently been running a member short since the summer. When a second carrier went amber, a spare was installed and the rebuild was allowed to run; the rebuild stopped mid-run, the virtual disk went offline, and on the next restart the job database showed up as SUSPECT. That same afternoon the chassis was taken off power, and every drive arrived here with a bay number on its carrier. Copies of the two weaker members were taken first, one of them over four passes, while the remaining disks were read end to end. The controller's own account of the set was taken from the images, the volume was assembled above them, and the .mdf and .ldf files were taken off as copies. Both databases attached, and both were examined here before anything went home.

The two weak members copied before the rest2 databases attached on the copies

What helps, and what does damage.

Worth doing first

  • Stop the SQL Server service, then cut the power
  • Number each carrier before you pull it out
  • Send each disk, the one marked failed included
  • Tell us what has been run against the array and the database

What makes it harder

  • Starting or restarting a rebuild while a member is missing
  • Importing a foreign configuration, or clearing it
  • Detaching a database that will not come up
  • Running DBCC with repair allowed to force it online

Answers before you spend anything.

SQL Server says the database is SUSPECT. Has it gone?

Almost never, and the message is referring to storage rather than your database. SUSPECT means the engine opened the files, read something it did not trust, and stopped rather than carry on guessing; on an array with a member missing, this points to a problem several layers below SQL Server. Two things then decide how the job goes. First, do not force it into EMERGENCY mode and detach it (SQL Server will not detach a SUSPECT database any other way), as a database detached in that state is far more difficult to attach again. Second, do not run a repair that allows pages to be discarded. Stop the instance, pull the power from the chassis, and let the disks be copied first.

A rebuild halted part-way. What happens now?

Stop there, before the hardware is asked for anything more. Every surviving member goes through a full sector read during a rebuild, and these are the most worn items in the room. The weakest member typically fails first under that load. So if you let the rebuild carry on, you have a set with two members missing, with copies still to take from each. So: power off the chassis, leave the carriers in their bays, and make images before trying anything else.

Do you want the server, or only the disks?

The disks. Get a quote first, by phone on 0115 8220606 or with our quote form. Remove each member as a bare drive and mark its bay number on it; carriers, chassis and card can stay in place, because how the set was configured is worked out from the images, not from your hardware. If your log lives on separate drives from your data file, send those too: data file and log are read together at this end. Then give us the history of your system. Was there a rebuild? Did you run an import? Was a configuration cleared? Was a member forced back online? Has a repair been run against the database? Nothing else you can tell us does as much to set the order of our work.

What does it cost, and when do I get the files back?

Server and RAID set recovery begins at £500 + VAT, and that price is printed here rather than saved for phone calls. We don't charge for the assessment. Once we give you a figure, it appears on paper and it holds; no chargeable work is done unless you accept it, and in most cases you only pay if we recover your data. Allow four to six working days on a multi-disk set, from your parcel arriving here to the files leaving on new media, with urgent cases moved up the queue.

Start here if the same thing is happening to yours.

Disks pulled out of a NAS → A RAID 5 rebuild that went wrong → Files locked up by ransomware → The full device list →

Switched off, a drive cannot get any worse.

The look costs nothing. It gives you a file listing of what opened and what did not, along with the cost of finishing the job, in writing, before anything chargeable begins. In most cases you only pay if we recover your data. Do not switch the drive on until you have that listing.

0115 8220606

Get a quote, then send it Posting it to Manchester