Home › Resources › Field Guides › CIFS & NFS File Share Migration
Field Guide · Storage OperationsCIFS & NFS File Share Migration Field Guide: Robocopy, rsync, and Proving the Data Arrived
File share migrations do not fail at the copy — Robocopy and rsync have moved petabytes reliably for decades. They fail at the edges: the ACL that did not follow, the ten million files nobody counted, the locked spreadsheet at cutover, the /MIR pointed the wrong way, and the awkward silence when someone asks "how do we know everything made it?" This runbook covers the whole lifecycle — analyze with TreeSize, seed, sync, cut over, and verify with BeyondCompare — so the answer to that question is a report, not a shrug.
!!Command safety model
ROBOCOPY /MIR and rsync --delete make the destination an exact replica of the source — which means they delete anything on the destination that the source does not have. Swap source and destination in either command and they will faithfully, efficiently destroy the data you were migrating. Read the direction out loud before every run, and dry-run first (robocopy /L, rsync -n) — the dry run shows you the deletions before they happen.
| Badge | Meaning |
|---|---|
| Read-only | Inspects, lists, or dry-runs. Changes nothing on either side. |
| Disruptive | Writes to the destination. Safe when the direction is right; belongs in a controlled sequence. |
| Destructive | Can delete data (/MIR, --delete). Dry-run first, verify direction twice. |
ENVReference environment
The worked example retires two aging file services at the Boston site. On the Windows side, the hidden share apps$ moves from bos-fs-old to bos-fs-new (both NEXORA domain members, same domain — so NTFS ACL SIDs stay valid). On the Unix side, the export /export/research moves from bos-nfs-old to bos-nfs-new. A migration workstation (bos-mig-01) runs TreeSize Professional and Beyond Compare with reach to both sides of each move.
01The migration model: seed → delta → cutover
Copying a large share once, during a change window, is a plan for missing the window. The model that works is incremental: a seed copy that runs for as long as it needs to while users keep working on the source; one or more delta passes that shrink the difference to minutes of change; then a short cutover window in which writes stop, a final delta runs against a quiet source, verification proves the trees match, and access flips. Both Robocopy /MIR and rsync --delete are built for exactly this — every rerun copies only what changed and prunes what was deleted, so the same command drives all three phases.
- Analyze — TreeSize inventory: how much data, how many files, the path-length and permission landmines (section 02).
- Seed — first full copy, days before cutover, users unaffected. Expect it to take the longest by far.
- Delta — rerun the same command daily (or nightly); each pass shrinks. When a delta completes in minutes, you are ready to schedule cutover.
- Cutover — writes frozen, final delta against a quiet source, verify, flip access (section 06).
- Verify & hold — Beyond Compare evidence saved, source held read-only for a grace period before decommission (section 07).
02Pre-migration analysis with TreeSize Professional
TreeSize Professional (JAM Software) answers, before you copy a byte, the questions that otherwise surface as 2 a.m. surprises. Point it at the source share (run it elevated, or with an account that can traverse everything — a scan that silently skips unreadable directories produces a baseline that lies) and collect:
- Totals for the verification math. The size, file count, and folder count of the tree. Write these down — section 05 compares the target against exactly these numbers.
- Path lengths. The built-in search can list every path longer than 255 characters. Classic Win32 tooling breaks near the 260-character
MAX_PATHlimit; Robocopy itself copes with long paths, but the applications that will open these files afterwards may not. Fix or shorten the worst offenders before migration, while their owners are findable. - The age and type profile. Last-access and last-modified statistics, largest files, file-type breakdown. Shares are routinely 40–60% stale data — a migration is the best decommission opportunity the business will ever give you. Even moving everything, the age profile tells you what could tier to cheaper storage on the target.
- Permission exceptions. The permissions view surfaces broken inheritance and orphaned SIDs (
S-1-5-21-…entries with no resolving account) — decide deliberately whether those travel or die here. - The stakeholder export. Export the scan to Excel/PDF and attach it to the change record. It is the "what we set out to move" artifact the post-migration report gets compared against.
du -sh /export/research for size and find /export/research | wc -l for the object count (run on the NFS server, not through a client mount — the server-side walk is dramatically faster and does not hammer the network). TreeSize can also scan the export through a mapped path if a Windows-readable view exists, but native counts are the authoritative baseline for the rsync move.
SAThe migration service account
The Robocopy runs in section 03 and the cutover pass in section 06 execute with /COPYALL /B — and that switch combination decides, by itself, what kind of account must run them. A standard user account will stall or fail on locked, hidden, or permission-restricted corporate data, and it cannot commit ownership or auditing information on the destination. Provision a dedicated domain service account for the migration, request it early (directory-services tickets have lead time), and retire it the day cutover completes.
| Attribute | Value |
|---|---|
| Account name | svc-migration-file |
| Account type | Dedicated domain service account (not a shared admin login, not anyone’s personal account) |
| Description | Service account used for enterprise file migrations. |
| Domain group membership | Domain Users only. No additional domain groups — every privilege below is granted locally, on exactly the two servers involved. |
| Local group membership | Backup Operators (preferred) or Administrators on both the source (bos-fs-old) and destination (bos-fs-new) servers |
| Share-level permissions | Full Control on both network shares: \\bos-fs-old\apps$ and \\bos-fs-new\apps$ |
| Logon restrictions | Deny interactive and Remote Desktop logon; the account exists to run the copy job, not to browse servers |
| Lifetime | Account expiry set to the project end date; disabled at cutover, deleted after the rollback window closes |
Why each right is technically required
Permission preservation (/COPYALL and /SEC). The migration script is explicitly configured to copy all file data, timestamps, NTFS ACLs, ownership, and auditing information. Writing someone else’s ownership and audit entries onto the destination filesystem is a privileged operation — committing those inherited security descriptors requires SeRestorePrivilege (and SeSecurityPrivilege for the auditing entries), which standard accounts do not hold.
Bypassing restrictive ACLs (/B). Backup mode makes Robocopy assert SeBackupPrivilege and SeRestorePrivilege, reading files where explicit NTFS permissions would otherwise deny access. Twenty years of departmental shares always contain trees whose ACLs deny everyone but a long-gone owner — backup mode is how those trees migrate instead of silently remaining behind.
Unrestricted transfer. The combination is what guarantees the post-migration numbers in section 05 reconcile: every file readable, every ACL preserved, no permission degradation, no quiet skips inflating the delta report.
SeBackupPrivilege/SeRestorePrivilege, but it does not grant SeSecurityPrivilege (“Manage auditing and security log”), which the auditing component of /COPYALL needs — without it Robocopy logs ERROR 1307 on SACL writes. Either grant that one user right to the account in Local Security Policy on both servers, or run with /COPY:DATSO (everything except auditing) if your shares carry no SACLs worth moving. Local Administrators carries all three rights out of the box at the cost of a broader grant — if you take that route, the logon restrictions and expiry date above stop being optional hygiene and become the control.
Please provision a dedicated domain service account to facilitate a file share migration.
Account name: svc-migration-file
Description: Service account used for enterprise file migrations.
Group membership: Domain Users only (no additional domain groups).
Required rights:
- Local "Backup Operators" (or "Administrators") group membership on both
the source and destination file servers.
- Full Control share-level permissions on both the source and destination
network shares (apps$).
- Deny interactive / Remote Desktop logon.
- Account expiry at project end date.
Justification:
The migration runs Robocopy with /COPYALL /B /SEC, copying all file data,
timestamps, NTFS ACLs, ownership, and auditing information. Committing these
inherited security descriptors on the destination requires administrative-
level backup/restore rights. Backup mode (/B) asserts SeBackupPrivilege and
SeRestorePrivilege so the account can read and copy files where explicit
NTFS permissions would otherwise deny access. A standard user account will
stall or fail on locked, hidden, or restricted data; this access ensures a
comprehensive transfer without data loss or permission degradation.For the directory-services team on the other side of that ticket — the grant, end to end:
New-ADUser -Name "svc-migration-file" -SamAccountName "svc-migration-file" `
-Description "Service account used for enterprise file migrations." `
-AccountPassword (Read-Host -AsSecureString "Initial password") `
-Enabled $true -AccountExpirationDate (Get-Date).AddDays(60) `
-KerberosEncryptionType AES128,AES256Add-LocalGroupMember -Group "Backup Operators" -Member "NEXORA\svc-migration-file"
Grant-SmbShareAccess -Name "apps$" -AccountName "NEXORA\svc-migration-file" -AccessRight Full -Force
Get-SmbShareAccess -Name "apps$" # verify the grant tookDisable-ADAccount -Identity svc-migration-file, remove both local group memberships, and note it in the change record. An enabled migration account that outlives its migration is a standing privilege-escalation path.
03CIFS/SMB migration with Robocopy
Robocopy ships in every supported Windows version, restarts where it left off, copies NTFS security, and has been the standard for this job since the Resource Kit days. The script below drives all three phases — seed, delta, and the final cutover pass are the same command rerun. Download it, edit the three SET lines, and run it elevated, as the migration service account, from the migration workstation (or better, directly on the target server — one network hop instead of two).
/MT post-date it, but no current document explains the classification engine as clearly. © Microsoft Corporation; hosted here unmodified, for convenience, with the current syntax reference linked in References.
@ECHO OFF
SETLOCAL
SET _source=\\bos-fs-old\apps$\
SET _dest=\\bos-fs-new\apps$\
SET _what=/COPYALL /B /SEC /MIR
:: /COPYALL :: COPY ALL file info (data, attributes, timestamps, NTFS ACLs, owner, audit)
:: /B :: copy files in Backup mode (needs SeBackupPrivilege -- run elevated)
:: /SEC :: copy files with SECurity (subset of /COPYALL; harmless alongside it)
:: /MIR :: MIRror a directory tree (copies new/changed, DELETES extras on dest)
SET _options=/R:0 /W:0 /LOG+:C:\migration\bos-apps-robocopy.log /V
:: /R:n :: number of Retries on failed copies (0 = skip and log, keep moving)
:: /W:n :: Wait time between retries in seconds
:: /LOG+ :: append output to log file
:: /NFL :: No File logging (add on multi-million-file trees to shrink the log)
:: /NDL :: No Dir logging
:: /V :: Verbose logging (shows skipped files)
ROBOCOPY %_source% %_dest% %_what% %_options%
ENDLOCALWhy each switch earns its place:
| Switch | What it does | Why it matters here |
|---|---|---|
/COPYALL | Copies data, attributes, timestamps, NTFS ACLs, owner, and auditing info (/COPY:DATSOU) | A share migration that loses ACLs is a security incident scheduled for later. This is the whole-fidelity flag. |
/B | Backup-mode copy using SeBackupPrivilege | Reads files the migrating account has no ACL rights to — a share always contains some. Requires an elevated prompt and Backup Operators (or Administrators) membership. |
/SEC | Copy files with security (/COPY:DATS) | Redundant next to /COPYALL but traditionally kept in migration scripts as belt-and-braces; harmless. |
/MIR | Mirror the tree — copy new/changed, delete dest extras | Makes reruns converge: every delta pass leaves the target an exact replica. Also the dangerous one — see the warning below. |
/R:0 /W:0 | No retries, no wait | During seed/delta you want locked files logged and skipped, not each retried 1M times at 30s (the default — a single locked file can stall a run for hours). The cutover pass catches them once writers stop. |
/LOG+ /V | Append verbose log | The log is your skip-list and your evidence. Review every ERROR line after each pass. |
/MT:32 — multithreaded copy, the single biggest speedup on trees of many small files (log becomes interleaved; pair with /NP). /XJ — exclude junction points, which prevents the classic infinite-loop-through-a-junction failure. /DCOPY:DAT — preserve directory timestamps. /ZB — restartable mode with backup fallback, worth it on flaky WAN links (slower than plain /B).
Seed and delta passes Destructive
Run the script. The first pass is the seed and takes hours-to-days; rerun the identical script for each delta and watch the job summary shrink. The Destructive badge is for /MIR's delete behaviour on the destination — correct here, catastrophic if the direction were reversed.
------------------------------------------------------------------------------
Total Copied Skipped Mismatch FAILED Extras
Dirs : 12,847 3 12,844 0 0 0
Files : 418,203 211 417,992 0 0 2
Bytes : 1.892 t 3.41 g 1.888 t 0 0 18.2 m
Times : 1:38:22 0:06:51 0:00:00 1:31:31
Ended : Sunday, 19 July 2026 22:41:07
------------------------------------------------------------------------------Read FAILED first — zero or explained is the standard (each failure is an ERROR line in the log; locked user files are normal mid-week and are exactly what the cutover pass exists to catch). Extras counts what /MIR deleted on the target — files removed on the source since the last pass. A delta whose Copied column is down to minutes of data is your green light to schedule cutover.
What Robocopy does not move Read-only
Robocopy copies the contents of the share. It does not copy the share definition itself — the share name, share-level permissions, caching flags — nor local groups referenced in ACLs, nor quotas or FSRM screens. Export the share definitions before cutover and re-create them on the target:
Get-SmbShare -Special $false | Select-Object Name,Path,Description | Export-Csv C:\migration\shares.csv; Get-SmbShareAccess -Name "apps$" | Export-Csv C:\migration\apps-share-acl.csv04NFS migration with rsync
rsync is Robocopy's counterpart on the Unix side and the same model applies: one command, rerun for seed, delta, and cutover, converging on an exact replica. Run it host-to-host over SSH from the source NFS server to the target — not through two NFS client mounts, which halves throughput and mangles ownership through ID mapping. Root on both ends preserves everything.
rsync -avHAX --numeric-ids --delete --info=progress2 --log-file=/var/log/bos-research-rsync.log /export/research/ root@bos-nfs-new:/export/research/| Flag | What it does | Why it matters here |
|---|---|---|
-a | Archive: recursive + permissions, ownership, timestamps, symlinks, devices | The baseline fidelity flag — everything below extends it. |
-v, --info=progress2, --log-file | Verbose, whole-transfer progress, persistent log | The log is the skip-list and the evidence, exactly as with Robocopy. |
-H | Preserve hard links | Without it every hard-linked file lands as an independent copy — trees with snapshots-by-hardlink or build outputs balloon in size silently. |
-A, -X | Preserve POSIX ACLs and extended attributes | The Unix equivalent of /COPYALL. Both filesystems must support them (check with getfacl/getfattr). |
--numeric-ids | Copy raw uid/gid numbers, no name mapping | Correct when both servers share an identity source (LDAP/NIS or identical passwd files). If uid 1042 means a different person on the target, stop and reconcile identities first — no copy flag fixes that. |
--delete | Delete dest files absent from source | The /MIR equivalent — convergent reruns, same danger, same direction-check discipline. |
Dry run first Read-only
The rehearsal that costs nothing: -n shows every transfer and every deletion the real run would perform. Make it a habit before the seed and mandatory before any --delete run.
rsync -avHAXn --numeric-ids --delete --itemize-changes /export/research/ root@bos-nfs-new:/export/research/ | head -50>f.st...... genomics/run-4471/summary.parquet
>f+++++++++ genomics/run-4482/manifest.json
*deleting scratch/tmp-a91f/
sent 48,211 bytes received 1,203 bytes 32,942.67 bytes/sec
total size is 2,081,442,617,344 speedup is 42,113,882.11/export/research/ copies the contents of the directory; /export/research (no slash) copies the directory itself one level deeper on the target. The commands above use the slash form deliberately — be consistent across every pass or the delta will re-copy everything into a nested path. Second, sparse files: VM images and databases copied without -S inflate to full size on the target; add -S when the tree contains them.
-A's ACLs. -A preserves POSIX draft ACLs. Rich NFSv4 ACLs (NetApp/ZFS-style) do not travel via rsync — if the export's security model lives in NFSv4 ACLs, use the array's own replication (SnapMirror and kin) or plan an ACL re-application step, and verify with nfs4_getfacl on both sides.
05Verification with Beyond Compare
The copy tool grading its own homework is not verification. Beyond Compare (Scooter Software) is the independent examiner: a folder-compare engine that walks source and target side by side and shows — and exports — exactly what matches, what differs, and what exists on only one side. Run it from the migration workstation over the same access paths users will take: UNC paths for the CIFS move, mounted exports for NFS.
The two-pass compare discipline Read-only
- Structure pass — size & timestamp. Session → Folder Compare → load
\\bos-fs-old\apps$against\\bos-fs-new\apps$. Default comparison (size + modified time) walks millions of files quickly. Filters → include subfolders, show mismatches and orphans only. The result should already be near-empty after a good final delta. - Evidence pass — CRC. Session Settings → Comparison → enable CRC comparison and rerun on the tree (or, pragmatically, on the mismatch set plus a sampled slice of the clean set). Content checksums are the claim "the bytes are identical" — this is the pass you attach to the change record. Budget real time: CRC reads every byte on both sides.
- Orphan review. Anything only on source after the final delta is a copy failure — investigate every one (the Robocopy/rsync logs usually name the reason). Anything only on target before go-live should not exist if
/MIR/--deleteran — its presence means someone wrote to the target early. - Export the report. Session → Folder Compare Report → summary + differences, saved alongside the TreeSize baseline. Totals should reconcile: TreeSize said 418,203 files; the compare walked 418,203 files; differences zero. That reconciliation is the sign-off.
robocopy \\bos-fs-old\apps$ \\bos-fs-new\apps$ /MIR /L /LOG:verify.log — /L lists what a mirror would do without doing it; an empty plan is a converged pair (it also compares ACLs when run with /SECFIX /L, which Beyond Compare does not). NFS: rerun the rsync dry-run with --checksum for a content-hash walk: rsync -avHAXn --checksum --delete src/ dest/ — silence is convergence. Belt, braces, and an independent witness.
06Cutover runbook
- Freeze writes on the source. CIFS: set the share read-only at share-level (
Grant-SmbShareAccess -AccessRight Readafter revoking Change/Full) or take it offline briefly; check open handles first (Get-SmbOpenFile) and give owners a closing warning. NFS: re-export read-only (ro) or stop the writing services. - Final delta against the quiet source. Same script, same command. With writers stopped it completes in minutes and
FAILEDshould be zero — the locked files that survived every prior pass are now copyable. - Verify — the section 05 battery: compare clean, orphans explained, report exported. This is the go/no-go gate; do not flip on a dirty compare.
- Re-create share/export definitions on the target — share name and share-level ACLs from the section 03 export; NFS export options (
root_squash,sec=, allowed clients) matched deliberately, not copied blindly. - Flip access. Best case: a DFS namespace or DNS alias already fronts the share, and cutover is retargeting
\\nexora.local\dfs\apps→bos-fs-new(or moving thebos-fsCNAME + SPN). Without an alias layer, this migration is the reason to introduce one — the next migration becomes invisible to users. NFS: update the automounter map or fstab entries to the new server. - Source stays up, read-only, for the grace period. Nothing is decommissioned on cutover night.
6bCutover day: handing the Windows server’s identity to PowerScale
When the destination is a PowerScale (Isilon) cluster and users must keep reaching the old UNC path, cutover day is a DNS identity handover: the Windows server surrenders its name, and SmartConnect starts answering for it. The worked example retires bos-fs-old behind the cluster’s SmartConnect zone bos-isln-smb.nexora.local. The order below is load-bearing — each step frees the resource the next one claims.
- Run the final sync job. The same Robocopy script from section 03, run as the migration service account — the day-of pass drains the last week of deltas while the share is still live.
- Stop the Server service on the retiring host. This stops SMB sharing — no client can open or write anything — while leaving every share definition intact in the registry for rollback. Then run the sync once more against the now-frozen filesystem: with zero writers this pass is the mathematically final one.
- Delete the A and PTR records for the retiring server from AD DNS — and disable dynamic DNS registration on its NIC first, or the server will quietly re-register its name at the next reboot and race your delegation.
- Rename the Windows server (append a retirement suffix) and validate the new computer object in ADUC. The rename is what releases the
HOST/andcifs/SPNs bound to the old name — without it, Kerberos sees duplicate identities and clients fail in confusing, intermittent ways. - Delegate the old name to SmartConnect. Create a DNS delegation for
bos-fs-oldpointing at the SmartConnect service IP, so every lookup of the old name is answered by the cluster with a pool IP it chooses. - Teach the cluster its new alias. Add
bos-fs-old.nexora.localas a SmartConnect zone alias on the Isilon IP pool, fix the SPNs on the cluster’s machine account, and flip the Global DFS folder targets to\\bos-isln-smb.nexora.local\apps$. - Clear DNS caches on the application servers that mount from the retiring name (and on the DNS servers themselves) so nothing serves a stale answer for the old A record.
- Test share browsing from the application servers — not from your admin workstation. Prove the path, prove Kerberos, open a real file.
net session &:: who is still connected -- warn them first
net stop LanmanServer /y &:: stops SMB sharing; share definitions stay in the registry
sc config LanmanServer start= disabled &:: survive an accidental reboot without re-sharing
wuc-robocopy-migration.bat &:: the zero-writer final delta -- FAILED must be 0Set-DnsClient -InterfaceAlias "Ethernet0" -RegisterThisConnectionsAddress $false # on bos-fs-old, BEFORE deleting
Remove-DnsServerResourceRecord -ZoneName "nexora.local" -RRType A -Name "bos-fs-old" -Force
Remove-DnsServerResourceRecord -ZoneName "20.10.10.in-addr.arpa" -RRType PTR -Name "31" -ForceRename-Computer -NewName "bos-fs-rtd01" -DomainCredential NEXORA\svc-admin -Restart
# after reboot -- validate the rename took in AD (or eyeball it in ADUC):
Get-ADComputer -Identity "bos-fs-rtd01" | Select-Object Name,DNSHostName,Enabled
setspn -L NEXORA\bos-fs-rtd01$ # SPNs now carry the new name; HOST/bos-fs-old is freeAdd-DnsServerZoneDelegation -Name "nexora.local" -ChildZoneName "bos-fs-old" `
-NameServer "bos-isln-ssip.nexora.local" -IPAddress 10.10.20.40
# 10.10.20.40 = the SmartConnect SERVICE IP (SSIP), not a pool IP --
# SmartConnect itself answers queries for bos-fs-old.nexora.local from now onisi network pools modify groupnet0.subnet0.pool0 --add-sc-dns-zone-aliases=bos-fs-old.nexora.local
isi network pools view groupnet0.subnet0.pool0 | grep -i alias
isi auth ads spn check --provider-name=NEXORA.LOCAL # will list the missing SPNs for the alias
isi auth ads spn fix --provider-name=NEXORA.LOCAL # writes HOST/bos-fs-old + cifs/bos-fs-old to the cluster accountNew-DfsnFolderTarget -Path "\\nexora.local\dfs\apps" -TargetPath "\\bos-isln-smb.nexora.local\apps$"
Set-DfsnFolderTarget -Path "\\nexora.local\dfs\apps" -TargetPath "\\bos-fs-old\apps$" -State Offline
dfsutil /root:\\nexora.local\dfs /verbose &:: confirm target states before removing anythingipconfig /flushdns &:: on each app server that mounts the share
nbtstat -R &:: legacy NetBIOS cache, if WINS/NetBIOS is still alive
Clear-DnsServerCache -Force # on the DNS servers themselves
dfsutil /pktflush &:: flush cached DFS referrals on the app serversTest-Path \\bos-fs-old\apps$ # old UNC path -- must answer, served by the cluster now
net view \\bos-fs-old &:: share enumeration through the alias
klist get cifs/bos-fs-old.nexora.local &:: MUST return a Kerberos ticket -- NTLM fallback means SPNs are wrong
nslookup bos-fs-old.nexora.local # answer must be an Isilon POOL ip, chosen by SmartConnect
dfsutil /pktinfo &:: DFS referral now shows the SmartConnect target ACTIVEHOST/bos-fs-old — the moment the cluster claims the same SPN you have a duplicate, and authentication fails intermittently depending on which DC answers. Second: skip the SPN fix (step 6a) and DNS resolves beautifully while every mount silently downgrades to NTLM — or fails outright where NTLM is disabled by policy. klist in step 8 is not optional; it is the test that distinguishes “works on my machine” from “works.”/pktflush exists because flushing DNS alone leaves stale referrals. And nothing in this sequence deletes the renamed server or its data: it sits stopped, shares intact, as the rollback — section 07’s grace-period discipline applies unchanged.
07Rollback
The rollback story is the quiet payoff of a one-way migration: the source was never modified — every pass read from it and wrote to the target. Rolling back is therefore an access flip, not a data operation: point the DFS target / CNAME / automount map back at the old server, lift its read-only lock, and users are exactly where they were. Keep the source in that warm state for an agreed grace period (two to four weeks is typical) before decommission.
A file server retirement on your calendar?
WUC engineers run share migrations as change-controlled engagements — TreeSize analysis and decommission candidates, seed/delta scheduling, ACL and identity reconciliation, cutover with evidence-grade verification, and the grace-period plan.
Talk to engineering →FAQFrequently asked questions
Q01Why not just restore last night's backup onto the new server?
A restore is a copy of the share as of the backup, with none of today's changes and no convergence mechanism — you would still need delta passes to catch up, which is the seed/delta model with extra steps. Restores are the right seed when the WAN is the bottleneck (restore locally at the target site, then delta over the wire).
Q02How long will the seed take?
Arithmetic, then reality: 2 TB at an honest 1 Gbps is ~5 hours of pure transfer — then halve the link speed for protocol overhead and double the time for millions of small files, where per-file setup dominates and /MT:32 earns its keep. The seed's duration barely matters; it runs while users work. What matters is the delta trend — when reruns finish in minutes, you are ready.
Q03What happens to files that are open/locked during a pass?
With /R:0 /W:0 Robocopy logs them as errors and moves on; rsync copies a moving file but may capture a torn version (it copies whatever bytes it reads). Both are why locked files are a non-event mid-project and a zero-tolerance item at cutover — the final pass runs against a write-frozen source precisely so every former skip copies cleanly.
Q04Do NTFS permissions really survive the copy?
Within the same domain, yes — /COPYALL (or /SEC) carries the ACLs and the SIDs still resolve. Across domains, the ACLs copy but reference the old domain's SIDs; you need SID translation or ACL re-application, planned as its own workstream. Local groups on the old server never travel — TreeSize's permission view finds them before they surprise you.
Q05Can Beyond Compare handle millions of files?
Yes — folder structure compares are metadata walks and scale well; the practical constraint is CRC passes, which read every byte on both sides. On very large trees, run the CRC pass overnight, or CRC the business-critical subtrees fully and sample the rest. The native cross-checks (robocopy /L, rsync -n --checksum) parallelize the evidence.
Q06Should I run the copy from source server, target server, or a third machine?
Prefer the target server pulling from the source: one network hop, newest OS and Robocopy build doing the work, and writes are local. A third machine means every byte crosses the wire twice. The workstation's job in this guide is analysis and verification, not bulk transport.
Q07My tree has paths over 260 characters — will the copy break?
Robocopy handles long paths itself, so the copy usually succeeds — it is the applications and scripts touching those files afterwards that break. Find them with TreeSize before migration (path-length search), shorten what can be shortened with the owners, and test the survivors from a client after cutover. On current Windows, the LongPathsEnabled policy relieves the limit for manifest-aware applications — which not all are.
Q08Robocopy for the NFS side too, over a mounted export?
It works mechanically and loses fidelity: Windows sees the export through its NFS client's identity mapping, so ownership arrives as translated approximations, and POSIX ACLs/xattrs do not travel at all. Use rsync host-to-host for anything whose Unix permissions matter; reserve mounted-share Robocopy for permission-trivial data in an all-Windows operation that accepts the trade.
RFReferences
- Microsoft Learn — Robocopy command reference (every switch, current syntax)
- Microsoft — ROBOCOPY.DOC, Robust File Copy Utility manual, Version XP010 (Windows Server 2003 Resource Kit; hosted copy, © Microsoft)
- rsync(1) manual — samba.org (authoritative flag semantics)
- Scooter Software — Beyond Compare download (folder compare + CRC verification)
- JAM Software — TreeSize Professional (pre-migration analysis and reporting)
→From the same practice
- PowerScale (Isilon) OneFS Command Reference
- Cisco MDS NX-OS Upgrade Runbook
- Cisco MDS Zoning Field Guide
- Post-OEM storage maintenance
Retiring a file server without a verification story?
Most migrations we are called into already copied the data — what is missing is the proof, the ACL fidelity, and the rollback plan. WUC engineers deliver share migrations as evidence-driven projects: analysis, sequencing, cutover, and a compare report the auditors accept.
- Pre-migration analysis and decommission-candidate review
- Robocopy / rsync execution with converging delta schedules
- ACL, SID, and identity reconciliation across domains and platforms
- Evidence-grade verification and grace-period rollback planning
Prefer to talk it through first? Book a technical consultation → · View managed services
All hostnames, domains, users, paths, serial numbers and IP addresses in this guide are synthetic reference values. No customer environment is depicted. Beyond Compare is a product of Scooter Software; TreeSize is a product of JAM Software; Robocopy is a Microsoft Windows component, and the hosted ROBOCOPY.DOC manual is © Microsoft Corporation. WUC Technologies is not affiliated with these vendors.