Showing results for 
Search instead for 
Did you mean: 


Level 5
Partner Certified

Hello everyone,

I have a query to do backup restore of a file server where a migration of file server from windows server 2008 R2 to windows server 2012 R2 standard, in which it goes unsuccessful. What is being proposed to make backup full and differential of the file server, but when it is commanded to restore the data in the new file server as it would restore the differentials.

Currently the scheduled task of the file server is backing up under the Full method, my query is if I add the backup task under the differential task, I will have problem for the historical dates and for acer restoration.

I appreciate your help.


Level 6
Partner    VIP    Certified

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.

Level 6
Partner    VIP    Certified

The important things to remember are:

1) To keep an on-line warm original copy, as you probably cannot afford for all of the shares to be offline for very long.

2) NetBackup is not a data migration tool.  Use robocopy or something like BeyondCompare (and several other products).

3) If you are being pushed by Windows admins to use NetBackup for the migration, then push back upwards to management.  The method that I have outlined above is the best practice (or near best practice) for file-server migration.  IMO, experienced NetBackup administrators would most likely use the method (or something like it) outlined above... because it provides the least disturbance of the original data-set, and is the quickest for smooth and clean cutover.

Partner    VIP    Accredited Certified

In addition to @sdo's excellent posts -

Can you explain what the restore error is?

And tell us what the selection is when you choose file/folders as well as restore destination and restore options?

Have you tested NBU comms to the new fileserver?
Can you run a small backup and restore using the same media server / STU as was used for W2008 file server?

Have you enabled logs to troubleshoot restore errors?
On master: bprd (NBU needs to be restarted to enable this log)
On media server: bpbrm and bptm
On destination fileserver: bpcd and tar