Ransomware attackers specifically target and attempt to destroy backup systems to increase the probability of payment. Hardening your system is critical. Please ensure you have reviewed your platform security using the Security Hardening Checklist
Cohesity

COHESITY Documentation

Explore our documentation to get started, discover products & new features, access troubleshooting guides, register sources, platforms support.

Products
Data Security Alliance
Visit Cohesity.com
Demos
Support
Blogs
Developers
Partner Portals
Cohesity Community
© 2026 Cohesity, Inc. All Rights Reserved.
Terms of Use|
Privacy Policy|
Legal|
  1. Home
  2. NetBackup™ Release Notes
  3. Operational notes
  4. NetBackup Bare Metal Restore operational notes
  5. BMR Restore Failure for ReFS Volumes on Windows (2016 - 2025)
NetBackup™ Release Notes

BMR Restore Failure for ReFS Volumes on Windows (2016 - 2025)

Cause

During a Bare Metal Restore (BMR) on Windows Server 2016, 2019, 2022, or 2025, ReFS volumes fail to restore and appear in an "Unformatted" state.

This occurs because no version of ADK/WinPE supports bare‑metal or block‑level restore of ReFS volumes, due to incompatibilities between ReFS versions.

ReFS Versions Used in Installed Operating Systems

Table:

Windows Version

ReFS Version

Windows Server 2016

3.1

Windows Server 2019

3.4

Windows Server 2022

3.7

Windows Server2025

3.14

ReFS Version in SRT / WinPE Environment

Table:

Environment

ReFS Version

SRT / ADK WinPE

3.9

Important Compatibility Note

The WinPE ReFS driver (3.9) cannot be downgraded or made backward compatible with OS‑specific ReFS versions (3.1, 3.4, 3.7, 3.14).

Microsoft provides no workaround for this downgrade limitation.

As a result:

  • Restored ReFS volumes appear Unformatted

  • The target OS cannot read WinPE‑created ReFS 3.9 metadata

  • The volume becomes unusable after BMR restore

Cause

ReFS versions are not backward compatible at the metadata level.

Key Rules:
  • A lower ReFS driver cannot recreate or replay metadata from a higher version

  • WinPE's ReFS driver is read‑mostly, not designed for reconstruction

  • BMR restore requires metadata replay, allocation maps, and integrity stream handling - operations that fail on version mismatch

Compatibility Matrix

All combinations below fail due to version mismatch:

Table:

Source Volume (ReFS)

Target OS

WinPE ReFS (3.9)

Result

3.14 (Windows 2025)

Server 2025

3.9

Fail

3.7 (Winodws 2022)

Server 2022

3.9

Fail

3.4 (Winodws 2019)

Server 2019

3.9

Fail

3.4 (Windows 2016)

Server 2016

3.9

Fail

Why it fails:
  • WinPE cannot create the required ReFS metadata structures

  • Version mismatch prevents metadata replay

  • Restore tools fall back to unsupported APIs

Solution

There is no direct solution.

Microsoft has not provided any method to upgrade or downgrade ReFS versions during BMR workflows.

Workaround

To ensure ReFS volumes are restored with the correct 3.x version matching the original operating system, perform the following steps:

  1. Right‑click the BMR configuration and create a copy using New Client Configuration.

  2. Edit the copied configuration and exclude all ReFS volumes from volume mapping.

  3. Run Prepare to Restore and proceed with the system restore.

  4. After the machine boots into the restored operating system:

    • Create the ReFS volumes excluded in step 2

    • Format them using Disk Management or DISKPART

    • Windows will automatically create the ReFS volume using the correct version for that OS

  5. Verify the ReFS version using: fsutil fsinfo refsinfo <DriveLetter:>

  6. Restore the data for these volumes from Recovery tab in NetBackup Web UI.

Feedback

Was this page helpful?
Previous

Mirrored dynamic volume may not receive a drive letter after Windows BMR DDR restore

Next

Post Bare Metal Restore (BMR) operation, windows Start Menu and Search not functioning

Feedback

Was this page helpful?