Restoring Active Directory to a different server Backup Exec 2014

[ACampbell-SCL]

Hello All

I'm in the process of writing and testing a DR plan, but I have limited resources. I have an 2 Hyper-v Host one with a virtualised domain controller (vDC) and the second one is DR Hyper -V host. I've done GRT backups using the agents of the vDC but I want to restore to system state (with active directory) to the DR VM. Both Hyper-V hosts are on different networks but share the same media server.

I'm not worried about hardware conficts as they are VMs or the Authoritative Restore as covered here:

 http://technet.microsoft.com/en-gb/library/cc961934.aspx

But how do I get this data to the DR VM?

Many Thanks

Note: The DR VM is an older copy of the vDC with all the services and roles working.

[pkh]

Why do you want to just restore the AD to the DR VM? You should be replacing the entire DR VM with the latest backup of your production AD VM. This is the advantage of backing up a VM as a VM

[Colin_Weaver]

If you did a Hyper-V agent backup and want to DR it then you don't restore into an existing VM you let Backup Exec create and restore the whole of the VM in one pass AND use the redirection option to specify a different Hyper-V host

If it works like VMware backusp do, then you have to start your restore from the hostname you backed up from and not from the FQDN name of the VM you backed up and you make the restore selections close to where you can see the VHD fiels listed (either against the files or the container they are held inside) a few steps later in the restore wizard you should see the redirection options.

Sorry I haven't specifically looked at a Hyper-V restore to confirm this the exact steps although it may be in the admin guide.

[ACampbell-SCL]

Thanks both for your response,

I have to explain my backup method, I do host level backups every 1/4 (per year), then GRT backups Full weekly and DIFF daily for specific VMs

The DR plan works on the assumption that, I have to restore the host with all the VMs (which can be up to 3 months old) and the restore the indiviual VMs (as and when required) from the GRT backups available. I want to test if the GRT backups are good with out bringing down the live vDC. 

Also the hyper-v host is not joined to the domain and the only DC is a VM on the same host, hence I can't do a GRT backup of the vDC at host level.

[pkh]

When you say GRT backup, do you backup the VM as a VM or do you back it up as if it is a physical machine? You should be doing the first option because this will allow you to restore the entire VM for DR. You can select specific VM's to backup when you back then up as VM's. You don't have to backup the entire host to backup VM's as VM's

[ACampbell-SCL]

 VM as like a physical machine.

OK, from what I can tell BE 2014 reconises the DC as a VM and I do have an option to do a redirected restore to a different server. But which directory should I restore to? 

[VJware · Accepted solution]

Ok, if backing up the VM as a physical machine, then you can't really redirect the system state to another machine.

The only way to test would be to setup a same machine (same name, same specs) preferably in a workgroup. Disconnect the production machine from the network. Install the remote agent on the test machine and you would be able to restore using the online restore option.

The redirection option which you see in the restore wizard will restore the system state as a flat-files and a folder structure gets created for each system state component. However, this is not a "true" system state restore and this is usually used to check what was backed up or for installing the ADC from restored files.

[pkh]

As I said earlier, by backing up the VM as physical machine, you loose the ability to restore the entire VM for recovery and make the recovery process a lot more complicated that it needs be.

[Colin_Weaver]

I'll try to explain the usual use of Virtual Agent backups with GRT (with AD, Exchange, SQL Sharepoint  inside the VM)

1) You perform a virtual agent backup with GRT enabled against a VM. GRT offers individual file recovery from your volumes (C:, DL; etc,) and individual object recovery from database techologiess such as AD, SQL, Exchange, Sharepoint.  It does not offer any capabaility against the system state itself as this is wholly contained within the backup of the vhd/vmdk files. The backup as a whole (whether or not GRT is enabled) gives the provision to restore the whole VM.

2) If you have a disaster affecting the whole of the VM, you restore the complete VM which backup Exec creates for you during the restore process (hence you do not need a system state backup or restore) If the VM already exists that you are recovering you have to enable the option to delete/overwrite the VM (or redirect to somewhere it does not exist)

3) if you want to restore a file or object (e-mail, user account etc) you make use of the GRT selections to pick the required file or object for restore in the same way you might want to restore an individual file and this then uses the remote agent to do the restore instead of the programming interface (API) of the Hyper-Visor in use. In the case of Active Directory you would normally restore the objects back to the original DC as this scenario is for acccidental changes to an object that you are attempting to undo.

What the above means is there is no real point in you having a DC already within your DR environment to restore into as you would be restoring the whole of the VM and overwriting the existing one to do your DR restore test anyway.

There are very few scenarios that would affect the whole of AD where restoring a complete DC and not just the System State part of it (and in fact System State backups restored on their own are often more complicated than restoring a complete VM anyway.) Also if you wanted to do a complete VM restore followed by making that newly restored DC be authoritative over AD you can do this as well just by following steps provided by Microsoft once the DC has been restored.

Note1: For either 2 or 3 if you have incremental or differential sets then the complete sequeunce back to the last full is used because of the block level nature of the backups. (This is different from agent based file system backups where you can restore individual files from within an incremental without needing the full.)

[ACampbell-SCL]

@Vjware, thanks for the imput but that what I'm trying to avoid. I don't have limited down time to test and based on the backup and retstore times it not possable without effecting the business.

@pkh and @Colin, I'm using SBS 2011 so I can't really use AD replication from another AD (I know it's supported it's just SBS is a funny system). On the production hyper-v host with vDC (SBS 2011) I do have access to restore the system state (AD) to VM directly via the host level restore, but can I redirect the restore data to a different host with the VM with the same name?

Or is there away just do a GRT backup (Full and Diff) the VM at host level and restore the whole VM that to a different host? Will it require a separate job?

[Colin_Weaver · Accepted solution]

OK the term GRT applies to

Virtual machine backups

Exchange backups (inside or outside of a VM)

SQL backups (inside or outside of a VM)

Sharepoint backups (inside or outside of a VM)

Active Directory backups (in a VM job)

- this does not provide full system state restoee capability (outside of restoring the whole VM)

- does provide AD Object, file system content and full VM restore capability

- can restore the whole VM (either to original or redirected locations)

 Active Directory backups (in a System State Job from a DC)

- does provide system state restore capability (redirection not possible)

- does provide AD Object restore

- as long as file system etc on server are also backed up can be used to restore complete systerm, although the process can be more complicated

- does not directly provide file system restore (although can be combined with backup up the file system as well)

If your small business server is inside the VM (as you appear to have) and you do a virtual agent backup with GRT enabled then the DR test would be to redirect the complete VM to somewhere as a new VM (this in theory can be a different host or a different folder and VM name on the same host). You would not be doing a full System State Restore from this type of backup at a GRT level.

You can do a System State backup within the VM using the traditional agent however a DR test would be hard work as the same severrname would have to exist to do a restore to. One of the limitations of System State Restores is that they cannot be redirected. This would mean you would need an offline DR test environment that you move the backup sets to for the test.

Note: the simplest and usually quickest restore method for the virtualized DC in the event of a complete disaster will be the VMware restore of the whole VM as such there is little point in doing a specific system state backups (uses more time to backup and more complicated DR restore.) I am concerned you are muddling up the benefits of an image level backup and restore of your whole VM vs the way you have to restore if you only have file and system state level backups. The option you highlighted in your screenshot cannot be used for a complete System State restore.

If you want to test restoring an AD object using the GRT part then probably safest way is use a test user that you can delete after the backup and then restore back into production and not worry about a redirect. If Active Directory GRT is enabled you should be able to use the option you highlighted to restore this test user.

The System state of the Hyper-V host will not contain Active Directory information unless it is also a DC. If you are concerned about protecting the operating system of the host then as long as the host only provides Hyper-V functionality and no other roles then you might find that documenting how to re-install from the OS CD with same settings and then install Backup Exec is a more efficient restore process then the steps you have to use to recover a backup. (Note you would want to backup some parts of Backup Exec (BEBD, Catalogs etc if you can in order to speed up the process of restore.)

[ACampbell-SCL]

@Colin

Thanks for the insights on this... Regards to the host level backups (image level), the plan was to have an offsite backup of all the VM non-GRT as the backup times are generally quicker and then with GRT backups of the individual VMs restore the differential data.

But what I understand that the doing a redirected GRT restore to a different host with the same VM is not possible for the system state (Active Directory).

So I can either:

1) Create an offline DR environment with all the host names, VM and IP are the same as the production environment (as yourself and VJware mentioned) 

2) Do a live test on the production environment, by creating a test user and deleting them between backups

I'm leaning towards option 1.

[Colin_Weaver]

Irrespective of GRT vs non-GRT as long as it was a VM backup the DR capability for all of AD is the same you would restore the whole of the VM (the DC)

Restoring one user is not technically DR as that is just an individual object restore in the same way that restoring one file is technically not a DR (However GRT is not really thought of as a DR process anyway so this is not an issue)

What we keep trying to say is that to prove DR just restict the restore of the whole VM to your other host and you do not need to build an offline environment to do this (although be careful to make the restored VM be sitting in a restricted network before you power it up to se the results)

If you want to prove you can restore one user in Active Directory (which is not a DR) then just restore a test user

[ACampbell-SCL]

Agreed...

But my aim was to restore the difference in data, as the whole VM image could be 3 months out of date. I could do a daily backup (at host level)  with GRT of the VM and it will solve the problem. But for a file based restores it's not practical as BE2014 will recreate the whole VHD and then extract the file, I don't have the space to hold the VHD file to complete the process.

So creating a DR environment with the same server names and IP addresses will make it more simpler for testing without interfering with the production environment. This will cover all the bases.