Forum Discussion

gkman's avatar
gkman
Level 5
8 years ago

AD GRT - vmware snapshot

Hi, this must be a subject discussed countless of times- regardless I havn't quite found the answers I was looking for. I am trying to figure out if I can and should backup Active Directory using v...
active directory
AD
GRT
netbackup 7.7.2
Snapshots
VMware
  • Marianne's avatar
    Marianne
    8 years ago

    If I search NetBackup for VMware Administrator's Guide  for GRT, this is what I find:

    For Exchange, SharePoint, and SQL applications, NetBackup for VMware
    supports Granular Recovery Technology (GRT) restores from full backups only.

    AD or Active Directory does not appear in this manual.
    So, my guess is that it is unsupported or else undocumented.

    If you need GRT, then probably best to treat the DC as a normal client.

  • Lowell_Palecek's avatar
    Lowell_Palecek
    6 years ago

    There is confusion at the top of the thread because terminology in Backup Exec differs from NetBackup.

    To rephrase the question, what kind of GRT restore can I do from a VMware backup?

    Answer: Normal files, Exchange, SharePoint, and SQL Server. Not AD.

    For AD GRT, you need to make an MS-Windows backup. It does use a snapshot, but the snapshot is taken on the client, not from the the outside as in a VMware backup.

    Reason: Active Directory uses a database, with the same JET database engine as Exchange uses. Exchange restores from a VMware backup need an agent on the VM to work with the Exchange VSS writer. Restores (whether database or GRT) work with the Exchange VSS writer, using metadata captured by the backup ASC job and data from the VMware backup image. AD restores would take parallel work, which we didn't do.

Marianne's avatar
Marianne
Level 6
Are you aware that your reference post is for Backup Exec?
Have you tried to find answers in NBU for VMware manual for your NBU version?
gkman's avatar
gkman
Level 5
8 years ago

Hi,

I wasn't aware that the reference post was for Backup-Exec. sorry, I usually double check to see to what backup system the post belong to.

I did look at the vmware manual, but didn't find any reference to active directory in it.

  • Marianne's avatar
    Marianne
    Level 6
    8 years ago

    If I search NetBackup for VMware Administrator's Guide  for GRT, this is what I find:

    For Exchange, SharePoint, and SQL applications, NetBackup for VMware
    supports Granular Recovery Technology (GRT) restores from full backups only.

    AD or Active Directory does not appear in this manual.
    So, my guess is that it is unsupported or else undocumented.

    If you need GRT, then probably best to treat the DC as a normal client.

    • SYM-AJ's avatar
      SYM-AJ
      Level 5
      6 years ago

      Marianne,

      I know this post is old - but it is key to a project I am just starting in this area.

      Did you ever confirm if we need to use an MS-Windows policy to allow GRT AD restores - or can a VMWARE policy type be used ?

      I have virtual W2K16 AD servers in a number of sites and would prefer to use a VMWARE policy type if possible.

      Thanks,

      AJ

      • Lowell_Palecek's avatar
        Lowell_Palecek
        Level 6
        6 years ago

        There is confusion at the top of the thread because terminology in Backup Exec differs from NetBackup.

        To rephrase the question, what kind of GRT restore can I do from a VMware backup?

        Answer: Normal files, Exchange, SharePoint, and SQL Server. Not AD.

        For AD GRT, you need to make an MS-Windows backup. It does use a snapshot, but the snapshot is taken on the client, not from the the outside as in a VMware backup.

        Reason: Active Directory uses a database, with the same JET database engine as Exchange uses. Exchange restores from a VMware backup need an agent on the VM to work with the Exchange VSS writer. Restores (whether database or GRT) work with the Exchange VSS writer, using metadata captured by the backup ASC job and data from the VMware backup image. AD restores would take parallel work, which we didn't do.