Australian cloud for business software — built and run in Sydney since 2003

+61 2 8282 5656
support@netleverage.com
Talk to an engineer
Talk to an engineer
NetLeverage
NetLeverage

Restoring files into a DFS Replication folder without surprises

Technical article
Backup & Recovery

Originally published:

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

DFS Replication keeps copies of the same folders on several Windows servers and keeps them in step. It is often used behind a DFS namespace, so users in different offices can work with a nearby copy of shared files.

For recovery, that design changes the rules. In an ordinary file server, a restore puts a file back in one place. In a replicated folder, whatever happens in one place is meant to happen everywhere. This article explains, from Microsoft's documentation, what that means when files are lost, restored, or when a whole server is rolled back.

Replication is not a backup

Microsoft's Distributed File System (DFS) Replication overview describes the service as an efficient, active-active replication engine for keeping folders synchronised between servers. Active-active means any member can accept changes, and those changes are sent to the others.

That includes deletions. The reference for Restore-DfsrPreservedFiles states it plainly: When a member computer deletes a replicated file, other members also remove that file.

In our reading, that settles a common misunderstanding. Having the same folder on three servers protects against one server failing. It does not protect against a user deleting the wrong folder, an application corrupting files, or ransomware encrypting them, because each of those changes is replicated faithfully to every member. Separate backups remain necessary.

The DFS Replication FAQ addresses backup directly: To back up files that are stored in a replicated folder, use Windows Server Backup or Microsoft® System Center Data Protection Manager. In our understanding, the broader point is that the backup should be one that works with the replication service rather than around it, as discussed below.

How replication settles conflicts

Because there is no central copy, two people can change the same file on two servers before replication catches up. The FAQ describes what happens: When DFS Replication detects a conflict, it uses the version of the file that was saved last. The other version is moved into a hidden folder named ConflictAndDeleted on the server that resolved the conflict.

The FAQ also explains that DFS Replication doesn't merge files when there's a conflict. Microsoft's article Understanding (the Lack of) Distributed File Locking in DFSR explains why: each server only knows about file locks on itself, so people on different servers can overwrite each other's changes.

In our reading, the rule that the last save wins has a direct consequence for restores, covered in the next section.

What a restore looks like to replication

In our understanding, when a backup tool writes a restored file into a replicated folder on one member, replication sees that as a new change on that member, and sends it to the others. Three things follow, in our reading:

  • A restored file appears everywhere. That is usually what is wanted when a file was deleted.
  • A restored older version can replace newer work. If the file still exists on other members and has been edited since the backup, the restore writes an older version now. Under the last-save rule, the restored copy may become the version that wins, and the newer edits end up in ConflictAndDeleted, if they are kept at all.
  • A large restore becomes a large replication. Restoring many files sends all of them to every member. The FAQ notes that replication sends only changed parts of files using remote differential compression, but RDC is used only for files that are 64 KB or larger by default. In our view, a large restore should be planned for the link capacity between sites. Restoring during quieter hours, or restoring onto the member at the busiest site first and letting replication carry it outwards, are choices worth making on purpose.

For that reason, we recommend restoring individual files to a separate location first, checking them with the person who asked, and only then moving them into the replicated folder. That turns a restore into a deliberate, visible change, rather than a silent overwrite.

The hidden folders that sometimes save the day

Replication keeps some files it would otherwise lose. The Restore-DfsrPreservedFiles reference lists three kinds:

These are moved into hidden ConflictAndDeleted or PreExisting folders under the replicated folder, and recorded in a manifest. They can be a quick source of recovery, but the FAQ warns against relying on them: DFS Replication treats the Conflict and Deleted folder as a cache. When a quota threshold is reached, it removes some files, and There's no guarantee that conflicting files are saved.

The FAQ lists the recovery routes for lost files: File History, the Restore previous versions command in File Explorer, or by restoring the files from backup, or recovering directly from the preserved folders with the PowerShell cmdlets. The cmdlet reference carries a caution worth repeating: by default it moves all files and removes existing preserved files, including older versions, and Microsoft suggests backing up those folders before using it. This article does not give the cmdlets' syntax.

Two quieter routes to the same problem

Not every loss in a replicated folder starts with someone pressing delete. The FAQ describes one that can surprise administrators. Replication does not copy files encrypted with the Encrypting File System, and If a user encrypts a file that was previously replicated, DFS Replication deletes the file from all other members of the replication group. The FAQ explains that this ensures the only remaining copy is the encrypted one. In our reading, if that copy is then lost, or its owner's encryption key is, recovery requires an earlier readable copy or an encrypted backup with the necessary decryption key.

The FAQ also covers shadow copies on members: DFS Replication is supported on Volume Shadow Copy Service (VSS) volumes and previous snapshots can be restored successfully with the Previous Versions Client. In our understanding, that makes Previous Versions a convenient first stop for a single overwritten file. The restored version is still written as a new change, so the cautions in the earlier section about older versions replacing newer work apply in the same way. Built-in software shadow copies depend on the original volume, even when their change-storage area is on another local volume, which is why they are covered as a convenience rather than a backup in a separate article in this series.

Initialisation is different from adding a member

When a replicated folder is first initialised, one member is chosen as the primary member. The FAQ explains that the primary member's content is considered "authoritative." This means that during initial replication, the primary member's files always overwrite other versions of the files on other members of the replication group.

The primary-member designation applies to initialisation of the replicated folder; adding a member to an established group is not a fresh election of a permanent primary. A rebuilt member needs the supported initial-synchronisation or recovery process for its situation. Establish which surviving data is authoritative before rebuilding the topology; do not designate an old restored copy merely because it is available.

Microsoft's guide Use Robocopy to pre-seed files for DFS Replication describes copying data to a new member before replication starts, to avoid sending everything over the network. It includes a detail that is easy to miss: The destination folder must not already exist on the destination server. It also describes checking file hashes on both servers afterwards. In our view, the same discipline applies when pre-seeding a member from a restored backup.

Snapshots and whole-server rollbacks

The most serious warning concerns restoring a whole member to an earlier point in time. The overview says: to restore a server that's running DFS Replication, don't use snapshots or saved states to replicate anything other than the sysvol folder. It adds that if you attempt this type of restore, DFS Replication fails, and that recovery requires special database steps. The same virtualised-member guidance also warns not to export, clone or copy those virtual machines; changing the name of the copying method does not establish a supported recovery path.

The support article DFSR no longer replicates files after restoring a virtualized server's snapshot describes what happens. Among the behaviours it lists after such a restore:

The article explains the cause: Snapshots aren't supported by the DFSR database or any other Windows multi-master databases. It notes that this applies to all virtualisation products, that snapshot restore is supported only for read-only members, and that Recreating the replication group or replicated folder will not fix the issue on the restored server. It also says DFSR does not implement the USN rollback quarantine protection described for Active Directory Domain Services. Do not rely on an automatic quarantine to make an unsupported rollback safe. Its resolution is to contact Microsoft Support.

For backup of virtualised members, the overview is equally clear: use backup software inside the guest, and Don't back up or restore a virtualized DFS Replication server from the host virtual machine.

In our reading, this is one of the most important points in this series for anyone who protects file servers by backing up whole virtual machines. A host-level image of a replicated file server is not, on Microsoft's guidance, a safe way to restore that server. File-level recovery from inside the guest, with the cautions above, is the supported route.

A note on SYSVOL

Domain controllers use DFS Replication for the SYSVOL folder, which holds Group Policy files and logon scripts. Microsoft documents separate procedures in How to force authoritative and non-authoritative synchronization for DFSR-replicated sysvol replication. These change directory attributes on domain controllers and affect every domain controller in the domain, so this article does not describe them; they belong in a domain controller recovery plan, read in full beforehand.

What we recommend

  1. Keep separate backups of replicated folders. Replication is not a backup.
  2. Back up from inside the guest for virtualised members, as Microsoft directs, not from the host.
  3. Never roll back a read-write member with a snapshot or saved state.
  4. Restore single files to a side location first, check them, then move them in deliberately.
  5. Check whether a file still exists and has changed on other members before restoring an older version over it. Ask the user which copy they last worked on, and on which server, before choosing a version.
  6. Plan large restores for the bandwidth between sites.
  7. Distinguish first initialisation from adding a member, and follow the documented recovery process for the affected topology.
  8. Treat the preserved folders as a bonus, not a recovery plan, and back them up before using the restore cmdlet.

Make the chosen file version explicit

Before a recovered file enters a live replicated folder, record its source backup, timestamp, expected owner and the member on which it was checked. Ask the data owner whether newer edits on another member must be retained or reconciled. Replication has conflict rules; it does not understand which business version is correct. Keep a protected copy of the competing versions until that decision is made.

A larger recovery also needs a release plan for client writes. Otherwise users can create fresh changes while restored content is still moving between sites, producing more conflicts and uncertainty. The recovery owner should define when writes resume and how completion is evidenced across the intended members. A file appearing on the first server is not proof of convergence. Confirm its content and permissions at the relevant destinations, and investigate replication errors or backlog before declaring the folder recovered.

Risks and limits of this article

  • Based on Microsoft documentation as read on 11 November 2026.
  • How replication treats a restored file is our understanding, labelled as such; it was not tested.
  • No restores, snapshots or replication changes were made. No cmdlet, attribute or command syntax is given.
  • Microsoft's backup product names in the FAQ reflect when it was written; other backup tools exist.

Sources

Writer research: 11 November 2026. Independently reopened for review: 13 November 2026.

This article was originally published on .