11-11-2013 12:45 AM
Hi,
When testing moving data from 1 file server (win 2008 r2) to a new fileserver (win 2012) i became litle worried about the job size and file count.
the backup: 1297956 files, filesize 1928072185
the restore of the above backup: 1290340 files, filesize 1649874941
(netbackup 7.5.0.6 master/media/client)
Anyone has a good explenation for this or should i log a case at symantec?
I also get tons of "WRN - unable to set short name on restore" i have another post about this if this could be related.
https://www-secure.symantec.com/connect/forums/wrn-unable-set-short-name-restore
thanks
Johan
Solved! Go to Solution.
11-11-2013 09:22 AM
Take a look at this blog - it maybe that 8.3 (short names) are disabled on your target server
As that is an attribute for the restore it may affect the numbers when doing the restore
Hope this helps or at least explain a couple of things:
11-11-2013 01:43 AM
Hi Johan,
Did you actually verify if the files were all restored, or whether they're missing? The reflection in the gui might be misleading.
Also, did you use the windows 2012 client (http://www.symantec.com/docs/TECH204661)?
There are some limitations with restoring between NTFS and ReFS.
11-11-2013 01:50 AM
i have seen that the restore size is more.. that is because actaully the number it shows was the read data not the write data ..
could you please enable the tar log in the client with verbose 5 and attach the log..
and also the restore log from the /usr/openv/netbackup/logs/user_ops/<user_id>/logs
its may be better to log a case with Symatec to check the detail logs..
11-11-2013 05:41 AM
Hi Riaan
thanks for reply,
due to the fact that it was almost 2 milion files I moved Icannot actually verify that all has been restored, thats why i checked the filecount and size.
Yes, im using 2012 client
We are using NTFS on both servers.
Could you clarify your comment "The reflection in the gui might be misleading." a little? how can that be misleading?
//Johan
11-11-2013 05:43 AM
Thanks for reply Nagalla,
i have already enabled the tar log on the client but only with normal logging and the output log was over 210MB so posting it here is not an option im afraid..
//Johan
11-11-2013 09:22 AM
Take a look at this blog - it maybe that 8.3 (short names) are disabled on your target server
As that is an attribute for the restore it may affect the numbers when doing the restore
Hope this helps or at least explain a couple of things: