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 / Preserved cache and cache data lost

Preserved cache · pinned cache · Cache data lost · Dirty cache · BBU · CacheVault · storcli /c0/vall show pc

Preserved cache, and cache data lost. Writes the controller promised and never made. Keep them and it will not boot; discard them and they are gone.

A RAID controller with write-back caching acknowledges a write when it reaches the controller's memory and commits it to the drives afterwards, with a battery or a CacheVault capacitor to hold the memory through a power loss. When a virtual disk goes offline with writes still in the cache, because too many members dropped or the set was pulled, a PERC or MegaRAID keeps those writes as preserved or pinned cache and refuses to bring the virtual disk back, or in some firmware to boot at all, until they are either written or discarded. Cache data lost, and the Dirty cache warnings, mean the battery could not hold them and they are already gone. The discard is the offer that costs: it throws away the last seconds of writes, and on a file system that is a journal with a gap and on a database a log with a hole. The right order is to image the members first and account for the missing writes on a copy. 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 discard the preserved cache to make the controller boot, and do not force the virtual disk online to flush it. Both write, or throw away, the last writes the file system believes were made. Photograph the message, export storcli /c0 show all if you can, power down, and send the members.

What is in the cache, what each choice does, and how the file system is squared afterwards.

Write-back caching is why a RAID controller feels fast: the operating system is told the write is done the moment it lands in the controller's memory, and the controller writes it to the drives in its own time, protected by a battery-backed unit or a flash CacheVault. When the virtual disk those writes were for goes offline, the controller cannot commit them and it will not silently drop them, so it marks them preserved (PERC) or pinned (MegaRAID) and holds them, refusing to bring the virtual disk back or, on some firmware, to complete POST until told what to do. storcli /c0/vall show preservedcache lists them; storcli /c0/vall delete preservedcache discards them.

Discarding is the usual advice on the forums and often in the vendor's own procedure, because the alternative is to bring the virtual disk back with every member present so that the cache flushes to it, and the virtual disk went offline precisely because the members are not all present. The discard is not the end of the world; it is the last few seconds or minutes of writes. But the file system on top acknowledged those writes to its applications, and its journal and its metadata expect them to be there. NTFS and ReFS replay their journals and lose the files those writes were for; a database's log has a gap; a virtual machine's disk has a torn write in it. Cache data lost means the same writes went when the battery could not hold them, without anyone being asked.

On the bench the members are imaged and the set assembled in software, and the file system is examined on a copy of the virtual volume for exactly the gap the lost cache left: a journal that stops short, metadata that describes blocks never written, a database whose log ends before its last checkpoint. The repairs are made there, with the file list showing which files were touched by the gap, and the originals are not written to. The controller's preserved cache is then a question you can answer from a position of having a copy.

What it says, and what it means.

Describe yours to us →
What you see The usual reason Where that leaves you
Preserved cache for an offline virtual diskMembers dropped with writes pendingDo not discard; image the members; bring the set back with all present, or assemble from images
Controller will not boot: pinned cacheFirmware waiting for a decisionPhotograph; power down; the bench decides on images
Cache data lost after a power cutBattery or CacheVault flatThe writes are gone; journal replay on images
Dirty cache warning on a running setBattery failing; write-back still onSwitch to write-through; replace the battery
Discarded already; volume corruptThe gap in the journalImage; repair on the virtual volume
Forced online to flushStale or unreadable member servingStop writing; image everything

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

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
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

  • The discard is a decision you can make later, with a copy in hand. It cannot be unmade.
  • Write-through until the battery is replaced. A failing BBU with write-back on is a cache loss waiting for a power cut.
  • Say what was running. A database, a virtual machine, a file share: each loses the gap differently, and each is repaired differently.
  • Export storcli /c0 show all or the PERC log before the decision; it records what was pinned and for which virtual disk.

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

A MegaRAID 9361-8i whose RAID 5 went offline when a backplane dropped three drives, holding a Hyper-V host's CSV, with pinned cache and a controller that would not boot

The owner did not discard it. The eight drives came in; the backplane fault had dropped three healthy members at once and the set's DDF metadata was intact. The set was assembled in software from the images and the CSV volume examined on a copy: the pinned cache had held the last seconds of writes to two virtual machines' VHDX files. Their guest file systems were repaired from their journals on extracted copies, and the host's volume went back complete but for those seconds.

99.99% of the CSV recovered9 days here, and back by post
Illustrative example — replace with a genuine case

What helps, and what harms.

Do this much first

  • Photograph the message and export the controller log
  • Power down without answering the prompt
  • Send every member, and the controller with its cache module
  • Say what was running on the virtual disk

What sets us back

  • Discarding preserved cache to get the controller to boot
  • Forcing the virtual disk online to flush it
  • Running chkdsk after a discard
  • Leaving write-back on with a failing battery

Questions answered before you commit.

What is preserved cache?

Writes the controller acknowledged and could not commit because the virtual disk went offline. It holds them and waits to be told to write or discard them.

Should I discard it so the server boots?

Not before the members are imaged. The discard throws away the last writes the file system believes were made, and it cannot be undone. With a copy in hand, it becomes a decision rather than a loss.

Cache data lost: is the data gone?

The writes in the cache are. The data on the drives is what was written before them. The file system's journal is replayed on images and the gap accounted for.

What does it cost?

£500 + VAT upwards for a set of two to four members after the free look, fixed in writing.

How long does it take?

5–10 days at the bench.

Where this usually leads.

HP 1785, 1789, 1793 and 1831 →Virtual disk failed or offline →Broadcom MegaRAID and ServeRAID →Hyper-V CSV and Storage Spaces Direct →

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 jobPacking and posting