DFS Replication between two Windows VPS nodes is one of the easiest ways to get a shared folder across sites, and one of the easiest ways to wake up to a 40 GB staging backlog and a file that never syncs. It copies data with compression and remote differential transfer, tracks versions with vector clocks, and quietly creates conflict copies instead of overwriting. Every one of those behaviors has a failure mode you need to watch.
The setup itself is modest: two servers, the DFS Replication role, a replication group, and a shared folder on each side. The tuning is where projects stall. Staging size, the 4 KB–256 MB file size floor, the 15-minute pre-seeding gap, and the ConflictAndDeleted folder quota all decide whether replication keeps up or falls behind permanently under a realistic write rate.
If your nodes live on separate Windows VPS instances in different regions, the WAN link becomes the real constraint. DFS-R does not reserve bandwidth, but it will compress and it will throttle itself to the replication schedule; plan for a link speed at least three times the sustained change rate, and never assume the initial sync will finish overnight.
Sizing staging correctly
Staging is a holding area for files waiting to be sent or assembled from received blocks. The default is 4 GB, which is too small for any folder that handles large files. A useful rule is the size of the largest 32 files you expect to change in one day, times two. For a 5 GB database dump replicated daily, that is 320 GB of staging on each member.
Undersized staging produces log entries that the cleanup process could not free space, and replication stalls behind a full queue. Check current usage with Get-DfsrState and the staging folder size on disk; the clean-path log records every case where staging had to delete a file to make room, which tells you the buffer was too small even if replication still completed.
Get-DfsReplicationGroup | Get-DfsrMembership | Format-Table
Get-DfsrState -ComputerName dfs-a
Get-WinEvent -LogName "DFS Replication" -MaxEvents 50 |
Where-Object {$_.Id -in 4004,4012,4208,5002,5008}Reading the backlog
Backlog is the number of updates not yet received by a partner, measured in files and in megabytes. A backlog that sits at a constant value is a permanent lag; a backlog that grows steadily is a link or staging problem; a backlog that drops after business hours is just daytime traffic. Capture it on a schedule and graph it — a single reading tells you nothing.
| Signal | Healthy | Degraded | Broken |
|---|---|---|---|
| Backlog (files) | < 100 | 100–2000 | > 2000 growing |
| Backlog MB | < 500 | 500–10000 | > 10000 |
| Staging used | < 60% | 60–85% | > 85% |
| ConflictAndDeleted | < 5% quota | 5–50% | > 50% |
| Replication latency | < 5 min | 5–60 min | > 60 min |
The most useful single event is 4012, which reports replication being paused because the receiving member’s staging is full. Seeing it once under a heavy load is fine; seeing it every hour means the sender is producing faster than the receiver can stage and the lag will never clear without intervention.
Conflicts and deleted files
When both members write to the same file between replication intervals, DFS-R does not merge. The newer writer wins and the other copy lands in DfsrPrivate\ConflictAndDeleted as a renamed file with the server name appended. Those files are worth recovering once, and a steady stream of them means two applications are fighting over one path — usually a sign the folder should not be multi-master at all.
ConflictAndDeleted has a quota, default 660 MB, and it is a ring buffer. When it fills, the oldest entries vanish silently. On a 1 TB replicated folder, raise the quota to 4–8 GB and monitor its usage; a sudden climb after a migration is expected, a persistent climb at 3 a.m. is not. Set the quota per member with Set-DfsrMembership -ConflictAndDeletedQuotaInMB.
Why it is not a backup
Replication propagates deletions. Remove a folder on one member and it disappears on the other within a replication interval. Encrypt files with ransomware on one node and the encrypted blocks replicate as a legitimate change; the vector clock cannot tell a malicious write from a good one. The only protection is the ConflictAndDeleted buffer, which holds a small, time-limited window of overwritten files.
Version history is also limited. DFS-R keeps previous versions only inside the ConflictAndDeleted area and the staging folder, both of which recycle. There is no point-in-time restore, no immutable copy, and no way to recover a file deleted two weeks ago. Treat DFS-R as a distribution mechanism for read-mostly content and pair it with a separate backup that lands on storage the replication group cannot write to.
Pre-seeding to avoid a multi-day first sync
Initial replication moves every file over the WAN. For 500 GB at 20 Mbps of usable bandwidth, that is about two and a half days. Pre-seed by copying the data offline to the second member, adding it to the replication group, and choosing the authoritative member — DFS-R compares the files and only transfers what differs, provided the copy happened within the supported window.
Do the copy with a tool that preserves timestamps and ACLs, and verify file count and total bytes on both sides before enabling replication. A mismatch of even a few files turns a 30-minute differential into a full re-sync of the affected folder. Run dfsrdiag ReplicationState after enabling and confirm it reports the expected number of files, not the full set.
Schedule and bandwidth throttling
The replication schedule is a 15-minute granularity grid, and the default is full bandwidth 24/7. If the WAN link also carries user traffic, throttle it — DFS-R honors the bandwidth setting per connection and will queue excess data rather than dropping it. Throttling to 60% of link capacity during business hours keeps interactive traffic usable while letting the backlog drain at night.
Remember that throttling changes the backlog math. If you cut bandwidth to 10 Mbps for nine hours a day, the daily change volume must fit in the remaining window or the lag compounds. Measure your actual change rate over a week before setting a throttle, and leave a 30% headroom on top of the worst day.
A monitoring routine that fits in five minutes
- Daily: backlog files and MB, both directions, compared with yesterday.
- Daily: staging usage percentage and the latest 4012 or 5002 event count.
- Weekly: ConflictAndDeleted size, and a sample of conflict file names for repeating patterns.
- Weekly: verified restore test of one random file from your real backup, not from DFS-R.
- Monthly: full file count and size comparison between members.
None of these checks catch every failure, but together they catch the slow ones before users do. If the backlog is rising for three consecutive days, stop adding load and fix it first; catching up on a two-week lag with a throttled link can take longer than the outage that caused it. A paired Windows VPS setup for DFS-R works well when the replication health is measured, and badly when it is assumed.
