Share via

DFS replication and HDD failure - assistance needed

Researcher 51 Reputation points
2025-08-18T10:44:05.2433333+00:00

Hello everyone,

We are currently considering to set up DFS replication for a Windows Server 2019 Standard PC in our environment. Our client PCs use this server to connect to all our applications. (Please refer to the ‘Notes’ later in this post why we’re not going for Storage Replica and sticking with DFS-R)

We need assistance in knowing whether DFS replication could satisfy the following criteria:

A) In case of data HDD failure of our primary server ( let us call it PC-1) due to the Hard disk (HDD) such as HDD not detecting, disk corruption etc. , we would like to pause/stop the DFS replication, and physically pull out the HDD from the secondary server ( say PC-2) so as to replace the existing HDD in the first server (PC-1) to connect to the applications and retaining the NTFS file permissions. Is this doable in DFS-R setup ?

B) In case of failure of the primary server (PC-1) due to any reasons other than the HDD, such as OS not booting etc., we would like to pull out the data HDD from this primary server and connect to the secondary server (PC-2), rename this secondary as PC-1 and start using it to connect to the applications and retaining the NTFS file permissions.

Please let us know whether DFS replication would be okay for the above requirements. We are fine with around 10-15 minutes of downtime for any related tasks such changing the PC name, DNS entries etc., as long as either/both (A) or (B) works. If there is any other better method then do let us know.

Notes:

  1. Storage Replica is not suitable for our use case in Windows Server 2019 Standard, due to the limitation of only 1 replica partnership ( i.e Volume) with size of max 2TB. We have multiple volumes in the server, and upgrading to Datacenter is expensive for us.
  2. We understand DFS replica would take care of the "fail-over’ part as the DFS cluster would switch replication to either of PC-1 or PC-2 upon failure, but we need to give the virtual cluster a totally different name, such as PC-3 (correct me if I am wrong?). This would not be possible for us so we would like to retain the application connectivity to “PC-1” as the server and not through any other name. The reason to go for a replication route, rather than a ‘manual backup and restore’ is to reduce operations downtime.
  3. For us, the file data is more important than OS drive or OS data. The secondary server in our case would be having the same OS, processor, memory as that of the primary and we are considering DFS-R for the filesystem recovery
  4. The server and our client PCs are all hosted on premises. We do not have any Azure VM or any cloud PCs involved. (P.S: We are aware of DFS replication limitations, such as limitations in replicating locked files, not being able to replicate VSS copies, ‘Shared’ file permissions as it works on file level and not volume level etc.)

We have been doing research for a while now and have done an elaborate comparison with Storage replica and by DFS it seems the core logic for file replication is based on the ‘DFS Namespaces’, which enable to route request to files to either or one among many servers in the replication cluster, when the primary server is down. We have covered several YouTube videos, tech blogs and Microsoft documents but did not find answers to our requirements.

Thanks.

Windows for business | Windows Server | Directory services | Other

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Quinnie Quoc 7,625 Reputation points Independent Advisor
    2025-08-19T08:39:48.57+00:00

    Hello,

    Thank you for the detailed overview and thoughtful consideration of your environment and requirements. Based on your outlined use case and constraints, I’ve reviewed the feasibility of using DFS Replication (DFS-R) on Windows Server 2019 Standard to meet your goals. Below is a breakdown of your two key scenarios and how DFS-R aligns with them.

    🅰 Scenario A: HDD Failure on Primary Server (PC-1)

    You’re asking whether, in the event of a data HDD failure on PC-1, you can:

    • Pause DFS replication
    • Physically remove the replicated HDD from PC-2
    • Install it into PC-1
    • Resume operations with NTFS permissions intact

    DFS-R Considerations:

    • NTFS Permissions: Yes, NTFS file-level permissions are preserved on replicated volumes and will remain intact when the disk is moved.
    • Replication Pause: You can pause or disable DFS replication using PowerShell or the DFS Management Console before removing the disk to prevent sync conflicts.
    • Disk Swap: Physically moving the disk is technically feasible, but it’s important to ensure:
      • The disk is healthy and not mid-replication
        • The volume mount point and drive letter match the original configuration
          • DFS-R database integrity is not compromised during the move

    ⚠️ DFS-R is not designed for disk-level failover or hot-swapping. Manual intervention is required, and care must be taken to avoid triggering unexpected replication behavior.

    🅱 Scenario B: OS Failure on Primary Server (PC-1)

    You’re asking whether, in the event of OS failure on PC-1, you can:

    • Move the data HDD from PC-1 to PC-2
    • Rename PC-2 to PC-1
    • Resume application connectivity with NTFS permissions intact

    DFS-R Considerations:

    • Disk Move: Yes, NTFS permissions will remain intact when the disk is moved.
    • Renaming PC-2: Renaming the server to match PC-1 is possible, but:
      • You’ll need to update DNS records and ensure AD replication reflects the change
        • DFS-R may require reinitialization or cleanup of replication metadata to avoid conflicts
        • DFS Namespace: You are correct—DFS Namespaces typically require a virtual name (e.g., PC-3) for abstraction. However, if you’re not using DFS Namespaces and relying solely on DFS-R for replication, you can retain direct access to “PC-1” by renaming PC-2 and updating DNS.

    ⚠️ DFS-R does not provide automatic failover or seamless redirection. Manual steps are required to switch roles between servers.

    Summary of DFS-R Suitability

    Requirement DFS-R Support Notes
    Preserve NTFS permissions ✅ File-level permissions are retained
    Preserve NTFS permissions ✅ File-level permissions are retained
    Manual disk swap between servers ⚠️ Possible but requires careful handling
    Rename secondary server to primary ✅ Requires DNS and AD updates
    Automatic failover ❌ DFS-R does not support automatic failover
    Replication of multiple volumes ✅ Supported, unlike Storage Replica Standard
    On-premises only setup ✅ Fully supported

    Alternative Suggestions

    If downtime tolerance is 10–15 minutes and file integrity is paramount, DFS-R can work with manual intervention. However, for more seamless failover, consider:

    • Robocopy-based scheduled syncs for simpler environments
    • Third-party replication tools with better failover support
    • Hyper-V replication if virtualization is an option

    I hope my answer is useful for you.

    Best regards,

    Quinnie Quoc.

    0 comments
  2. Quinnie Quoc 7,625 Reputation points Independent Advisor
    2025-08-19T08:42:13.43+00:00

    Hello,

    Thank you for the detailed overview and thoughtful consideration of your environment and requirements. Based on your outlined use case and constraints, I’ve reviewed the feasibility of using DFS Replication (DFS-R) on Windows Server 2019 Standard to meet your goals. Below is a breakdown of your two key scenarios and how DFS-R aligns with them.

    🅰 Scenario A: HDD Failure on Primary Server (PC-1)

    You’re asking whether, in the event of a data HDD failure on PC-1, you can:

    • Pause DFS replication
    • Physically remove the replicated HDD from PC-2
    • Install it into PC-1
    • Resume operations with NTFS permissions intact

    DFS-R Considerations:

    • NTFS Permissions: Yes, NTFS file-level permissions are preserved on replicated volumes and will remain intact when the disk is moved.
    • Replication Pause: You can pause or disable DFS replication using PowerShell or the DFS Management Console before removing the disk to prevent sync conflicts.
    • Disk Swap: Physically moving the disk is technically feasible, but it’s important to ensure:
      • The disk is healthy and not mid-replication
        • The volume mount point and drive letter match the original configuration
          • DFS-R database integrity is not compromised during the move

    ⚠️ DFS-R is not designed for disk-level failover or hot-swapping. Manual intervention is required, and care must be taken to avoid triggering unexpected replication behavior.

    🅱 Scenario B: OS Failure on Primary Server (PC-1)

    You’re asking whether, in the event of OS failure on PC-1, you can:

    • Move the data HDD from PC-1 to PC-2
    • Rename PC-2 to PC-1
    • Resume application connectivity with NTFS permissions intact

    DFS-R Considerations:

    • Disk Move: Yes, NTFS permissions will remain intact when the disk is moved.
    • Renaming PC-2: Renaming the server to match PC-1 is possible, but:
      • You’ll need to update DNS records and ensure AD replication reflects the change
        • DFS-R may require reinitialization or cleanup of replication metadata to avoid conflicts
        • DFS Namespace: You are correct—DFS Namespaces typically require a virtual name (e.g., PC-3) for abstraction. However, if you’re not using DFS Namespaces and relying solely on DFS-R for replication, you can retain direct access to “PC-1” by renaming PC-2 and updating DNS.

    ⚠️ DFS-R does not provide automatic failover or seamless redirection. Manual steps are required to switch roles between servers.

    Summary of DFS-R Suitability

    Requirement DFS-R Support Notes
    Preserve NTFS permissions ✅ File-level permissions are retained
    Preserve NTFS permissions ✅ File-level permissions are retained
    Manual disk swap between servers ⚠️ Possible but requires careful handling
    Rename secondary server to primary ✅ Requires DNS and AD updates
    Automatic failover ❌ DFS-R does not support automatic failover
    Replication of multiple volumes ✅ Supported, unlike Storage Replica Standard
    On-premises only setup ✅ Fully supported

    Alternative Suggestions

    If downtime tolerance is 10–15 minutes and file integrity is paramount, DFS-R can work with manual intervention. However, for more seamless failover, consider:

    • Robocopy-based scheduled syncs for simpler environments
    • Third-party replication tools with better failover support
    • Hyper-V replication if virtualization is an option.

    I hope my answer is useful for you.

    Best regards,

    Quinnie Quoc.

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.