VIDEO: NetBackup Support Screencast Demo: Performing an Exchange 2007 Snapshot/Cluster Continuous Replication (CCR) database restore to a Recovery Storage Group (RSG) using NetBackup 6.5

Article:HOWTO41848  |  Created: 2011-01-19  |  Updated: 2013-10-24  |  Article URL http://www.symantec.com/docs/HOWTO41848
Article Type
How To


Subject


The video linked to is a part of the NetBackup Support Screencast Demo Video series.  It demonstrates Performing an Exchange 2007 Snapshot/Cluster Continuous Replication (CCR)  database restore to a Recovery Storage Group (RSG)  using NetBackup 6.5
 
 
 
TRANSCRIPT OF VIDEO:
 
Welcome to the NetBackup Support Screencast Demo Video series.
 
These videos deliver how to demonstrations in a variety of NetBackup functions.
 
They assume fundamental NetBackup knowledge.
 
If you need basic NetBackup training, please go to http://education.symantec.com where you will be able to find a listing of instructor-led classroom training as well as self-paced computer-based courses for NetBackup.
 
This video is Performing an Exchange 2007 Snapshot/Cluster Continuous Replication (CCR)  database restore to a Recovery Storage Group (RSG)  using NetBackup 6.5
 
For this demonstration, we will be using a master/media server running NetBackup 6.5.6 on Windows 2003 R2 SP2. We have an Exchange 2007 running NetBackup 6.5.6 on Windows 2008 R2. The Exchange 2007 server is clustered and configured for CCR.
 
This video does not apply to:
Exchange 2010
Exchange 2003
Stream-based backups
NetBackup 7.0 or higher
 
Please also note that for NetBackup version 6.5, there have been numerous features added, as well as streamlined, regarding backups and restores of Exchange 2007 throughout the NetBackup 6.5 update releases. For the demonstration in this video, we will be covering the configuration as it relates to NetBackup 6.5.4 and later. It is also highly recommended that NetBackup 6.5 be at update release 6.5.4 or later for Exchange backups and restores.
 
To start, we need to work on the Exchange 2007 active node to create the Recovery Storage Group. We open the Exchange Management Console, click on Toolbox, and then double-click on Database Recovery management. After the update check, we click Go to Welcome screen to continue. We fill in a label for this activity, double-check the Exchange server and domain controller names, and then click Next to continue. 
 
Here, we click Create a recovery storage group, then choose the storage group with the database we want to restore, then click Next. Here we confirm the name and file paths used for the creation of the RSG. In this example, we will leave the default settings, and click Create the recovery storage group. We see the RSG has been created successfully, so we will close the Exchange task center. The database in the RSG should already be dismounted and the flag to allow the database to be overwritten by a restore should already be set. 
 
We can confirm the RSG database status by running the command shown in the Exchange Management Shell:
Get-MailboxDatabase -Identity "<Name of RSG>\<Mailbox Database Name>" -Status | format-table Name,Recovery,Mounted,AllowFileRestore
 
No other steps should be required, and Exchange is now ready for the restore.
 
After preparing the client, we will bring up the master/media server for this demonstration and go to the Backup, Archive, Restore (or BAR) GUI. We start by going to the File menu and click on Specify NetBackup Machines and Policy Type. In the resulting window, we set the source and the destination to be the Exchange 2007 cluster virtual host name. We also set the policy type to MS-Exchange-Server.
 
We are using the BAR GUI on the master server, although we could also be using one on a NetBackup remote administration console host. In either way, we can see the destination client field is available to be set to a specific host. However, if we were using the BAR GUI on the active node of the Exchange 2007 cluster, the destination client field would not be visible and the hostname of that cluster node is automatically used as the destination client name. The destination client name used by NetBackup for the restore would then be the physical node name of the client. If the physical node name is used by NetBackup when talking to the Exchange restore API, no Exchange server will be found and the restore will fail. However, to properly perform the restore, the virtual name of the Exchange cluster is the one that should be specified for the restore within NetBackup. Therefore, if you are restoring a database on a clustered Exchange server, you must use the BAR GUI on a master server or Remote Administration Console and specify the virtual name of the Exchange cluster as the destination client.
 
We click OK on the Specify NetBackup Machines and Policy Type window.
 
Next, we click on the Select for Restore button. Initially, we see the backup images in a Timeline view. This doesn't provide much information about each backup, fulls are green and differentials are blue. It is recommended that you go to the View menu and deselecting the Show NetBackup History as a Timeline setting as we are doing here to get more information about each backup, including the specific time backed up. To select multiple images for restore, we click on the full backup we want to restore and then, holding down the <shift> key, we select the differential image up through which we want to restore. This will select the full image and all differential images we want to restore through.
 
Next, in the All Folders pane in the BAR GUI, we drill into the Information Store and click on the storage group that we want to restore the database from.
 
It is important to note that with NetBackup 6.5, there is a caveat regarding how to select the files for restore, when restoring a snapshot backup to an RSG for Exchange 2007. This also only applies for a restore that contains a full backup image, as well as one or more incremental backup images. Instead of selecting the individual database or log files in the right-hand pane, we should select the checkbox for the original storage group itself in the All Folders pane. We can see that there is a visual difference in how the selection looks, depending on how we select the files. If we select individually in the right-hand pane, each item has a checkmark and the storage group shows a slash next to it. When we select the storage group itself in the left-hand pane, the storage groups has a checkmark next to it instead of a slash. The individual items appear the same as before and again show checkmarks. If the selection is done incorrectly for this type of restore in NetBackup 6.5, the restore will be successful for the full backup image, but will fail when trying to restore from subsequent incremental images. 
 
This is the error we would see in both the Detailed Status tab of the restore job in the Activity Monitor as well as in the View Status output from the BAR GUI. In another Exchange 2007 environment, the storage group name and ctime stamp in the file representing the transaction log files will, of course, differ. The BEDS error code and error message will be the same, however.


 
"ERR - error writing Exchange object: Microsoft Information Store:\Admin Storage Group\Logs_1286381760 Error: BEDS 0xE000FEE5: A failure occurred restoring because the files cannot be replaced and no alternate location was specified."
 
Once we've marked all the files we want restored, we click on the second icon down on the left-hand toolbar, which is the Start Restore of Marked Files. This brings up the Restore Marked Files dialog box. We click on the Microsoft Exchange tab. 
 
Here we see Roll-Forward Recovery and Point-in-time recovery. With the Point-in-Time recovery option, only the logs being restored are replayed. The Roll-Forward recovery option will replay all restored logs, but will then continue with rolling forward any other logs that may exist on the system since logs were last truncated. Since we are restoring to an RSG, there will be no other log files on the Exchange server to roll forward, so we will do just the point-in-time recovery.
 
The Temporary location for log files setting is unavailable, as it is unnecessary for an Exchange 2007 database restored from a snapshot backup.
 
We see a Dismount database prior to restore option. The database in the RSG is dismounted by default, so this option should remain deselected. Please note that any time a database needs to be dismounted, it is recommended that dismounting be done from either the Exchange Management Console or the Exchange Management Shell. This ensures that the correct database is dismounted. Using the option here only could result in the wrong database being dismounted and overwritten, if the restore does not use the intended storage group and database destination.
 
The next two options are Commit after last backup set is restored, which tells Exchange to recover the database after we restore the full and all log files, and Mount Database after restore, which will actually mount the database after it is recovered. These are both selected by default. However, please check with your Exchange Administrator to ensure they are appropriate actions at the end of your restore. 
 
The last option, Redirect to Recovery Storage Group (Only for Exchange 2007), as the name implies, is for Exchange 2007. It is only available for a restore from a snapshot backup, such as the CCR passive node backup in this example so we will go ahead and check it. 
 
With the last option checked, there are no applicable settings under the General tab so we will click the Start Restore button. A message will appear indicating the restore has successfully initiated. We click Yes to see the View Status window.
 
In the Activity Monitor of the NetBackup administration console, we see the restore job and can double-click on it to see detailed status. In the Detailed Status tab, we can see some further information about the progress of the job: connecting to the client, starting the bptm process to read from the images. For this demonstration, we should see 2 sub-jobs start as part of Job ID 234, namely we should see 2 different restores, one for the full and one for the two differentials.
 
If we go back to the BAR GUI’s view status window, we will see similar information. For instance, we can see that we have a status 0 on the full with 4 of 4 files successful. The next job is the differential with a status 0 and 3 of 3 files successful. We also see that there are messages about remaining jobs. After the first job, it said there was one job remaining and, therefore, recovery would be deferred. After the differential, it says there were no jobs remaining and recovery would be performed. We can see here after the last differential, there is a status 0. 
 
Looking in Activity Monitor, we also see the job with a blue man and a status 0. On a restore, any final status other than 0 should be considered an unsuccessful restore and the cause should be investigated and the restore retried.
 
We can now go back to the client and confirm that the database in the RSG is now mounted after the successful restore, by running the Get-MailboxDatabase command shown in the Exchange Management Shell:
Get-MailboxDatabase -Identity "<Name of RSG>\<Mailbox Database Name>" -Status | format-table Name,Recovery,Mounted,AllowFileRestore
 
Length: 11:30
 
 
Reference:
Microsoft Exchange 2007 Management Shell Cmdlet reference:
Get-MailboxDatabase
http://technet.microsoft.com/en-us/library/bb124924(EXCHG.80).aspx



Article URL http://www.symantec.com/docs/HOWTO41848


Terms of use for this information are found in Legal Notices