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 / vSAN: object inaccessible, reduced availability

Inaccessible · Reduced availability · Absent · Degraded · Active – Stale · VSAN.ClomRepairDelay · FTT · RAID-5 · RAID-6 · disk group

vSAN: object inaccessible, reduced availability. Objects, components and a sixty-minute timer, in Broadcom's own terms.

vSAN stores each virtual machine as objects, each object as components spread across hosts and disk groups according to its policy, and reports their health in terms Broadcom's knowledge base defines. Inaccessible: an object has suffered more failures, permanent or temporary, than it was configured to tolerate, and is currently unavailable. Reduced availability with no rebuild – delay timer: a component is absent and vSAN is waiting, by default sixty minutes, before rebuilding, the setting being VSAN.ClomRepairDelay and, from vSAN 6.7 U1, the cluster-wide Object Repair Timer. Reduced availability – active rebuild: the timer expired and the rebuild is running. Components are Active, Absent, Degraded or Active – Stale. Broadcom's KB 385514 gives the host minimums: FTT=1 with RAID-5 needs four fault domains or hosts, FTT=2 with RAID-6 needs six. What arrives here is a disk group whose cache or capacity device failed with objects on it that had nowhere else to be, a cluster that lost two hosts, or a repair that ran onto disks that then failed. The disk groups are imaged device by device and the objects reassembled from the images. A vSAN job is enterprise storage, £1,250 + VAT upwards after the free look, fixed in writing, 10–15 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 reset the hosts, do not remove and re-add disk groups, and do not run a full data migration or repair with a disk group showing errors. A rebuild reads every component on the survivors and writes to whatever is left. Export vSAN health, the object list and the component states, power down the affected hosts, and send every device from every affected disk group, labelled by host and slot.

Objects, components and disk groups, and what each state means for the data.

A virtual machine on vSAN is a set of objects: its namespace, its VMDKs, its swap, its snapshots. Each object is laid out as components according to its storage policy, mirrored across hosts for RAID-1, erasure-coded across four or six for RAID-5 and RAID-6, with witness components to break ties. A disk group on each host is one cache device and up to seven capacity devices, and a component lives on a capacity device in one disk group. When a device fails, every component on it is Degraded; when a host goes away, every component on it is Absent; a component that was absent and is back but behind the others is Active – Stale.

The health states follow. An object with enough components to satisfy its policy is healthy. One with a component absent is Reduced availability with no rebuild – delay timer, because vSAN waits before rebuilding an absent component in case the host returns; Broadcom's KB 327031 states the default is sixty minutes and names the setting VSAN.ClomRepairDelay, and from vSAN 6.7 U1 the same thing is set cluster-wide as the Object Repair Timer. When the timer expires the rebuild starts and the state becomes Reduced availability – active rebuild. An object with a degraded component rebuilds at once. And an object that has lost more components than its policy tolerates, two hosts in an FTT=1 cluster, a disk group and a witness, is Inaccessible: Broadcom's KB 326929 defines it as having suffered more failures, permanent or temporary, than it was configured to tolerate.

Inaccessible is where the bench starts. The components still exist on the capacity devices of the failed disk groups, in vSAN's on-disk format, and the objects are reassembled from them. Every device in every affected disk group is imaged, including the cache device, and the components read from the images with their metadata; the object is rebuilt from the components that are current, with stale ones used only where nothing else holds the block; the VMDK is extracted and its guest file system opened. The rebuild vSAN would have run reads the survivors under load and writes to whatever capacity is left, which on a cluster that has already lost two hosts is the wrong order.

What it says, and what it means.

Describe yours to us →
What you see The usual reason Where that leaves you
Reduced availability with no rebuild – delay timerA component absent; timer runningIf the host is coming back, wait; if not, image before the rebuild
Reduced availability – active rebuildRebuild running onto survivorsStop it if any survivor is weak
InaccessibleMore failures than toleratedEvery affected disk group imaged; objects reassembled
Active – Stale componentReturned behind the othersNot used as current; fills holes only
Disk group cache device failedEvery component in the group degradedThe group's devices imaged; components read
Cluster lost two hosts on FTT=1Objects inaccessibleBoth hosts' disk groups imaged

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

A vSAN disk group is imaged device by device, the cache device first, with the host and slot recorded for each, and the components on the capacity devices located from vSAN's on-disk metadata before anything is assembled. Devices with failed heads go to the clean bench first.

Sector by sector, weak areas lastThe first-dropped member included
03

The geometry, from the metadata or from the parity

Objects are reassembled from their components across the images: for RAID-1 objects, from the mirror components that are current; for RAID-5 and RAID-6 objects, from the erasure-coded components with the parity proving which are current and which stale. The VMDK is extracted from the object and its guest file system opened read-only.

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 sixty-minute timer is the clue. If a host is coming back, waiting is right; if it is not, the rebuild that follows is the risk.
  • Label by host and slot. A component's home is a disk group on a host, and the images are matched to it.
  • Export the object and component lists from vSAN health or RVC before the hosts are touched.
  • Two hosts lost on FTT=1 is the commonest case, and both hosts' disk groups are needed.

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

A four-host vSAN cluster on FTT=1 RAID-1 that lost a host to a failed motherboard and, forty minutes later, a capacity device on a second host, leaving a dozen objects Inaccessible

The failed host's two disk groups and the second host's affected group came in, sixteen devices labelled by host and slot. The failed capacity device had a head swap on the clean bench; the rest were imaged directly. The components were located from vSAN's metadata on the images, each object reassembled from its current mirror components with stale ones used only where nothing else held the block, and the twelve VMDKs extracted and their guest file systems opened. The cluster was resynced from the extracted disks.

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

What helps, and what harms.

Do this much first

  • Export vSAN health, the object list and component states
  • Power down the affected hosts
  • Send every device from every affected disk group, labelled by host and slot
  • Tell us the policy: FTT, RAID-1, 5 or 6, and the host count

What sets us back

  • Resetting hosts to see whether components come back
  • Removing and re-adding disk groups
  • Running a full data migration on a degraded cluster
  • Letting the repair timer expire into a rebuild onto weak devices

Questions answered before you commit.

What does vSAN object inaccessible mean?

In Broadcom's words, that the object has suffered more failures, permanent or temporary, than it was configured to tolerate. The components still exist on the failed disk groups' devices, and the object is reassembled from images of them.

What is the repair delay?

The time vSAN waits before rebuilding an absent component, sixty minutes by default, set by VSAN.ClomRepairDelay or the Object Repair Timer. If the host is coming back, waiting is right; if not, the rebuild that follows reads the survivors under load.

How many hosts does RAID-5 or RAID-6 need?

Broadcom's KB 385514: four hosts or fault domains for FTT=1 RAID-5, six for FTT=2 RAID-6. Fewer, and the object cannot be placed or rebuilt.

What does it cost?

vSAN is enterprise storage: from £1,250 + VAT after the free look, fixed in writing.

How long does it take?

10–15 days at the bench.

Where this usually leads.

VMware VMFS and vSAN →Hyper-V CSV and Storage Spaces Direct →Rebuild failed: a second drive went during it →RAID 6 →

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