08-13-2014 01:25 PM
Hi all,
I'm trying to restore all the data from a Windows 2000 file server to a new 2012 R2 server. The backup type is vmware but I'm doing a file level restore rather than vmdk.
The restore has worked fine and ntfs pemissions ok but none of the shares have been created even after rebooting the server. Any idea why this may be, if I remember rightly doing a std windows client backup/restore would recreate the windows share. Is this a limitation of the vmware type backup. I've tried to find some mention in the vmware admin guide but no joy..
Thanks
08-13-2014 02:22 PM
It does not matter if the machine is a VM or not. A Windows restore will behave like a Windows restore. It will restore all permissions and share permissions as long as the user performing the restore has the permissions to create such objects in the destination. You do have to reboot the destination after the restore is complete.
This only applies to local folders that are to be shared from this server. We are not talking about foreign mount points. Mount points are not included by default.
08-13-2014 03:15 PM
Thanks for the clarification. If this is the case, any thoughts on why the shares are not being created?
Thanks
08-13-2014 09:56 PM
The Server service needs to be restarted to register the shares. See the Note in http://www.symantec.com/docs/TECH21801
08-14-2014 06:13 AM
I already mentioned the permissions of the user account used to perform the restore. Beyond that you would need to do some log analysis. Check the windows event viewer for the time during the restore for odd filesystem errors.
Have you anaylized the view status log from the BAR GUI? It contains different information than the detailed status in the activity monitor.
From the machine used to start the restore:
for windows
C:\Program Files\VERITAS\NetBackup\logs\user_ops\<username>\logs
for unix install path/NetBackup\logs\user_ops\<username>\logs
Also the TAR log from the destination:
C:\Program Files\VERITAS\NetBackup\logs\tar
You might have to create the tar folder on the destination and turn up the verbosity of logging on the client. Then you can run the restore again and capture the tar log. This will be needed to perform in depth troubleshooting.
08-14-2014 09:09 AM
Hi all,
if you use standard share FS by Windows platform (no CIFS/SAMBA share by another system as example Netapp, Linux, Isilon, etc ...) therefore as wrote Riaan, the Server service need to restart.
Windows is storing the Share permission to Window's registry, therefore recover of Network Share Permissions means add/modify more records in registry SYSTEM\CurrentControlSet\Services\LanmanServer\Shares. Every share folder has own's key
SYSTEM\CurrentControlSet\Services\LanmanServer\Shares\Security\ - here are share folders and their share permission. If you add any new user to the sharing this folder this item will changed.
more information here http://support.microsoft.com/kb/125996/en-us
Therefore, you can verify logs as wrote it INT_RND in previous message or check registry if correct record for the share folder exist.
Netbackup can restore share permission to registry if you have equivalent rights. Please, check disable UAC on W2012 - this could be problem in create record to registry , see http://windowsitpro.com/windows-server-2012-r2/changing-uac-behavior-windows-server-2012-r2-and-windows-81
Petr
09-05-2014 04:23 AM
Interesting issue. Think a part of the problem could be that W2K is 32 bit and W2012 is 64 bit, so that he share keys might end up under the wrong part of registry
Curious, what does the Server admin GUI show under shares on the Windows 2012 machine after the restore ?