To be more sure of a clean and up to date restore, one should really consider enabling TIR on the backup policy - however, this can consume a fair bit more catalog space if you are not already capturing TIR.
Plus with a big file server migration you have the added worries of what about interleaving file changes during and after the backups? And the fact that the final stage is quite long because you have to:
- offline old shares
- take a final diff
- restore full + diff(s)
- online new shares
Are you able to describe the volume/disk count, share count, folder count, file count and total sizes?
One of the problems with a disk/folder/file restore like you are considering (i.e. backup from server A and restore to server B) is that the "shares" are not restored - i.e. someone will have to manually re-create the shares.
IMO, the best method for file server migration is:
1) Keep old server on-line and keep backing-up as usual.
2) Build new server, name "fileserver-new".
3) Restore from old server "full" backup to new server.
4) Build the new shares with same permissions as old shares.
5) Start a regime of regular robocopy + updates and pruning - i.e. get robocopy to also replicate the deletes and renames that are occuring on the old/current file server - i.e. replicate the state of "fileserver" to "fileserver-new".
6) Capture timings from several days of runs of item 5) - i.e. work put how long the final cutover will take.
7) Implement regular/same pattern of backups for fileserver-new And wait for these backups to settle down.
...when you are ready:
8) Off-line all shares on "fileserver".
9) Run windows commands to make sure that no files are left open by users.
10) Run a final robocopy from "fileserver" to "fileserver-new".
11) Eject "fileserver" from domain.
12) Rename computername/hostname of "fileserver" to "fileserver-old", and change IP address, reboot, rejoin domain as "fileserver-old".
13) Eject "fileserver-new" from domain.
14) Rename computername/hostname of "fileserver-new" to "fileserver", and give it the IP address of the old fileserver. Reboot.
15) Rejoin "fileserver" (i.e. the new one) to the domain.
16) Online shares.
17) Test.
.
This way the old file server remains almost pristine as your fairly quick recovery / fall-back point. And don;t forget to devise a "roll-back plan" too.
Your server team of Windows administrators should be well versed in doing this kind of thing. Yes, use NetBackup for the initial full seed restore, but then let the Windows admins do what they do best, which is handle the migration of the "shares".
I've assumed that there is no clustering and no DFS/DFSR in play here.
