Once a quarter companies should go through an audit process to validate that a backup of system can be restored. In most companies the most important server to validate a backup of will be a database of a production server. If the database was properly setup, you will find that there will already be an internal backup of the database to the server’s X: drive. This X: drive is the best target for our data protection system to create a backup image from. Once backed up, we can restore it in two different ways depending on if the backup was of a physical or virtual server.
Here we will look at the recovery of a database from a physical server. We will assume that this is a loss of a server and we need to recover the database in the fastest possible way. We will restore the directories of the X: drive to a virtual server as this should be easily deployed by a pre-configured template in VMWare.
I will not go through how to deploy a server from a template in a VMWare environment as that is another subject. I will touch on a Business Continuity solution for such a disaster situation. I have two purpose built virtual servers in my environment. One was created for restoring a physical server’s X: drive database to this virtual server. The other is to restore the virtual hard disk or VMDK file of a virtual server’s X: drive, directly to the second purpose built virtual server. In both cases, I had the DataBase Administrator (DBA) setup both servers, as though they were a less beefy version of the original.
Both of these servers were created for restoring the X: drive, for the purpose of validating restores for the quarterly audits, but either could become a pre-configured disaster recovery server for a database.
The virtual to virtual database only restore will be a result of a failed operating system and the backups were of an already failing OS was not bootable after restore. Mounting the backed up X: drive to the virtual server is an easy solution. In this solution there is no need for the X: drive to exist on the server before we mount the restore to this server. If you want to look into this tutorial go How To Restore A Virtual Hard Drive Using Avamar.
The rest of this tutorial we will walk through the restore of a physical server’s backed up X: drive to a pre-configured virtual server. To begin we have to have an existing X: drive already present on the target server we are restoring to. This virtual drive will need to be larger than the originally backed up source hard drive. I usually give it an extra 50GB of space. In this case my backup on the X: drive is 797.3 GB so I make my virtual disk 850 GB.
Because we are going Physical to Virtual (P2V) we will need to create a share on the new 850GB drive. If the server is setup for RDP we can access the server and navigate to the X: drive. Right click the drive and go to Properties and then the Sharing tab. Here we will select “Advanced Sharing…” button.
We will check the “Share this folder” box and click on Permissions button.
Now you may have a service account in Active Directory (AD) for your Avamar that you should add here. For simplicity, we will put “Everyone” has permission to access this share. And yes anyone could access it if they knew it existed and how to find it, but no one does and we will unshare it once the restore is successful.
On this page, as long as we used RDP and not the VMWare console to access the virtual server, we can highlight the network path can copy it with a Ctrl+C.
Now we move to our Avamar and locate the backup of the physical server. We select our backup and right click and select “Restore Now…”.
Select “Restore everything to a different location” and then click on “Set Destination”
Here we will paste in our share Network Path and click OK. Bare in mind that this part of the process is not possible in the Avamar Web UI and is only available through the Java based Avamar Console.
Now click on “More Options”
Click “More”
Here we need to enter the attribute ” [avtar]ignoreacls ” and it is equal to ” true ” (without quotes) and click on the + sign to add it.
This will tell the restore so ignore the Access Control Lists (ACL) of the restore. ACL’s can be looked at as permissions for the restore. In this case, if we do not add this ignore attribute the restore will be successful, but the DBA’s will see the database as corrupt and inaccessible. This is because the database realizes it is not in the same server as it was originally and locks the database from being accessed.
Now we click OK and check our server’s file share for new files.
And already we see data populating the share.
Once the restore has competed, we can remove the share network access to the X: drive. Be sure to wait for the restore to complete in the Avamar console before informing the DBAs. As Avamar restores the data it first puts a placeholder of the file or directory that shows that it is fully restored data. This is not true as the placeholder is needed and then the data is added in the restore process. The database is not usable until Avamar has completed in the Activities section of the Avamar console. Once completed we can inform the DBA’s to validate the data for the audit.
