Forum Discussion

jmanini's avatar
jmanini
Level 4
12 years ago

Restoring VMware Files and Folders with No Agents (Windows)

We have a pretty large environment and are now finally moving to doing VMware backups. We currently are using Windows 2008 R2, NetBackup 7.5.0.4. In the past we had an agent on each server so it was easy for the different server admins to do their own file level restores. So now we are testing the VMware backups which works real well and as a NetBackup admin I can easily restore the entire VMDK or a single file from the Master Server by using the Backup, Archive, and Restore GUI Client. So I was pondering on how going forward can we allow our Admins to do their file level or possible VMDK level restores when there are no agents on the boxes? My thought nwas to install the NetBackup client on a terminal server and allow the admins to do alternate client restores from there but it seems to only allow them to restore data to the terminal server only and not the server in question. The Destination Client for Restores in greyed out as seen by the attachment. So am I not able to do this and what are the masses doing with this same issue?

 

 

  • The altnames feature should do exactly what you are dreaming about.
    Please look under the title About allowing a single client to perform redirected restores in the Nbu admin guide.

     

    Suppose your terminal server hostname is term1, create the following file on the master server (not folder, and without extensions such as .txt):

    Install_path\NetBackup\db\altnames\term1

    Use notepad to add to this ASCI-format file the names of the VMs - as cataloged from the VMware backup jobs - one name per line; upper/lower case matters.

     

    Effectively, you will be granting term1 permission to restore other clients' files (in your case, the VMs').
    The Destination client field on term1 should become editable.

    Suppose you need to restore a file back to a VM named vmserver1 and it does not have the Nbu Client installed, you can first restore the file to term1, then from term1 send this file to vmserver1 using Windows share folders / UNC paths.

     

    I would also recommend reading up on No.Restrictions, which is essentially an all-clients-can-restore-all-clients version of the above, but I do not recommend it for production use for security reasons.

  • With the Vmware backups if you want to restore individual files then you should have the NBU agent installed on the servers.Without agent being installed on the servers you can restore the complete VMDK but not the individual files. Also to restore the VMDK is not a daily task and needs to be done when vm is crashed or some issue and should be left to NBU admin as there are lot of selection needs to be made while doing so. The image that you have attached is from the client it seems and you can't change the destination while doing the restore from the client. Do the restore from the Master or Media server.
  • Disagree with your statement sazz

    NBU agent in guest VMs are required for follwing two reasons

    If we have Exchange/SharePoint/SQL or

    If we want to perform GRT restores of Files directly back to Source VM instead of Alternate restores to master/media or any other server where we have NBU client installed

     

    Without Agent being installed in Guest VM too , NBU can restore individual files , that's one of beauty we got (V-Ray)

     

    jmanini

    You would need to install NBU client in each of VMs which you would like to provide access to respective admins for restores

    Agent inside Guest VM uses less footprint backup/restores

    It is all VMware Tools and vStorage API which does magic

    Do let us know if you still have any queries

  • Hi Jazz, The image I attached was from a Terminal Server which I was hoping to install the client then give this clien the ability to do alternate restores for many servers. But this does not seem to be in the cards. I was hoping to give admins a single place to do their file/folder restores whereas I'd do the VMDK restores from the master. Oh well maybe in the future there will be a way to do this but for now I'll what Symantec says I can do :-)

     

    THx

  • Thx Captain, I ws just hoping there was a trick for allow admains a single place to do their file\folder restores whereas I'd do the VMDK restores from the master. So I understand going forward that I have two options, One is to put a client on all machines which then requires me to keep that updated to a certain point which stinks, two would be to do all of the restores from the master which is probably the way for me to go for most situations. In a perfect work I would be able to install a client on a terminal server and allow that client to do alt restores for only ceratin servers so an Admin could go to one place and clients would never have to be installed on a VM in the future :-) I'll keep dreaming

     

    Thx for your knowledge

  • The altnames feature should do exactly what you are dreaming about.
    Please look under the title About allowing a single client to perform redirected restores in the Nbu admin guide.

     

    Suppose your terminal server hostname is term1, create the following file on the master server (not folder, and without extensions such as .txt):

    Install_path\NetBackup\db\altnames\term1

    Use notepad to add to this ASCI-format file the names of the VMs - as cataloged from the VMware backup jobs - one name per line; upper/lower case matters.

     

    Effectively, you will be granting term1 permission to restore other clients' files (in your case, the VMs').
    The Destination client field on term1 should become editable.

    Suppose you need to restore a file back to a VM named vmserver1 and it does not have the Nbu Client installed, you can first restore the file to term1, then from term1 send this file to vmserver1 using Windows share folders / UNC paths.

     

    I would also recommend reading up on No.Restrictions, which is essentially an all-clients-can-restore-all-clients version of the above, but I do not recommend it for production use for security reasons.