Dell PERC puncture recovery

A Dell PERC puncture records a double fault in a stripe; restoring array optimal status does not recreate the data already lost there.

Dell describes a puncture as a rebuild-with-errors condition caused by inaccessible data in more than one member location within the same stripe. The virtual disk may later appear optimal while files or filesystem metadata remain damaged.

Understand the symptom

Parity can correct one unavailable block per RAID 5 stripe, but a same-stripe double fault removes information.

WHY

What is happening

PERC logs can distinguish media errors, predictive failures, rebuild events, and punctured LBAs. The impact depends on where those LBAs fall: unused space, ordinary file content, or critical filesystem and database metadata. Recovery preserves the controller configuration and members, then correlates stripe damage with logical structures.

What you may see

Symptoms that change the recovery path.

01

Controller log reports puncture

PERC recorded a stripe that could not be reconstructed cleanly.

02

Rebuild completed with errors

Redundancy returned, but unreadable source blocks were propagated as missing data.

03

Filesystem checks report corruption

Punctured LBAs may intersect allocation, directory, journal, or database pages.

04

Drive shows predictive failure

Media errors or propagated puncture state may accompany hardware warnings.

Protect the source

Actions that can make the situation worse.

01

Check Consistency can write parity

On an unprotected damaged array, correction may commit assumptions over evidence.

02

Virtual-disk recreation destroys metadata

Deleting and rebuilding the array changes controller state and may initialize data regions.

03

Replacing every flagged disk loses context

Original members and logs are needed to determine the double-fault timeline.

Do this now

Safe steps before evaluation.

01

Export the PERC controller log

Save event history, virtual-disk properties, member states, stripe size, firmware, and puncture details.

02

Preserve all array members

Label bays, serials, failed disks, replacements, and hot spares without clearing foreign state.

03

Stop consistency and rebuild tasks

Do not start patrol read, check consistency, initialization, or another rebuild on the only copy.

04

Identify critical workloads

List filesystems, VMs, databases, and the time window when errors began.

NEPFOSYS process

How a data-first evaluation proceeds.

01

Controller-event analysis

NEPFOSYS maps punctures, media errors, member transitions, and RAID geometry.

02

Member imaging

Each readable disk is preserved with bad regions recorded by LBA.

03

Stripe and filesystem reconstruction

Affected stripes are correlated with logical structures and priority data is validated.

A clear next step

Preserve the original device before another repair or recovery attempt.

Start a case with the exact symptoms, incident timeline, prior attempts, encryption details, and the files that matter most. NEPFOSYS will route the case to the appropriate DFW intake or nationwide mail-in path.

Start with a case review

Questions, answered

What customers ask before starting.

Is a punctured array still recoverable?

Often some or most data remains readable, but data in double-faulted stripe locations may be incomplete.

Will Check Consistency restore missing file content?

It may restore parity consistency, but it cannot recreate information lost when two stripe blocks were unavailable.

Can I discard the failed disks after rebuild?

No. Preserve them until recovery and validation are complete; they may contain readable data missing elsewhere.

DFW local · Nationwide mail-in

Protect the device. Start with the facts.

Start my recovery case