The RAID Battery Failed After a Power Cut. Don't Force the Array Online.

Written and maintained by the Desert Data Recovery lab team. · Updated September 25, 2026

We already wrote about a controller Rebuild, about a RAID 5 that loses a second drive, and about a Synology NVMe write-back cache that died. This page is the card in the server. Dell PERC, HPE Smart Array, Broadcom MegaRAID, Adaptec, and the same family of hardware RAID controllers. The cache is on the controller. The battery — or the capacitor and flash module that replaced it — is what was supposed to protect that cache when the power died. Do not force the virtual disk online while that state is unknown.

What write-back cache and the battery actually do

A hardware RAID controller sits between the operating system and the member disks. In write-back mode it acknowledges a write when the bytes are in the controller's own memory, then flushes them to the disks later. Until that flush, the cache is dirty. The operating system has been told the write is safe. The platters or the SSD NAND may not have it yet.

Write-through is the other policy. The controller acknowledges the write only after the members have it. A power cut in write-through does not leave a pile of acknowledged writes sitting only on the card. Write-back does. Controllers switch to write-through on their own when the battery will not hold a charge, when a learn cycle is running, or when someone set the policy that way. The policy you had at the moment of the outage is the one that matters, and a screenshot taken the next morning may already show write-through because the pack failed.

The battery backup unit is there for the dirty cache, not for the server as a whole. Vendors name the pack differently. You will see BBU, cache battery, BBWC, a supercapacitor, CacheVault, or flash-backed write cache (FBWC). An older pack keeps the DRAM powered until mains power returns and the controller can destage. A flash-backed module uses a few seconds of capacitor energy to copy that DRAM into NAND on the cache module, then copies it back on the next boot and writes it to the disks. Different hardware. The same job. Those blocks are not on the member disks yet.

A learn cycle is the controller testing the pack — discharge, then charge — to see whether it can still hold the cache. Many cards fall back to write-through for the duration. A learn that fails, or a pack that will not charge after a deep discharge, shows up as failed, missing, degraded, or learning. That line is about the pack. It does not tell you whether dirty blocks are still in DRAM, already in the flash backup, already destaged, or already gone. Read the cache line separately. If the screen says preserved cache, pinned cache, or cache data lost, that line is the one to believe. If it says nothing about cache contents, treat the cache state as unknown.

What the controller shows after the power comes back

The POST screen, the controller BIOS, MegaRAID Storage Manager, Dell OpenManage or iDRAC, HPE Smart Storage Administrator or iLO, or Adaptec maxView will usually show a mix of these. The wording is not exclusive to one vendor. The action behind the wording is what matters.

• Battery, capacitor, or BBU: Failed, Missing, Degraded, Learning, or a replace warning
• Cache: disabled, write policy forced to write-through, preserved cache, pinned cache, or a line that cache data was lost
• Virtual disk or logical drive: Offline, Degraded, Failed, or Foreign
• Physical disks: Failed, Unconfigured, Foreign, or already Rebuilding
• A prompt: Import foreign configuration, Clear foreign configuration, Discard preserved cache, Force Online, Bring Online

Power loss plus write-back means the controller may still hold unflushed writes. The members can also disagree with each other. A stripe that was only partly destaged leaves data blocks and parity that no longer match. A disk the controller failed because it was slow to spin up may hold an older copy than the disks that stayed up. Force Online does not sort those versions out. It picks a path and commits it: destage the cache onto the disks, or drop the cache and present whatever the disks already have. Then the operating system mounts that result and writes.

Force Online commits one version of the volume

Force Online and Bring Online mark a virtual disk, or a physical disk the controller had failed, as usable again. If preserved or pinned cache is still on the card, bringing the volume up is how that cache gets written to the members. MegaRAID's name for dirty cache stuck to an offline virtual disk is pinned cache. Deleting it, or accepting Discard preserved cache on a PERC, throws away writes the operating system was already told had landed. The disks do not grow a copy of those blocks because the warning cleared.

If the message is the other one — cache data lost — the unflushed writes are already gone from the card. Forcing the virtual disk online will not recreate them. It presents a volume that stopped mid-stripe, and the boot that follows writes on top of that. Journal replay, a database crash recovery, and a filesystem check are all writes. A volume that "came up so we could copy the files" is a volume the controller and the operating system are both changing.

A member that dropped in the outage and is then forced online is a disk the controller had stopped trusting. Forcing it back and starting a rebuild writes reconstructed stripes across the set. That is the same write as a Rebuild, from a worse starting point: the other members may be missing the last flush, or they may disagree with cache the card has not destaged. On RAID 5, a second member that will not read is already past what the level survives. That case is two drives failed, and a rebuild does not undo it.

Clear Foreign Configuration deletes the array metadata the disks are carrying: RAID level, which member is which, stripe size. User data is not securely wiped by that click. The map you needed is gone, and the next screen is usually create a new virtual disk. Import Foreign loads that metadata into the controller. Import is the right step only when the foreign view is this array and you already know whether preserved cache will be kept, destaged, or dropped. Importing because the prompt appeared, with the cache state unknown, can commit or discard that cache as the volume comes up. Other cards do not all say "foreign." Clearing the configuration, or creating a new logical drive on the same disks, is the same class of action.

What not to click

Force Online or Bring Online on the virtual disk or on a failed member, to see if the data is there. You just chose a commit or a discard, and then a mount.

Discard preserved cache, or delete pinned cache, to get past the boot warning. That menu exists so the card will continue. It drops the only copy of blocks that had not reached the disks.

Clear Foreign Configuration when the data matters. You are deleting the label on the set. Import Foreign without reading the cache line first is the other experiment. Leave both alone until someone who can image the disks has the screenshots.

Replace the battery, then immediately force the virtual disk online and let the server boot. A new pack does not contain the old cache. It often will not even enable write-back until it has charged. The boot writes new blocks over members that may still be missing the last flush.

Rebuild before any image exists. The controller reads every surviving member and writes the replacement. If one of those members is marginal, or the stripe was only partly flushed, the rebuild overwrites the last good copy. That is the failure the rebuild post is about.

A consistency check that corrects, or a patrol read that remaps. A corrective consistency check writes parity or data to make a stripe agree with itself. After a dirty-cache outage, the "error" it corrects can be the only remaining copy of a block. Patrol read is a media scan; when it hits a bad sector, the disk remaps and the controller may rebuild that stripe. Both are writes. Hours of extra head time on disks that just lost power is its own cost, even on a check that only reads. Do not start one to make the controller status green.

Initialize, Full Init, or Quick Init. A full initialization writes the virtual disk. On PERC and MegaRAID, Fast Initialization overwrites the first and last 8 MB — the partition table and the copy of it at the end — and a background initialization then writes parity across the set. That is the map, and then a second write. It is not a label you can put back.

Create a new virtual disk on the same physical disks. New array metadata, and usually an initialization, land on the only copies you have.

Power-cycle the server to see if the next boot offers a kinder prompt. Each cycle is another chance to accept Discard, and another spin-up of disks that just went down hard. If a member is clicking, extra power-ons are head time. See what a clicking drive means.

This is the controller, not a Synology cache SSD

The Synology NVMe write-back post is a different device. That cache is an M.2 SSD in the NAS. DSM writes to the stick first and flushes to the hard drives later. The button people reach for is Repair. This page is the RAID card: DRAM on the controller, a battery or a capacitor-and-flash module beside it, and a virtual disk that went offline when the power died. Do not pull a Synology Repair procedure and aim it at a PERC, and do not Force Online a Smart Array because a NAS article said to leave the volume alone.

A Synology volume that says Crashed, with or without a cache SSD, is that post. Unraid and TrueNAS have their own destroy-and-recreate buttons. A motherboard stripe with no battery-backed cache at all is RAID 0. If the screen in front of you is iDRAC, iLO, MegaRAID Storage Manager, or the controller BIOS, you are in this one.

What to do right now

Do not force the virtual disk online. Do not clear or import a foreign configuration. Do not discard the cache. Do not rebuild. Do not initialize.

1. If you are looking at Discard preserved cache, Force Online, or Clear Foreign, do not accept it. Power the server off from that screen. A clean shutdown is the right call when the operating system is up, the volume is serving files, and no disk is clicking — that is a flush you still control. A clicking member, or a rebuild already running, is a reason to power down rather than let the write finish.
2. Photograph the screens before anything changes. Controller BIOS, MegaRAID Storage Manager, iDRAC, iLO, Smart Storage Administrator, the POST lines. You want the exact words: battery or capacitor status, write policy, preserved cache, pinned cache, or cache data lost, virtual-disk state, foreign, and which bay is failed. Screenshots help. They are not a diagnosis.
3. Write down the array: RAID level, how many disks, bay order, which bays are failed, foreign, or rebuilding. Do not pull disks to try a different order. If they have to come out, label the bay on the drive before it leaves the slot.
4. Leave the controller with the set when the screen says cache is preserved or pinned. Those blocks are on the card or its cache module, not on the members. Discarding the cache to make the card easier to ship drops them. A failed battery pack is part of the same hardware. Leave it attached.
5. Stop power-cycling. The next boot is not a second opinion. It is the same prompt, plus another spin-up.

Pack the disks the way you would any failed drive — how to ship a failed drive safely. A server chassis can ship if you cannot pull the set cleanly. Do not open a drive to look at it. Then talk to a lab before anyone forces the array online.

How a lab handles it

We do not Force Online, Bring Online, Clear Foreign, Import, Initialize, or start a rebuild on your controller to see if the volume mounts. We do not discard preserved cache to get past the prompt.

Bay order is recorded before a disk leaves the chassis. Each member is imaged write-blocked — a sector image, including a drive that only reads in pieces — before the controller is asked to change state. Imaging uses the lab tools already named on this site, including the ACE Lab PC-3000 and DeepSpar Disk Imager. Work happens on the copies. RAID level, member order, stripe size, and parity are reconstructed from those images. A wrong guess on a copy can be thrown away. The same guess on the original disks cannot.

Preserved cache still on the controller is not a disk image. It is a separate set of blocks that may never have reached the members. We will not describe a DRAM-dump procedure here, and we will not promise the cache module reads. If that cache was discarded before the machine reached us, the unflushed writes are not on the disks. We will tell you what the images hold. A hole in the parity or a missing journal is still a hole. We will not promise a mount.

The public case log has no battery-backup, preserved-cache, or force-online job. We will not invent a case ID, a controller model, or an outcome. The closest published hardware-controller cousin is 21607: twelve HPE 1.8 TB SAS drives on one SmartArray, a five-drive RAID 5 whose problem was the controller dropping offline, and a seven-drive RAID 6 that had lost three members, some of them months earlier. Three of those RAID 6 members needed head swaps before they would read. Nothing was rebuilt on the original hardware. The controller was taken out of the equation. Every member was imaged, and the arrays were reconstructed from the images. Full recovery on that set. The write-up does not mention a battery, preserved cache, or Force Online. That outcome belongs to that set.

The other published array in the log is a different stack: DDR-2026-0003, a four-drive Synology RAID 5, two members failed, nothing rebuilt in the NAS. That is a NAS and a two-disk RAID 5 loss, not a controller battery. Neither job is a rate, and neither is a prediction about dirty cache on the card in front of you. We don't advertise a success rate.

If the screen is a Rebuild on an array that is still online and healthy apart from one disk you have already replaced, start with rebuild vs. recovery — that is the case where a normal rebuild can be the right maintenance step. If two RAID 5 members are down, the limit is that post. For how these cases run once the disks are here, see RAID data recovery.