Share via

DFS replication rollback is causing file loss and an outdated backup state on Windows Server.

Ezreal 0 Reputation points
2026-04-20T11:39:40.2+00:00

I'm dealing with a serious issue in a corporate file-sharing environment where we use DFS Replication between two servers: DC-FS01 running Windows Server 2008 R2 Enterprise and DC-FS02 running Windows Server 2019 Standard. The configuration was working normally in production for departmental file shares until recently, and was considered stable. After a planned restart of both servers on 2/22, something unexpected happened. Several folders replicated by DFS appeared to have reverted to a previous state, from approximately 2/8. Users immediately began reporting missing documents and old versions of files being restored, which raised concerns about a possible data loss or replication rollback. What makes this situation even more confusing is that our backup system shows the same outdated file state, even in the most recent successful backup runs. This suggests that the backups are also capturing the same old dataset, despite users having actively created and modified files after that date in normal operations. I'm trying to understand if DFS Replication exhibits any behavior related to versioning, conflict resolution, staging, or replication latency that might cause more recent changes to be overwritten or not properly preserved. I'd also like to know if shadow copies or DFSR mechanisms can somehow expose or retain more recent versions that aren't visible through normal file or backup browsing, and if there's any viable way to recover lost changes from DFS Replication itself. I haven't been able to find a clear explanation for this "rollback to a previous state" behavior, so I'm trying to determine if it's related to configuration, a replication failure, or something deeper in the DFSR architecture.

Windows for business | Windows Server | Devices and deployment | Configure application groups
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Tracy Le 8,470 Reputation points Independent Advisor
    2026-04-20T12:33:47.2733333+00:00

    Hi Ezreal,

    DFSR does not have a rollback, staging delay, or versioning mechanism that works like this. When an entire dataset time travels exactly two weeks into the past and even local backups reflect this-it is a catastrophic infrastructure-level event.

    Here are the two actual culprits and how to recover your missing data:

    1. The Hypervisor Snapshot Revert

    If these are virtual machines, someone almost certainly reverted one of the servers to a February 8th snapshot during the February 22nd reboot. When a DFSR node wakes up from a snapshot, its USN journal is completely out of sync (USN Rollback). DFSR's conflict resolution can aggressively treat the "restored" old files as the truth, forcing the partner server to overwrite its newer files with the old snapshot data.

    2. The 2008 R2 Dirty Database Rebuild

    Windows Server 2008 R2 is notorious for DFSR database corruption upon reboot. If its database corrupted and auto-rebuilt on 2/22, a massive conflict resolution storm occurred. Due to clock skew or metadata mismatches, the system may have incorrectly judged the old 2008 R2 files as "winners" and dumped the newest files from the 2019 server into the hidden Conflict vault.

    How to Recover Your Files Right Now: Do not rely on standard backup browsing. The truly newer files were likely moved by DFSR into a hidden quarantine folder during the conflict storm.

    Open an elevated PowerShell on both nodes and run: Get-DfsrPreservedFiles -Path "X:\Path\To\Your\Share\DfsrPrivate\ConflictAndDeleted"

    If you see your missing recent documents listed in the output, you can immediately recover them by piping that command into Restore-DfsrPreservedFiles.

    Mixing a legacy 2008 R2 server with 2019 in a DFSR topology is a ticking time bomb. They handle database engine states very differently. Expedite the retirement of that 2008 R2 node to prevent this from happening again.

    I hope this helps you recover the lost data! If it points you in the right direction, please click "Accept Answer".

    Tracy.

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments

  2. AI answer

    2026-04-20T11:40:14.27+00:00

    DFS Replication does not provide multi-version rollback of replicated folders, but several DFSR behaviors and known issues can make it appear as if data has reverted or been lost, especially around restarts, database problems, or virtualization/snapshots. Key points and concrete recovery options are as follows.

    1. Why a “rollback” can happen in DFS Replication

    a. Restoring or rolling back a DFSR member (especially virtualized)

    If a DFSR server is restored from a snapshot, export, clone, or other image-level rollback, DFSR can stop replicating or behave incorrectly because the DFSR database no longer matches the file system state. This is explicitly called out for virtualized DFSR members:

    • Restoring a server that runs DFS Replication from snapshots or saved states (for anything other than SYSVOL) can cause DFSR to fail and requires special database recovery steps.
    • Exporting, cloning, or copying the VM is also unsupported for DFSR data volumes.

    In such cases, DFSR may:

    • Stop replication on a volume with internal database errors (for example, Event ID 2004/2106 with errors like 9214/9014).
    • Require database recovery or non-authoritative/authoritative sync to resume correct replication.

    If one server was effectively “rolled back” to an older state (for example, via hypervisor snapshot or backup restore) and then allowed to replicate, that older state can overwrite newer data on its partners, depending on which side “wins” in DFSR conflict resolution.

    Relevant behavior is documented under “Snapshots and saved states” and the linked article on DFSR not replicating after restoring a virtualized server’s snapshot.

    Distributed File System (DFS) Replication overview

    b. DFSR database failures and auto-recovery

    When DFSR encounters internal database errors, it can:

    • Stop replication on a volume (Event ID 2004, error 9214/9014).
    • Then perform an internal database recovery and resume replication (Event ID 2106).

    If the DFSR database is lost or rebuilt, the member can receive a new database GUID and behave as if it is a new member. Depending on configuration (for example, StopReplicationOnAutoRecovery registry setting), this can lead to:

    • Replication being halted until manually fixed, or
    • Replication resuming with a potentially inconsistent view of what is authoritative.

    A known issue is that after a hotfix is installed and the DFSR database is lost/rebuilt, or when a member cannot contact downstream partners (for example, closed schedules), replication backlog and state can become problematic.

    You find a very large increase in the DFS Replication backlogs

    c. Known DFSR bugs causing data loss or unexpected deletions

    There are documented issues where DFSR can unexpectedly delete folders or files on upstream servers after the DFS Replication service restarts. For Windows Server 2003/2008, the workaround is explicitly “do not stop the DFS Replication service” until the hotfix is applied.

    If a similar bug or unpatched state exists in a mixed environment (2008 R2 and 2019), a restart of the DFSR service or the server could trigger unexpected deletions or state changes that look like a rollback.

    Some folders or some files are unexpectedly deleted on the upstream server after you restart the DFS Replication service

    1. How DFSR handles conflicts and why newer data can disappear

    a. Conflict resolution behavior

    When the same file is updated on different servers, DFSR:

    • Keeps the version that was saved last.
    • Moves the losing version into the local DfsrPrivate\ConflictAndDeleted folder on the server that resolves the conflict.

    The ConflictAndDeleted folder:

    • Is not replicated.
    • Acts as a cache and is cleaned up when its quota is exceeded or disk space is low.
    • Does not guarantee preservation of all conflicting files.

    If a server with an older dataset appears to have “newer” timestamps (for example, because of clock skew or database inconsistencies), DFSR can treat the older content as the winner and push it out, moving the truly newer versions into ConflictAndDeleted on the other member. To users, this looks like a rollback.

    DFS Replication FAQ

    b. Staging and schedules

    DFS Replication does not stage or replicate files outside of scheduled replication times or when bandwidth quotas are exceeded. If schedules are misconfigured or closed, a large backlog can accumulate, and when replication resumes, a burst of updates can overwrite files in bulk.

    DFS Replication FAQ

    1. Why backups also show the old state

    DFS Replication itself does not alter how backup software sees the file system. If backups show the same old state, likely causes include:

    • The backup source is a server that was effectively rolled back (for example, VM snapshot) and is now the DFSR member backing up.
    • The backup solution is targeting a member whose DFSR database or replication state caused it to revert to or present older data.
    • Backups were taken after DFSR had already overwritten newer files with older versions from another member.

    Additionally, for virtualized DFSR members, guidance is to:

    • Use backup software inside the guest VM to back up replicated folders.
    • Not back up or restore the DFSR server from the host level, because that can cause DFSR database inconsistencies and the kind of behavior being observed.

    Distributed File System (DFS) Replication overview

    1. Options to recover lost or newer versions

    a. Recover from ConflictAndDeleted or PreExisting folders

    If DFSR treated newer files as conflicts and moved them into ConflictAndDeleted or PreExisting on either server, they can be recovered using PowerShell:

    • Get-DfsrPreservedFiles to enumerate preserved files.
    • Restore-DfsrPreservedFiles to restore them.

    This is the only DFSR-native way to recover files that DFSR itself moved aside.

    DFS Replication FAQ

    b. Recover from shadow copies / backups

    DFS Replication does not maintain its own version history beyond ConflictAndDeleted/PreExisting. To recover:

    • Use File History, “Restore previous versions” in File Explorer, or restore from backup of the underlying file system or share.
    • Ensure that the restore is done in a DFSR-safe way (for example, restoring only data, not rolling back the entire DFSR server/VM image) to avoid re-triggering database inconsistencies.

    DFS Replication FAQ

    1. Recommended next steps for this scenario
    2. Check DFSR event logs on both DC-FS01 (2008 R2) and DC-FS02 (2019) around 2/22 for:
      • Event IDs 2004, 2106, 2213, or other DFSR database/auto-recovery events.
      • Any indications of database rebuilds or auto-recovery.
    3. Confirm whether either server was restored from a VM snapshot, export, or image-level backup around 2/8–2/22.
    4. On both servers, inspect DfsrPrivate\ConflictAndDeleted and PreExisting using:
      • Get-DfsrPreservedFiles to see if the missing “newer” files are there.
      • If found, use Restore-DfsrPreservedFiles to recover them.
    5. Verify backup configuration:
      • Ensure backups are taken from a DFSR member that is healthy and not rolled back.
      • Avoid host-level VM rollback for DFSR members; use in-guest backups.
    6. For the Windows Server 2008 R2 member:
      • Review whether the DFSR hotfixes related to unexpected deletions and backlog issues are applied.
      • If not, plan to apply the relevant updates or consider decommissioning the legacy OS from the replication topology.
    7. After recovery, validate replication health:
      • Use dfsrdiag backlog and propagation tests, DFS Management diagnostic reports, or DFSR PowerShell cmdlets to confirm that replication is in sync and stable.

    DFS Replication FAQ

    In summary, DFSR itself does not intentionally roll back to a previous date, but a combination of VM/image rollback, DFSR database recovery, conflict resolution, and known bugs around service restarts can cause newer data to be overwritten and appear lost. Recovery is primarily through ConflictAndDeleted/PreExisting folders and external backups; DFSR does not maintain a full version history beyond those preserved files.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

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.