RAR / Whatever it is saying now / Virtual disk degraded

PERC H710 · H730 · H740P · MegaRAID · ServeRAID · Degraded · Partially degraded · Unconfigured bad · Predictive

The virtual disk is degraded. A warning with a clock on it, and a spare slot the controller wants to fill.

A PERC or MegaRAID virtual disk goes Degraded when a member has been dropped: in RAID 5 or 10 one member, in RAID 6 one or two, with Partially Degraded meaning a RAID 6 that has lost one. The virtual disk keeps serving, computed from parity or read from the mirror's other half, with no redundancy left. The physical disk that was dropped shows Failed, Offline or Unconfigured Bad, or has simply gone Missing, and the controller's instinct, and the vendor's documentation, is to fit a replacement and rebuild. A rebuild reads every sector of every survivor to compute the missing member, on drives bought the same day as the one that failed, and a survivor showing Predictive Failure is the controller's own warning that this is about to go wrong. A set of two to four members is £500 + VAT upwards after the free look, fixed in writing, 5–10 days at the bench.

Free first lookOne fixed figure in writingNo data, no bill on most jobsReturn postage paid

Rather talk it through? An engineer answers the bench line
0800 6890668

Power down. Label every slot before a drive comes out. Do not rebuild, do not force a drive online, do not import or clear a foreign configuration, do not initialise, and do not run chkdsk, fsck, zpool import -F or mdadm --create on the members. A rebuild reads every sector of every survivor and writes to the replacement; each of the commands writes to the drives. On images, all of them are reversible. On the originals, none of them is.

What the controller is doing at each state, and where it goes wrong.

A PERC watches every read a physical disk answers. A disk that returns an unrecoverable error, or takes longer than the controller will wait, is marked Failed and dropped; MegaRAID calls the same drive Unconfigured Bad, a drive it will not use until told to. Enterprise firmware reports the error within seconds precisely so the controller has something to act on. The virtual disk becomes Degraded: every read is now served from the survivors and, in RAID 5, computed from parity where the missing member's data should be. It works, and it works with no margin.

A hot spare, or a replacement fitted into the slot, starts a rebuild. The controller reads every stripe of every survivor to compute the missing member's contents and write them onto the new drive, including the stripes nobody has read since the array was built and the ones a survivor has been quietly working around. A survivor that throws an unrecoverable read error part-way through is either dropped, which fails the virtual disk, or, on a PERC with the option enabled, skipped, which produces a puncture: an array marked Optimal with a hole in it. Predictive failure on any survivor is the controller's warning that this is about to happen.

The bench does the same arithmetic on images. Every member is imaged with its weak areas last, including the one the controller dropped, which still holds every stripe written before it dropped. If one member was the job and the rest are healthy, its image goes back on fresh media, sector-identical, so the rebuild runs from a drive that answers every read; that is the drive site's £300 job. If the set has a second weak member, the set is reassembled from the images in software, where nothing can stall.

What it says, and what it means.

Describe yours to us →

What you see	The usual reason	Where that leaves you
Virtual disk: Degraded	One member dropped (two in RAID 6)	Copy critical data; power down; image the weak drives before rebuilding
Virtual disk: Partially degraded	RAID 6 with one member out	Replace it if every survivor is clean; otherwise image first
Physical disk: Failed / Unconfigured bad, but it spins	Answered too slowly once	Usually reads on the bench; image it
Physical disk: Predictive failure on a survivor	Thresholds crossed	Stop; the rebuild will read the sectors that finish it
Physical disk: Missing	Backplane, cable or the drive	Check seating once, server off; do not clear anything
Rebuild at n per cent, then Failed	A survivor's read errors	Power down; the first-dropped drive still holds the stripes

From the parcel arriving to your files going back.

Work we have closed →

Logged the day it lands, and the first look costs nothing Free

A case number goes on the parcel and a number on every member the day it is opened, matched to the slot you wrote on it. Each member goes on the imager its interface needs, never on a controller, and its metadata is read before a sector is: the level, the order, the stripe size, the event counts that say which member is current and which dropped out first. An engineer settles what has happened to the set and how much of it can honestly be read back. Back to you come two things together: a straight note of what is liftable and what is not, plus one figure, fixed and written down. Accept it, or decline and owe us nothing.

Nothing to pay for lookingA single figure, put in writingNo rebuilds, no imports, no initialise

Every member imaged, including the one that failed first

Every drive in the set is imaged sector by sector, weak areas last, on hardware that controls every retry, with a map of what could not be read kept for each. Members with failed heads go to the clean bench first; that is the drive site's work and the same bench does it. The drive that dropped out first is imaged too, because it still holds every stripe written before it dropped, and a rebuild that stalled part-way never reached them.

Sector by sector, weak areas lastThe first-dropped member included

The geometry, from the metadata or from the parity

Where the controller's metadata survives on the members, the order, stripe size, parity rotation and data offset are read from it. Where it was cleared or overwritten, they are recovered from the data: parity across the members at the same offset should XOR to zero on a consistent stripe, which confirms the level and finds the stale member; where parity lands says the rotation; entropy at stripe edges and the file system's own anchors give the stripe size, the order and the start.

Metadata first, parity secondOrder, stripe, rotation, offset

Assembled in software, and repaired on the virtual volume

The set is put together from the images in software, with nothing written to any of them: the current members in, the stale member used only to fill holes a survivor could not give. The file system is checked and repaired on a copy of the virtual volume, VMFS and CSV volumes opened and the virtual machines' disks extracted, databases repaired where they need it. The originals are not touched again.

Nothing written to the imagesVirtual machines and databases opened

You see the file list before you pay

What was recovered is listed for you first, and only then does a bill exist. Approve the list and it is invoiced; turn it down and it is not — and where nothing has come back, most jobs carry no charge at all. Recovered data travels home on fresh media bought in for your job, with the postage at our end. Your case is not closed until you have opened the files on a machine of your own.

No charge until you accept the figureFresh media, supplied with the job5–10 days at the bench

From the bench

Export the log first. OpenManage, iDRAC, perccli or storcli /c0 show all give the controller's own account of what failed when.
Degraded with a predictive-failure survivor is the stop signal. The rebuild will read the sectors that finish it.
Failed by the controller is not failed. A drive dropped for one slow read usually images in an afternoon.
The first-dropped drive holds the stripes the rebuild never reached. Keep it; do not let the engineer take it.

Tonight, in this order: stop writes and do not reboot repeatedly; press nothing the controller offers (F2, Import, Clear, Force online, Rebuild); photograph the screen and label the slots; export the log without changing state (PERC TTYLOG or storcli show all, an SSA diagnostic report, mdadm --examine on every member, zpool import with no flags, Get-VirtualDisk); power down and send every member, plus the controller if it was replaced or holds a key. The first-response page has the reasons.

One job, followed all the way through.

UK · RAR-2026-0613JOB LOGGED ✓

An R740 in RAID 5 on a PERC H740P, slot 2 Failed and slot 4 Predictive, a hot spare that had already begun rebuilding, and an owner who pulled the power at 12 per cent

All six drives came in, including the part-written hot spare. Slot 2 had failed heads and was imaged after a head swap; slot 4 was imaged with its weak areas last; the survivors directly. The DDF metadata gave the geometry, parity across the images confirmed it, and the set was assembled from the four clean survivors and the slot 2 image, with slot 4's image used where slot 2 could not read. The file server's NTFS volume mounted and was copied out.

100% of the volume recovered7 days here, and back by post

Illustrative example — replace with a genuine case

What helps, and what harms.

Do this much first

Export the controller log
Copy anything critical while it still reads
Power down and label the slots
Send every member, including the failed one and any part-rebuilt spare

What sets us back

Fitting a spare with a predictive-failure survivor
Forcing the failed drive online to see
Clearing the foreign configuration to tidy the warning
Handing the failed drive to the warranty engineer first

Questions answered before you commit.

The virtual disk is degraded. Is my data at risk?

It is readable now and recoverable in any case. What puts it at risk is the rebuild, which reads every sector of every survivor. If any survivor is predictive, image the weak drives first.

Should I fit the hot spare?

Only if every survivor is healthy and you have a backup. Otherwise power down and send the weak drives.

What does Unconfigured Bad mean?

MegaRAID's name for a drive it dropped and will not use. It answered too slowly once. It usually reads on the bench.

What does it cost?

One member imaged so your own rebuild can run is £300 + VAT on the drive site; a set of two to four members reassembled here is £500 + VAT upwards; larger sets from £1,250 + VAT.

How long does it take?

5–10 days at the bench for a set of two to four.

Where this usually leads.

Rebuild failed: a second drive went during it →Virtual disk failed or offline →Dell PERC →Broadcom MegaRAID and ServeRAID →RAID 5 →

Nothing gets worse while it is powered down.

Looking at it is free. Back comes a list of what opened and what did not, together with a single price to finish, set down in writing while you are still free to say no. Until that list reaches you, leave the server off and the drives in their slots.

0800 6890668

Price my job Packing and posting

Every level and layout

Manufacturers

Whatever it is saying now

Servers

What it costs, and what follows