ReFS integrity recovery

ReFS checksum errors can identify corruption without guaranteeing an alternate good copy exists.

ReFS uses checksums for metadata and can use integrity streams for file data. On redundant Storage Spaces, it may repair a bad copy from another; on nonredundant or multiply damaged storage, detection can leave files inaccessible.

Understand the symptom

Integrity metadata detects mismatches, while redundancy determines whether correction is possible.

WHY

What is happening

Checksummed blocks include metadata that points to the file-system tree and, when enabled, file content. Recovery must distinguish a logical checksum mismatch from unreadable media, identify all available replicas, and reconstruct the pool before interpreting ReFS structures.

What you may see

Symptoms that change the recovery path.

01

Integrity-stream checksum mismatch

Windows detects file content that does not match its stored checksum.

02

Volume mounts read-only or not at all

Critical metadata cannot be validated or repaired.

03

Scrub reports uncorrectable corruption

No trusted redundant copy was available for one or more blocks.

04

Storage Spaces is degraded

A missing member or enclosure problem reduces the replicas available to ReFS.

Protect the source

Actions that can make the situation worse.

01

Salvage can remove damaged namespaces

Making a volume mountable may exclude files or directories that cannot be validated.

02

Pool repair writes new state

Rebuilding a virtual disk can alter member metadata and consume remaining redundancy.

03

Media scans stress failing disks

Underlying weak sectors may worsen during exhaustive reads.

Do this now

Safe steps before evaluation.

01

Stop writes and maintenance

Pause scrub, repair, optimize, deduplication, backup, and application activity.

02

Preserve all pool members

Record serials, slots, virtual-disk layout, resiliency, column count, and failures.

03

Export Windows evidence

Save ReFS, Storage Spaces, System, and hardware events plus exact error output.

04

Image unstable devices

Acquire members independently before file-system reconstruction or repair.

NEPFOSYS process

How a data-first evaluation proceeds.

01

Storage-layer reconstruction

NEPFOSYS maps physical members, spaces, offsets, columns, and available replicas.

02

Checksum-aware analysis

ReFS metadata and integrity records are used to select consistent copies where available.

03

File validation

Recovered directories and priority files are checked from the protected reconstruction.

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.

Can ReFS always self-heal?

No. Correction requires a valid redundant copy; checksums alone only detect a mismatch.

Should I run refsutil salvage?

Not on the only copy. Salvage can change what is retained and should follow preservation and imaging.

Is this a file-system-only problem?

Not necessarily. Disk, controller, cabling, enclosure, or Storage Spaces failures can cause the bad reads.

DFW local · Nationwide mail-in

Protect the device. Start with the facts.

Start my recovery case