Taking work now — the first look is freeWhole sets posted in from anywhere in the UK, or handed in at ten drop-off pointsQuicker still, give us a ring:0800 6890668
RARRAID Array Data Recovery 0800 6890668 Price my job
RAR / Whatever it is saying now / mdadm: not enough devices, array inactive

mdadm --examine · Not enough devices · inactive · kicking non-fresh · no superblock · --assemble --force · --create --assume-clean

mdadm: not enough devices to start the array. The superblocks know what happened. The forum's two commands write over them.

Linux's md driver assembles an array from the members whose superblocks agree: same UUID, and event counts that match. When too few of them do, it refuses, and the log says why in one of a few ways. md: kicking non-fresh sdX from array means that member's event count is behind, because it dropped out and missed writes. Not enough devices to start the array means that after the stale members were kicked, fewer remained than the level needs. no superblock on /dev/sdX means the superblock was not found where mdadm looked, which is version-dependent: 0.90 and 1.0 near the end of the device, 1.1 at the start, 1.2 four kilobytes from the start. Inactive in /proc/mdstat means the array was found and not started. Every one of those is recoverable from images with the superblocks read from all four locations, and every one of them is made harder by the two commands the forums offer: --assemble --force, which promotes a stale member to current, and --create, which writes new superblocks over the old with whatever geometry was typed. 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

Do not run mdadm --create, and do not run --assemble --force, on the members. The first writes new superblocks with new UUIDs and possibly a new data offset; the second promotes a stale member to current and lets the array write over it. Run --examine on every member, copy the output, and stop.

What the superblocks say, and what each command does to them.

Every md member carries a superblock recording the array's UUID, level, chunk size and layout, the member's role, the data offset, and an event counter incremented on every write to the array. At assembly, mdadm groups members by UUID and starts the array from the members whose counts agree. A member whose count is lower missed writes, because it dropped out during a power cut or a cable fault and came back later, and its copy of the data is older than the others'. The kernel says so, kicking non-fresh, and assembles without it. If that leaves fewer members than the level needs, it says Not enough devices to start the array and leaves the array inactive. Nothing has been written; the state on the members is exactly what it was.

--examine reads a member's superblock and prints all of it: Version, UUID, Raid Level, Raid Devices, Data Offset, Super Offset, Layout, Chunk Size, Device Role, Events. Run on every member, it is the whole case, and it writes nothing. --assemble --readonly starts the array without writing to it. dmesg and /proc/mdstat report what was tried. Those are the diagnostics.

--assemble --force tells mdadm to include a stale member as if it were current, and the array then runs with weeks-old blocks in one member's stripes and writes on top of them. --create writes brand-new superblocks on every member with a new UUID, the level, chunk and layout typed on the command line, and the data offset the current mdadm version uses; with --assume-clean it skips the resync, and without it the resync rewrites parity from the data as the new geometry sees it. --create does not write to the data area, so the data survives it; what is lost is the description, and on an array created with an older mdadm the data offset, so that the superblock says one thing and the partition table sits somewhere else. The bench recovers the geometry from the parity and the true offset from where the file system actually starts, and the old superblocks are sometimes still readable at a different location from the array's earlier life.

What it says, and what it means.

Describe yours to us →
What you see The usual reason Where that leaves you
md: kicking non-fresh sdX from arrayThat member is staleImage it; assemble from the current members
Not enough devices to start the arrayToo few current membersEvery superblock read from images; the stale member used to fill
no superblock on /dev/sdXWrong version looked for, or overwrittenAll four locations checked on the image
sdX has different UUIDAnother array, or --create ranCheck the superblocks from the images
inactive in /proc/mdstatFound, not startedNothing written; do not force
--create ran; volume will not mountNew superblocks, possibly new offsetGeometry from parity; offset from the file system

From the parcel arriving to your files going back.

Work we have closed →
01

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
02

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
03

The geometry, from the metadata or from the parity

Every superblock is read from the images at all four locations before anything is assembled: version, UUID, chunk, layout, role, data offset and event count on each member. The current members are chosen by count and the set assembled in software from them, proved by parity, with the stale member used only where the others cannot read. Where --create has overwritten the superblocks, the original chunk and layout are recovered from the parity and the data offset from where the partition table or superblock of the file system actually sits.

Metadata first, parity secondOrder, stripe, rotation, offset
04

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
05

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

  • Copy out --examine for every member, dmesg and /proc/mdstat, before anything else. They are the case, and they are read-only.
  • Not enough devices is mdadm being careful. It has not written anything. Leave it there.
  • --create with the same parameters is not safe either. A newer mdadm uses a different data offset, and the resync rewrites parity.
  • Several read errors corrected on one drive in a day is a drive to image now, before it is the one the rebuild reads.

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-0620JOB LOGGED ✓

An eight-drive mdadm RAID 6 that logged kicking non-fresh on two members after a power cut, then went inactive with Not enough devices when the owner tried --assemble --force

The force had promoted one stale member and the array had refused the result. All eight drives were imaged, the superblocks read from the images, the two stale members identified by their event counts, and the set assembled in software from the six current members with the stale ones used only where the others could not read. The XFS volume mounted read-only from the virtual array and everything came back.

100% of the volume recovered8 days here, and back by post
Illustrative example — replace with a genuine case

What helps, and what harms.

Do this much first

  • Copy out mdadm --examine for every member, dmesg and mdstat
  • Power down and label the slots or device names
  • Send every member
  • Tell us every command that was run, in order

What sets us back

  • mdadm --create over existing members
  • --assemble --force before the stale member is known
  • Adding a new drive and letting it resync
  • Running fsck on the array's file system

Questions answered before you commit.

What does Not enough devices to start the array mean?

That after kicking the stale members, fewer remained than the level needs. mdadm has written nothing. The superblocks and event counts on every member say which are current, and the set is assembled from images.

What does kicking non-fresh mean?

That the member's event count is behind: it dropped out and missed writes. mdadm assembles without it. Image it; do not force it back in.

I ran --create. Is the array gone?

Not the data. --create writes superblocks, not the data area. The original geometry is recovered from the parity and the true data offset from where the file system actually starts.

What does it cost?

£500 + VAT upwards for a set of two to four members after the free look, fixed in writing; eight drives or more from £1,250 + VAT.

How long does it take?

5–10 days at the bench.

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