LSI MegaRAID SAS2108 Data Recovery: 9260, 9261, 9280, IBM M5015 and Intel RS2BL080 Error Messages and Failure States

The LSI SAS2108 was the chip inside the first generation of 6 Gb/s MegaRAID controllers: the MegaRAID SAS 9260, 9261 and 9280 families, and a long list of rebadged twins sold by IBM, Intel and other server makers from 2010 onward. Every one of them uses the same firmware lineage, the same WebBIOS setup utility, the same MegaCLI command-line tool and the same MegaRAID Storage Manager event log — which means they fail in the same ways and put the same messages on the screen. This page collects those messages from LSI’s own documentation, OEM guides from IBM, Intel and Oracle, the Linux kernel source, and years of administrator forum threads, and rates each one by how much danger your data is in and which keystroke turns a recoverable array into an unrecoverable one.

Gillware has been recovering failed RAID arrays for more than two decades from our lab in Madison, Wisconsin. If your SAS2108 array is already offline and the data matters, power the server down and book a free consultation with one of our enterprise recovery experts.

Before You Press Anything: The SAS2108 Actions That Destroy Arrays

MegaRAID gives an administrator a lot of power at the moment an array fails, and most of it writes to the drives. Every action below appears in vendor documentation or support walkthroughs as a legitimate step. Each is safe when the array’s history is simple and every member is healthy — and a one-way door when it is not.

• Clearing a foreign configuration (WebBIOS Clear, MegaCLI -CfgForeign -Clear). Foreign configuration is the array definition the controller found on the drives. Clearing it erases the only copy of that map.
• Pressing F at POST, or importing a foreign configuration, when members dropped out at different times. Import trusts every member’s metadata. If one drive fell out of the array days before the others, its data is stale, and the import can hand the controller a mix of old and current data.
• Making “Unconfigured Bad” drives “Unconfigured Good” and forcing them back in (Make UnconfGood, MegaCLI -PDMakeGood, then -PDOnline or Make Online). When the drives were healthy and simply lost their connection, this is exactly the right fix. When a drive actually failed, or dropped out earlier than the rest, it injects stale or unreadable data into a live array.
• “Replace Missing PD” followed by marking the drive online. MegaRAID warns that virtual drive corruption can occur, and it means it.
• Discarding preserved cache (the POST prompt about offline or missing virtual drives with preserved cache, MegaCLI -DiscardPreservedCache). Preserved cache holds writes the controller could not deliver because the array went away. Discarding it throws them out permanently.
• Clearing the configuration (WebBIOS Clear Configuration, MegaCLI -CfgClr) or deleting a virtual drive.
• Initializing a virtual drive (fast or slow initialization, MegaCLI -LDInit). IBM’s own fix for punctured blocks is a slow initialization after backing up — a step that zeroes the array.
• Recreating the virtual drive “without initialization.” A real technique administrators use after an import fails, and it sometimes works. It only works if RAID level, member order, stripe size and start offset match the original exactly; get one wrong and the new metadata overwrites the old.
• Flashing firmware — or cross-flashing an IBM card to LSI firmware — with array members attached. MegaRAID has a specific event for cache that had to be thrown away because the firmware changed underneath it.
• Starting a rebuild or consistency check on a degraded array whose surviving members are logging media errors. Both read every sector of every surviving drive.
• Plugging member drives into a motherboard SATA port or another PC to “see what’s on them.” A RAID 1 member looks like a normal disk to Windows, and the first write to it breaks the mirror.

If you have already done one of these, stop there and do not try another to undo it. Most of these situations are still recoverable from drive images if nothing else is written.

The SAS2108 Family at a Glance

Every card on this page is built on the LSI SAS2108 RAID-on-chip: an 800 MHz PowerPC core, a PCIe 2.0 x8 host interface, 6 Gb/s SAS and SATA ports, support for SAS expanders, and 512 MB of DDR2-800 cache on most models. The cards differ mainly in port count, connector orientation, cache size and how the cache is protected.

Card	Ports	Cache	Cache protection	Notes
LSI MegaRAID SAS 9260-4i	4 internal (1 × SFF-8087)	512 MB	Optional battery (iBBU07)	Low-profile
LSI MegaRAID SAS 9260-8i	8 internal (2 × SFF-8087, vertical)	512 MB	Optional battery (iBBU07)	The most common SAS2108 card
LSI MegaRAID SAS 9260CV-4i / CV-8i	4 / 8 internal	512 MB non-volatile	CacheVault flash module (CVFM01)	Flash instead of battery
LSI MegaRAID SAS 9260DE-8i	8 internal	512 MB	—	Same connectors as the 9260-8i
LSI MegaRAID SAS 9261-8i	8 internal (2 × SFF-8087, horizontal)	512 MB	Optional battery	Same chip; connectors exit the side
LSI MegaRAID SAS 9280 family (e.g. 9280-4i4e, 9280-16i4e)	Internal plus external ports	512 MB	Optional battery	Common with external JBOD shelves
IBM ServeRAID M5015	8 internal	512 MB	M5000 battery included	RAID 6/60 require an Advanced Feature Key
IBM ServeRAID M5014	8 internal	256 MB	Battery optional	RAID 6/60 require an Advanced Feature Key
Intel RAID Controller RS2BL080 / RS2BL040	8 / 4 internal	512 MB ECC	Intel Smart Battery AXXRSBBU7 / BBU8	Setup utility opens with Ctrl+G; discontinued 2017

All of the full cards support RAID 0, 1, 5, 6, 10, 50 and 60 (the IBM cards need their feature key for 6 and 60). IBM notes that mixing SAS and SATA drives in the same array is not supported on its M5000-series cards. The 9260-8i is a server part that needs active airflow across its heatsink — a detail that matters in towers and home-lab builds.

How SAS2108 Controllers Store Your Array

The map is on the drives, and in the controller

MegaRAID keeps the array definition — which drives belong to which virtual drive, their order, stripe size, RAID level and state — in two places: the controller’s own non-volatile memory, and a metadata record on every member drive (SNIA’s Disk Data Format, stored in a reserved area at the end of each disk). When the two agree, the array simply comes up. When they disagree — a replacement controller, drives moved to another server, drives that vanished and came back — the controller calls what it found on the drives a foreign configuration and waits for someone to decide what to do with it. Almost every SAS2108 data-loss story involves that decision.

Preserved cache

When a virtual drive goes offline while the controller still holds writes for it in cache, SAS2108 firmware keeps those writes instead of throwing them away, and says so at POST. That cache is the last thing written before the failure — often file system metadata. It is only useful if the original members come back.

Punctures and the bad block table

If a rebuild or consistency check finds an unreadable block on one member while another member is already missing or also unreadable at the same spot, MegaRAID cannot reconstruct that stripe. It “punctures” it — records it as bad and returns an error whenever it is read — rather than handing the operating system invented data. The array stays online; the data in that stripe is gone from the controller’s point of view. We cover the mechanism in more depth on our RAID puncture page.

Cache protection

Write-back cache on these cards is protected by a battery (LSI iBBU07, IBM M5000 battery, Intel AXXRSBBU7/BBU8) or, on the 9260CV models, a CacheVault flash module. Batteries age, and their periodic learn cycles change how the controller handles writes while they run. A failed or missing battery with write-back forced on is one of the classic ways to lose the last few seconds of writes during a power event.

Compatibility boundaries

• SAS2108 to SAS2108: a healthy array normally imports into another SAS2108 card. Firmware differences can still block it; one administrator documented an identical replacement 9260-8i refusing to import until firmware was addressed.
• IBM and Intel rebadges: same chip and metadata, different firmware packages. IBM cards need the M5000 feature key for RAID 6 and 60; check the replacement has it before connecting RAID 6 drives.
• To newer MegaRAID generations: later MegaRAID cards are built around the same metadata format, but every import is a write to the drives. On a degraded array, image first.
• To Adaptec, HPE Smart Array or motherboard RAID: no import path in either direction.

How to Read the Message Catalog

Risk level	What it means	What to do
Level 1 — Informational	No data at risk.	Note it and move on.
Level 2 — At risk	Redundancy lost, cache protection gone, or confirmed unreadable blocks.	Back up first. Avoid rebuilds until the backup is done if survivors show errors.
Level 3 — Data offline	The virtual drive or controller is unavailable. The data is usually still on the drives.	Power down. No imports, clears, forces or rebuilds.
Level 4 — Destructive prompt	The screen is asking you to do something that writes to the drives.	Do not confirm until you are certain, or until the drives have been imaged.

Messages at Boot (MegaRAID BIOS)

“Foreign configuration(s) found on adapter. Press any key to continue or ‘C’ load the configuration utility, or ‘F’ to import foreign configuration(s) and continue.”

Risk: Level 3 — and the F key is a Level 4 prompt.

What it means: the drives carry an array definition the controller does not have in its own memory. The usual causes are a replaced or reset controller, drives moved from another server, or drives that lost their connection long enough for the controller to drop them and then found them again.

What not to do: do not press F to “just get it booting” unless you know every member dropped out at the same moment and every drive is healthy. On Intel-branded cards the same situation shows up as drives marked Frn-Ba (Foreign Bad) in the RAID BIOS.

Safe next step: press any key to continue without importing, or power off. Record which drives are present. If the event was a single cable, backplane or power interruption that affected all drives at once, the import is usually the right fix — but if any drive failed earlier, image the drives first. More on this state on our foreign configuration page.

“All of the disks from your previous configuration are gone. If this is an unexpected message, then please power off your system and check your cables to ensure all disks are present.”

Risk: Level 3. The controller remembers an array but finds none of its drives. That is almost never every drive failing at once — it is a cable, backplane, expander, power supply or a drive shelf that did not power up. The related message Some configured disks have been removed from your system means some, not all, are missing. Power down, check connections and power with the system off, and do not create a new configuration on the empty controller.

“The following VDs have missing disks”

Risk: Level 2 or 3, depending on how many members are missing versus the RAID level’s tolerance. Note which virtual drives are listed. A redundant array with one missing member will run degraded; a second missing member takes it offline.

“There are offline or missing virtual drives with preserved cache”

Risk: Level 3, with a Level 4 prompt. The controller is holding writes for a virtual drive that is no longer there, and at boot it asks what to do with them. The safe answer is to bring the original members back so the cache can be delivered to the drives it belongs to. Discarding it is permanent. Flushing it against a different set of drives writes those blocks to the wrong places.

“Memory/battery problems were detected. The adapter has recovered, but cached data was lost. Press any key to continue.”

Risk: Level 2–3. The controller could not preserve its cache through the last power loss or reset. Writes the operating system believed were complete never reached the drives. The array itself is usually intact, but file systems on it may need careful checking — and a repair tool run against a live volume can make small inconsistencies much worse. If the data matters, image first, repair second.

“Invalid SAS Topology Detected”

Risk: Level 3. Oracle documents this as an error that stops the system from booting on its MegaRAID-based HBA. It points at cabling, expander or backplane wiring rather than the drives. Fix the wiring with the power off; do not change the array configuration to get past it.

Intel RS2BL080: configuration mismatch at boot

Risk: Level 3. Intel’s rebadged cards use their own wording and open the RAID BIOS with Ctrl+G. Administrators report a “configuration mismatch” warning at boot with an option to press C. The underlying state is the same as LSI’s foreign configuration message; treat it the same way.

Drive States and Prompts in WebBIOS (Ctrl+H)

“(FOREIGN) Unconfigured Bad”

Risk: Level 3. The drive is present, carries metadata from an array the controller does not currently have, and has been marked bad. Oracle’s documentation shows WebBIOS listing these drives in black text and the recovered (FOREIGN) Unconfigured Good drives in blue. The vendor procedure for drives that lost their connection is: make each one Unconfigured Good, scan devices, open Foreign Configs Found, click Preview, then Import.

That procedure is correct when the cause was a connection event that hit every member at once — a pulled backplane module, a cable, a power blip. It is dangerous when drives went bad at different times, because it tells the controller to trust all of them equally.

“Make UnconfGood” / “Make Online”

Risk: Level 4. Changing a drive’s state is not a read-only action; it changes what the controller will do with that drive’s data at the next scan or import. Before changing any state, record every drive’s slot, serial number and current state.

“Replace Missing PD” and the corruption warning

Risk: Level 4. This inserts a drive into a missing slot of an existing virtual drive. MegaRAID warns that virtual drive corruption can occur. In one documented case, an administrator whose RAID 5 lost two drives had repaired the second drive’s circuit board, cleared its foreign configuration, and still found the array offline; the suggested next step was exactly this replace-and-online sequence. It is sometimes the only path left through the controller — and it is also the step that decides whether the data survives.

Fast Initialize / Slow Initialize

Risk: Level 4. Initialization writes zeroes (fast: the start of the virtual drive; slow: all of it). It is required for new arrays and has no place on an array that holds data you want.

Clear Configuration and Delete Virtual Drive

Risk: Level 4. Clearing the configuration deletes every virtual drive definition. The data blocks stay on the disks until something overwrites them, but the controller will no longer know the array existed.

MegaRAID Storage Manager and Event Log Messages

MegaRAID Storage Manager (MSM) — Intel ships it as RAID Web Console 2 — shows the controller’s event log. The same event text appears in MegaCLI’s event log dump and, for critical events, in the Linux kernel log. Events include the drive address in the form PD 05(e0x20/s5): device ID 05, enclosure 0x20, slot 5.

“State change on PD 05(e0x20/s5) from ONLINE(18) to FAILED(11)”

Risk: Level 2. A member drive has been failed out of its array. It usually follows Error on PD 05(e0x20/s5) (Error 02) and sometimes a fatal Reassign write operation failed on PD … (the firmware spells it “operaiton”), meaning the drive could not remap a bad sector. Note the slot and serial number now.

“VD 00/0 is now DEGRADED”

Risk: Level 2. The virtual drive is running without full redundancy. Back up before replacing the failed drive if any surviving member is logging errors, because the rebuild will read every sector of every survivor. When a redundant virtual drive loses more members than it can tolerate, MegaRAID reports it offline instead, and it stops presenting the volume.

“Controller cache discarded due to memory/battery problems”

Risk: Level 2–3. A fatal-class event (code 0x000a in LSI’s event table). The cache contents were lost, not delivered. Some integrators note it also fires when write-back is configured on a card with no battery installed — which is itself a warning that a power loss will lose writes.

“Unable to recover cache data due to configuration mismatch”

Risk: Level 3. Fatal-class (0x000b). The controller had cached data but the configuration it belonged to no longer matches — typically because drives or the configuration changed before the cache could be flushed. Related events: Unable to recover cache data from TBBU (0x0002, fatal) when the battery-backed cache module could not deliver its contents, and Cache data recovered from TBBU successfully (0x0003) when it could.

“Controller cache discarded due to firmware version incompatibility”

Risk: Level 3. Fatal-class (0x000d). Cache was thrown away because the firmware changed while it held data — the reason not to flash or cross-flash a card with an array in trouble attached.

“Fatal firmware error: …” and “Configuration cleared”

Risk: Level 3 and Level 4 aftermath. A fatal firmware error (0x000f) means the controller itself crashed; the drives are usually fine. Configuration cleared (0x0004) records that someone or something erased the configuration. If nobody on your team did it, find out what did before anything else changes.

“Puncturing bad block on PD” — and the other punctured-stripe events

Risk: Level 2, with confirmed data loss inside the array. IBM lists the family: Puncturing bad block on PD, Patrol Read found an uncorrectable medium error on PD, Consistency Check detected uncorrectable multiple medium errors, Background Initialization detected uncorrectable multiple medium errors and Double media errors found! IBM’s recommended fix is to back up and then run a slow (full) initialization to regenerate parity — which erases the array. If the files in those blocks matter, the only path back to them is reconstructing the array from drive images, where each member’s copy of the damaged region can be evaluated separately.

“Foreign drives cannot be imported as they don’t form a complete configuration.”

Risk: Level 3. MSM refuses an import because the drives present do not add up to a complete array in the controller’s view — a member is missing, or the firmware reads the metadata differently. One administrator saw this after swapping a failed 9260-8i for an identical model; the forum advice was to match firmware first. He eventually cleared the configuration and recreated his RAID 1 without initializing it, and noted that clearing and recreating will not always get the data back. For a mirror, that gamble has decent odds. For RAID 5, 6, 50 or 60, it rarely does.

MegaCLI: Safe Commands and Destructive Commands

MegaCLI is the command-line tool for this generation. These are read-only and safe to run on a failing array; save their output to another machine before anything changes: MegaCli -AdpAllInfo -aALL, MegaCli -CfgDsply -aALL, MegaCli -LDPDInfo -aALL, MegaCli -PDList -aALL, MegaCli -AdpEventLog -GetEvents -f events.log -aALL, MegaCli -AdpBbuCmd -aALL, MegaCli -GetPreservedCacheList -aALL, and MegaCli -CfgForeign -Scan -aALL (which only reports).

Command	What it does	Risk on a failed array
-CfgForeign -Import -aN	Imports the foreign configuration	Level 4 if members dropped out at different times
-CfgForeign -Clear -aN	Erases foreign configuration metadata	Level 4 — removes the array map
-PDMakeGood -PhysDrv[E:S] -aN	Unconfigured Bad → Unconfigured Good	Level 4 as part of a force/import sequence
-PDOnline -PhysDrv[E:S] -aN	Forces a drive online in its array	Level 4 — trusts stale data
-PDRbld -Start -PhysDrv[E:S] -aN	Starts a rebuild	Level 4 if survivors have media errors
-DiscardPreservedCache -Lx -aN	Throws away preserved cache	Level 4
-LDInit -Start [-full] -Lx -aN	Initializes a virtual drive	Level 4 — zeroes data
-CfgLdDel -Lx -aN	Deletes a virtual drive	Level 4
-CfgClr -aN	Clears the entire configuration	Level 4

Linux Kernel Messages (megaraid_sas)

SAS2108 cards are driven by the in-kernel megaraid_sas driver, which identifies the chip by PCI device ID 0x0079. The driver prints the controller’s own critical events into the kernel log in the form <sequence> (<timestamp>/0x<locale>/<CLASS>) - <description>, so the MSM event text above — including VD 00/0 is now DEGRADED — shows up in dmesg and syslog. The driver’s own messages, taken from the current kernel source:

“megasas: RESET cmd=… retries=…” / “reset successful” / “failed to do reset”

Risk: Level 2–3. A command timed out and the driver tried to reset the controller. One success is usually a transient; repeated resets point to a failing drive holding up I/O, a cabling or expander fault, or an overheating card. cannot recover from previous reset failures means the driver has given up.

“FW detected to be in faultstate, restarting it…”

Risk: Level 3. The controller firmware faulted and the driver is attempting an online controller reset (printed exactly like that, without a space, followed by FW restarted successfully,initiating next stage…). If it ends in adapter not ready, the reset failed.

“HBA is killed.” / “OCR failed and HBA is killed.” / “Controller in crit error”

Risk: Level 3. The driver has stopped using the controller after failed recovery attempts; the log may also show killing adapter scsiN disableOnlineCtrlReset …. Filesystems on the array will error out and the SCSI layer reports rejecting I/O to offline device. The controller, not necessarily the drives, is the failed component — protect the drives; do not move them to “any” replacement card.

“Waiting for FW to come to ready state” / “FW now in Ready state”

Risk: Level 1 if it completes. Normal during boot. If a boot hangs after the first line and never prints the second, the controller firmware is not coming up — often a hardware fault or a drive hanging discovery.

Battery, CacheVault and Firmware Notes

• Battery retention: the 9260’s iBBU07 is rated to hold cache for up to 72 hours; IBM rates the M5000 battery at up to 48 hours. After a longer outage, cached writes are gone.
• Learn cycles: LSI firmware 12.12.0-0111 (January 2013) lists a fix for firmware quiescing I/O when a battery learn cycle starts even in “write-back always” mode — a reminder that battery maintenance can stall a busy array.
• Old POST warnings: the same release lists a fix for a “Native configuration is no longer supported” message at POST, an example of how firmware level changes what administrators see during a failure.
• CacheVault: 9260CV cards replace the battery with a flash module (CVFM01) and 512 MB of non-volatile DDR2, so cache can survive long outages.

The SAS2108 Failure Patterns That Bring Arrays to a Lab

Four drives “failed” at once

One administrator came home to an alarming 9260-8i and found four of eight RAID 6 drives failed, now showing as (Foreign) Unconfigured Bad, behind an HP SAS expander. LSI support walked him through making each drive Unconfigured Good and rescanning, and the array came back. That worked because the drives had all dropped at the same instant from a path problem. The same steps on drives that failed one at a time over weeks produce corrupted data.

One drive drops, the whole virtual drive goes with it

Another owner, running an IBM M5014 (the 9260-8i’s twin) on SATA breakout cables, described a single drive dropping out and taking every drive in the virtual drive to foreign with it, every couple of weeks. Repeated make-good-and-import cycles kept the server running — until the cycle that coincides with a real drive failure.

The identical replacement that will not import

A 9260-8i dies, an identical card goes in, and the import fails with Foreign drives cannot be imported as they don’t form a complete configuration. Firmware is the usual suspect. The tempting shortcut — clear the configuration and recreate it without initializing — is a gamble that depends on reproducing the original parameters exactly.

The second drive during the rebuild

A RAID 5 loses a drive, a rebuild starts, and a second drive fails partway through. MegaRAID takes the virtual drive offline. The second drive is often only partially failed; cleanroom work on it, followed by offline reconstruction, is usually the difference between some data and all of it.

Punctures nobody noticed

A rebuild completes, the array reports optimal, and the event log quietly shows Puncturing bad block on PD. Months later a database or VM file hits the punctured region. The fix vendors recommend erases the array; the files in those blocks can often be recovered from images.

What to Do Right Now

1. Stop writing. If the volume is still online and degraded, copy the most important data off before any rebuild. If it is offline, shut down cleanly.
2. Capture the evidence. Photograph every POST and WebBIOS screen. If the OS is up, save the read-only MegaCLI output listed above and the full event log to another machine.
3. Record the physical layout. Label every drive with its bay, the controller connector and any expander or backplane position, and note serial numbers against the slot numbers in the event log.
4. Do not import, clear, force, initialize, flash or rebuild. Do not move drives to another controller or a PC.
5. Get an evaluation. Ship all the drives together. We do not need the server, and in most cases we do not need the controller.

How Gillware Recovers SAS2108 Arrays

We never run a failed MegaRAID array during recovery. Every member is logged by slot, serial number and firmware, then imaged on write-blocked hardware in our ISO 5 Class 100 cleanroom; drives with physical damage are repaired with donor parts first. The originals are shelved and all work happens on the images. Our in-house reconstruction software, HOMBRE, reads the MegaRAID metadata from every image, establishes member order, stripe size and parity layout, and identifies which members dropped out and when. Where the metadata was wiped by a clear or an initialization, the layout is derived from the file system structures across the images instead. The array is assembled virtually, without any controller, and the file systems on it are recovered from the assembled volume. More on our MegaRAID process is on our LSI MegaRAID recovery page and the RAID data recovery hub.

Every case starts with a free technical consultation with one of our enterprise storage engineers, and you approve all recovery fees in advance.

SAS2108 Model Pages

• LSI MegaRAID SAS 9260-8i (and 9260-4i, 9260CV, 9260DE) data recovery
• LSI MegaRAID SAS 9261-8i data recovery
• LSI MegaRAID SAS 9280 (9280-8e, 9280-4i4e, 9280-16i4e) data recovery
• IBM ServeRAID M5015 and M5014 data recovery
• Intel RAID Controller RS2BL080 and RS2BL040 data recovery

SAS2108 Manuals and Documentation

Document	What it covers
6Gb/s MegaRAID SAS RAID Controllers User Guide (41450-04 Rev. D)	Hardware for SAS2108 and SAS2208 cards: card layouts, connectors, battery mounting
MegaRAID SAS Software User Guide (Rev. I, June 2010)	WebBIOS, MegaCLI, MegaRAID Storage Manager, and the Events and Messages appendix
MegaRAID SAS 9260CV-4i / 9260CV-8i Quick Installation Guide	CacheVault models
IBM ServeRAID M5015 and M5014 Product Guide	IBM rebadges, feature key, supported System x servers
Intel RAID Controller RS2BL080 Technical Product Specification	Intel rebadge, cache and battery options
IBM: Recovering unrecoverable medium errors	Punctured-block events
Linux megaraid_sas driver source	Authoritative text of every driver message

Frequently Asked Questions

Should I press F to import the foreign configuration?

Only if every member dropped out at the same moment and every drive is healthy. If any drive failed earlier, import can combine stale and current data. When in doubt, image first.

My drives show (Foreign) Unconfigured Bad. Can I just make them Unconfigured Good?

If they all dropped at once from a cable, backplane or power event, that is the documented fix. If they dropped at different times, it is how arrays get corrupted. Record states and serial numbers before changing anything.

Is an IBM M5015 the same as an LSI 9260-8i?

Same SAS2108 chip, same 512 MB cache, different firmware package, and IBM requires its feature key for RAID 6 and 60. Arrays usually move between them, but not reliably enough to try on a degraded array.

What does “Puncturing bad block on PD” mean for my data?

The controller permanently blocked stripes it could not reconstruct. Files in those blocks cannot be read through the controller. Recovery requires imaging the drives and reconstructing offline.

Can I recreate the array without initializing to get my data back?

Sometimes, for simple mirrors, if every parameter matches. For parity arrays it is a single high-risk attempt that overwrites the original metadata. Images first.

Do you need my controller?

Usually not. Send every drive, labeled by bay. We reconstruct from drive images without a controller.

Start Your SAS2108 Recovery

If your MegaRAID SAS2108 array is offline, degraded with failing survivors, or showing messages you now recognize from the Level 3 and Level 4 lists above, power the server down and label the drives. Do not import, clear, force, initialize, flash or rebuild. Our engineers image every member and reconstruct the array without the controller.