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 / HP 1785, 1789, 1793 and 1831

1785 · 1789 · 1793 · 1797 · 1831 · c03925149 · a00074690 · a00053311 · firmware 6.88

HP 1785, 1789, 1793 and 1831 drive array messages. Not configured, not responding, and write-back cache lost: HPE's advisories, and what each one leaves on the drives.

Besides 1779, four Smart Array POST messages bring arrays here. 1785 Drive Array not Configured says the configuration on the drives was written by a controller with a newer firmware version, and HPE's own text says to reattach the drives to the original controller or upgrade the firmware to avoid data loss. 1789 Disk Drive(s) Not Responding follows a service event where SAS cables were reconnected to different ports, and HPE advisory c03925149 warns of possible data loss if the cabling is not restored. 1793 Data in Write-Back Cache has been Lost and 1831 Data in Write-Back SmartCache has been lost mean writes the controller had acknowledged never reached the drives; HPE advisory a00053311, first published 8 August 2018, described 4GB cache modules on P440, P441, P840 and P841 controllers becoming permanently disabled after a firmware upgrade, with the fix in Smart Array firmware 6.88, and a00074690 described 1831 on Gen9 controllers after a power-button shutdown during POST. Each of them leaves the data on the drives in a known state, and none of them is improved by pressing on. 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 upgrade the firmware on a controller showing 1785 until the drives have been imaged, and do not recreate the configuration. On 1789, restore the cabling exactly as it was before anything else. On 1793 and 1831, the cache is gone; what matters is that nothing else is written. Photograph the message, export the log, power down.

What each message means, in HPE's words, and what is on the drives afterwards.

1785. The text is 1785-Slot 0 Drive Array not Configured. Configuration information indicates drives were configured on a controller with a newer firmware version. To avoid data loss, reattach drives to original controller or upgrade firmware. The configuration on the drives is intact and the controller cannot read it, because the RIS format moved on. The right move is a controller on matching firmware, or the bench, which reads the RIS from the images regardless of what the card can parse. The wrong move is to let the controller create a new configuration on drives it calls unconfigured.

1789. HPE advisory c03925149 is titled for the customer action required to reconnect all SAS cables after a service event, to avoid a 1789-Slot 0 Drive Array Disk Drive(s) Not Responding message and possible data loss. Cables swapped between ports change which drives the controller finds where; a logical drive whose members are on the wrong ports is reported as drives not responding, and the fix is the cabling, not the drives. Advisory a00104843 covers the related 1716 and 1915 messages on Gen8, Gen9 and Gen10 controllers, where SSA reports unrecoverable media errors detected during a previous rebuild or background surface analysis.

1793, 1797 and 1831. A Smart Array with write-back caching acknowledges writes when they reach its cache module and writes them to the drives afterwards; the battery or capacitor is there to hold the cache through a power loss. When the module fails, or the power is lost with the battery flat, the writes in it never reach the drives, and at the next POST the controller says so: 1793 Data in Write-Back Cache has been Lost, 1797 Write-Back Cache Restore Previously Failed, caching is disabled, 1831 Data in Write-Back SmartCache has been lost. HPE's advisory a00053311 described 4GB cache modules on P440, P441, P840 and P841 controllers becoming permanently disabled after a Smart Array firmware upgrade from 4.52 or earlier to 4.60 or later, first published 8 August 2018 with the fix in firmware 6.88 on 15 August 2019, and HPE's own instruction for a system that had already shown 1793, 1797 or 1831 was to upgrade the firmware and restore the data from a backup. The data that was in the cache is gone; the data on the drives is whatever was written before it, and the file system on top has lost its most recent writes, which on NTFS or ReFS is a journal replay and on a database a log job.

What it says, and what it means.

Describe yours to us →
What you see The usual reason Where that leaves you
1785 not Configured, newer firmwareThe RIS on the drives is a newer formatMatch the firmware, or image and read the RIS on the bench; do not reconfigure
1789 Drive(s) Not Responding after serviceSAS cables on the wrong portsRestore the cabling; do not accept a degraded set
1793 Write-Back Cache LostCache module or battery failedThe cached writes are gone; the volume needs its journal replayed on images
1797 Cache Restore Previously FailedAs above, caching now disabledSame; check the file system before writing more
1831 SmartCache lost (Gen9)Power button during POST (a00074690)As for 1793
Cache module disabled after upgradea00053311; 4GB modules, 4.52 to 4.60+Firmware 6.88; data from the cache is gone

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

A Smart Array set is read from its RIS metadata on the images, whatever firmware wrote it. Where write-back cache was lost, the set is assembled and the file system's journal replayed on a copy of the virtual volume, so that the writes the controller acknowledged and never made are accounted for rather than guessed at.

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

  • 1785 is the controller being unable to read a newer format, not the drives being blank. Do not let it configure them.
  • 1789 after a service visit is the cabling. Every SAS cable back on the port it came from, before anything else.
  • 1793 and 1831 mean the cache is gone, and the volume's most recent writes with it. The file system is checked on images, not with chkdsk on the originals.
  • HPE's advisory numbers are the citation. Quote them when you ring the vendor; the bench quotes them on the report.

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

A DL380 Gen9 with a P440ar showing 1793 after its cache module failed, a SQL Server database that would not start, and an engineer who had already run chkdsk on the volume

The six drives came in with the controller. The set was assembled in software from the images and the NTFS volume examined on a copy: the lost cache had taken the last few seconds of writes, and chkdsk had then rewritten the MFT around the gap. The journal was replayed on the virtual volume, the database's transaction log used to recover it to its last consistent point, and the volume copied out with a list of the files chkdsk had truncated.

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

  • Photograph the POST message
  • Export an SSA diagnostic report
  • Restore any cabling changed during service
  • Power down; send every member and the controller

What sets us back

  • Upgrading firmware on a 1785 controller before imaging
  • Letting the controller configure 'unconfigured' drives
  • Running chkdsk after a cache loss
  • Accepting a degraded set on 1789 instead of fixing the cabling

Questions answered before you commit.

What does HP 1785 mean?

That the configuration on the drives was written by a controller with newer firmware than this one runs. The data is intact; the controller cannot read the description. Match the firmware or have the set read on the bench.

What does 1793 Data in Write-Back Cache has been Lost mean?

That writes the controller had acknowledged never reached the drives, because the cache module or its battery failed. The data on the drives is what was written before; the file system needs its journal replayed.

Is the data gone after advisory a00053311?

The data that was in the cache is. The data on the drives is intact. HPE's own instruction was firmware 6.88 and a restore from backup; the bench assembles the set and recovers what the backup lacks.

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 1779: replacement drive(s) detected →Preserved cache and cache data lost →HPE Smart Array →Virtual disk failed or offline →

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