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 begin at £500 + VAT, the assessment costs nothing, and you have the figure on paper before a chargeable minute is spent. Underneath, nearly every SQL job here takes one shape: an .mdf and its .ldf on an array that has been quietly short of a member for weeks; a spare put in; a rebuild left to run; a second carrier going amber while it does. What shows at the top of all that is a database that will not attach, or one sitting in SUSPECT or RECOVERY PENDING — three layers above the fault itself. So every disk gets cloned read-only on its own, how the controller arranged the set is recovered from those images, the volume goes together above them, and the database files are lifted off and opened on copies. Sets arrive from Nottingham, Derby, Leicester, Lincoln, Loughborough and Newark-on-Trent.

No files back, no bill — 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 serve cleanly — not a fault inside SQL ServerStop the instance and cut the power
A rebuild started and then halted part-wayThe set was already a member down when a second one started to give outTake the chassis off power
The controller reports a foreign configurationIt has mislaid its own description of the set following a power cutDo not import it; ring us first
The .ldf is gone and only the .mdf is leftA log file deleted, or sitting on a volume that never returnedSend both volumes if either survives
A disk plugged into a PC reads as nothing at allA SAS member will not plug into a desktop SATA port at all, and a disk out of a storage array may be formatted at 520 bytes a sector, which an ordinary controller refusesInterface or formatting, not a fault. Send them
The full backup restores but the log chain will notA gap in the chain, which only ever shows up on the day it is neededSend the array as well as the backup disk
How to pack and post it: pack it so nothing can move, value the parcel at what the data is worth to you rather than what the hardware cost, and use a tracked service to the intake lab. Postage back is ours. Would you rather an engineer talked the packing through first? Ring before you seal the box. All of it is set out on the packing and postage guide.

Where a SQL Server job actually stops.

The .mdf, the .ndf and the .ldfA SQL Server database is a data file, sometimes several of them, with a log file alongside, and all of it has to agree with itself. The log is what makes the data file usable again after an unclean stop, so a job with the .ldf intact runs quite differently from one without it. Send both where both exist, and say which disks each of them was living on.
SUSPECT, RECOVERY PENDING and the restThe state a database comes up in describes what the engine could not read. It is not a diagnosis. RECOVERY PENDING usually points at a file it cannot find or open at all; SUSPECT at one it opened and could not trust. Either way the cause is under the file system, which is where this job begins rather than ends.
Controllers, and 520-byte membersA RAID controller stores its own account of a set on the disks themselves — the order the members sat in, the width of the stripe, the way parity moved, and the point at which data starts — so the volume can be reassembled from images at this end, with no card and no chassis. Disks that have come out of a storage array — NetApp, EMC, HPE 3PAR — are often formatted at 520 or 528 bytes to a sector rather than the usual 512, the extra bytes carrying an integrity checksum, which is precisely why an ordinary controller will not read them. Formatting, not damage.
What we never doNo rebuild is started, nothing is imported, no configuration is cleared, no member is forced back online, and no repair is run against the database you sent. Every one of those is a write, and each write removes an option. Your members are read a single time 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.

Jobs already finished →
01

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

Your device picks up a case number the day it arrives, and an engineer then establishes what has genuinely gone wrong — at no cost, and ahead of everything else. Two things come back to you together: a plain account of what can be lifted and what cannot, and one fixed figure in writing. Agree to that figure, or turn it down and pay nothing.

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

Copies before the array is asked anything

Behind a write blocker, every member is read and cloned in full before the set is so much as put together — the healthy disks and equally whichever one the controller had given up on. Difficult regions are taken in short runs and left until everything else is safely down. At no point in the job does a byte go back onto the drives you posted.

Each member imaged firstNothing goes back onto your disks
03

The volume rebuilt from the members themselves

Because a controller keeps its account of the 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 ran, how parity moved across them and the point at which data actually starts are all recovered from the images, cross-checked against the file system above, and only then is the volume built over the 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. Where the log is intact the database is attached and checked; where it is not, the data file is opened on its own and the tables read out of it. Anything that comes back damaged is named as damaged, page by page, rather than handed over as a file that opens today and argues with you next week.

Database files taken as copiesDamage named, page by page
05

The file list comes before the bill

The file list reaches you before any invoice does. Say yes and it is billed; say no and it is not — and on most jobs, if nothing comes back there is nothing to pay. Whatever comes off goes home on media bought in for your case, carriage at our end. Nothing here is closed until you have opened those files on your own machine.

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 sets it when the engine could not trust what it read back, and the reason for that generally sits under the file system rather than inside it. Working on the database while the array is still unresolved fixes nothing and spends what little margin is left.
  • Nothing loads a set harder than a rebuild — finishing one means reading every sector of every surviving member, and those members went into the bays together, out of one batch, carrying the same hours. So a disk giving out mid-rebuild is not misfortune. It is the weakest survivor being handed the heaviest task of its life.
  • Never detach a database that will not come up — of everything anybody does on a bad day, forcing a SUSPECT database into EMERGENCY mode and detaching it (SQL Server will not detach it any other way) is the one that most reliably turns a workable job into an awkward one, because it takes away the state SQL Server needs in order to attach the thing again. Leave it exactly as it is, stop the instance, and let the array be copied first.
  • The log volume counts as part of the job — plenty of installations keep the .ldf on a separate set of disks from the .mdf, and here the two are read together. Send both. Tell us as well what has already been run: a rebuild, an import, a configuration cleared, a member forced back online, DBCC with repair allowed. Nothing else you can tell us 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 was left running; whether a repair was allowed to discard pages; and whether the volume was encrypted. Shut a server down with every disk still in its bay and the options stay at their widest. Fit a spare, run a rebuild, import a configuration and restart it for two nights, and they narrow a long way — though you still hear which tables sit in the gaps while there is nothing yet to pay. Encryption needs its key, and that comes from you. Storage recovery is all we do, so no phones and no tablets. The band for servers and RAID sets starts at £500 + VAT, put in writing once the free assessment is finished, and on most jobs you are not billed at all unless your data is genuinely back.

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 manufacturer in Leicester kept its batch and QA records on a six-bay server that had quietly been running a member short since the summer without anyone noticing. When a second carrier turned amber a spare went in and the rebuild was allowed to run; it halted part-way, the virtual disk dropped offline, and on the next restart the job database came up SUSPECT. Power came off the chassis that same afternoon, and every drive reached us with a bay number on its carrier. Copies were taken of the two weak members first, one of them across four passes, while the rest read from end to end. The controller's own account of the set came off the images, the volume was assembled above them, and the .mdf and .ldf were taken away as copies. Both databases attached, and both were checked here before a thing 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
  • Say 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 describing storage rather than the database itself. SUSPECT means the engine opened the files, read something it could not trust, and stopped rather than carry on guessing — which on an array running a member short is a symptom several layers below SQL Server. Two things then decide how the job goes. Do not force it into EMERGENCY mode and detach it — SQL Server will not detach a SUSPECT database any other way — because a database detached in that state is considerably harder to attach again. Do not run a repair that is allowed to discard pages. Stop the instance, take the chassis off power, 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. A rebuild pushes every surviving member through a complete sector read, and those members are the most worn things in the room; whichever is weakest tends to be the one that quits under that demand. Let it run on and the set is short of two rather than short of one, with copies still to be taken off each. So: chassis off power, carriers left in their slots, and images made before a further thing is attempted.

Do you want the server, or only the disks?

The disks. Pull each member as a bare drive and write its bay number on it; carriers, chassis and card can all stay put, because how the set was arranged gets recovered from the images rather than out of your hardware. Where the log lives on its own disks, those come too — data file and log are read together at this end. Then give us the history. A rebuild, an import, a cleared configuration, a member forced back online, a repair run against the database: nothing else you can hand over does as much to set the order of the work.

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

£500 + VAT is where servers and RAID sets begin, and that band is printed here instead of being saved for the telephone. The assessment is not charged for. A figure follows it on paper, and it holds; no chargeable work happens until you have accepted that figure, and on most jobs, where nothing is recovered, there is no bill whatever. Allow four to six working days on a multi-disk set, from the 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. What comes back to you is a file list — what opened, what did not — plus one figure to finish the job, in writing, before anything chargeable begins. Most jobs carry no fee at all unless the data comes back. Leave the drive switched off until you have that list.

0115 8220606

Send it for a free look Posting it to Manchester