The video linked to is a part of the NetBackup Support Screencast Demo Video series. It demonstrates Restoring an Exchange 2003 Stream-Based Database Backup to a Recovery Storage Group (RSG) using NetBackup 6.5 and 7.0.
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 Restoring an Exchange 2003 Stream-Based Database Backup to a Recovery Storage Group (RSG) using NetBackup 6.5 and 7.0.
For this video, I will be using a master/media server running NetBackup 7.0.1 on Windows 2003 R2 SP2. The Exchange 2003 client is running NetBackup 7.0.1 on Windows 2003 R2 SP2. It is a stand-alone server. Although we will be using NetBackup 7.0.1, the interface and configuration settings are the same for NetBackup 6.5, so the information presented here can be applied to a NetBackup 6.5 environment as well.
This video does not apply to:
NetBackup versions prior to 6.5
To start, we need to work on the client in the Exchange System Manager to create the Recovery Storage Group we will be using for the restore. We open the System Manager, then drill down into Administrative Groups, then the Administrative Group our Exchange server is in, then Servers, and then the Exchange server that we want to create the RSG for. We right click on the server and choose New, then Recovery Storage Group. And then see the Recovery Storage Group Properties dialog. Under the General tab, we can define the name of the RSG, as well as the transaction log and system paths for the RSG, although we are going to just go with the defaults here. The Details tab can also be used for any notes we may want to add, but we will keep it blank. Then we click OK to create the RSG. Now we see our RSG amongst the other Storage Groups for our Exchange server.
We also need to add the database we want to restore to the newly created RSG, so we right-click on the RSG and choose Add Database to Recover. This will bring up the Select database to recover dialog, where we see the databases available to add to the RSG. We select the database we want to restore and then click OK.
The Properties dialog comes up where we can make changes to attributes of the database we are adding to the RSG. Under the General tab, we can change the name. Under the Database tab we can change the paths for the edb and stm database files. We also see a checkbox for the This database can be overwritten by a restore setting, which we will leave checked. There is also another Details tab for notes we may want to add. We are going to leave all of the default settings, as the physical file path on the hard drive should already be set from the previous step of creating the RSG itself. If we did want to put the databases files in a different path, however, this is where we would define those paths. Here we click OK to add the database to the RSG. We can drill down into the RSG, and see the newly added database in a down state. 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 into 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 2003 server host name. We also set the policy type to MS-Exchange-Server.
In this example, we are restoring to Exchange 2003 running on a single server. If we were restoring to an Exchange 2003 server running on a cluster, we would need to make sure that we set the destination client to the Exchange 2003 virtual cluster hostname. Please note that setting the destination client name for a restore can be done only from either running the BAR GUI on a master server or from a NetBackup remote administration console host.
If we were using the BAR GUI on the active node of the Exchange 2003 cluster, the destination client field would not be visible and the hostname of that cluster node would 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 would fail. To properly perform the restore to an Exchange 2003 cluster, 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, it is necessary to use the BAR GUI on a master server or Remote Admin 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. Fulls are green and differentials are blue. It is recommended to 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 database that we want to restore. Then, in the lower right-hand pane, we click the checkboxes for the database and log files we want to restore.
Differential backups will back up the transaction logs and then truncate. Thus, they only contain the logs since the most recent full or differential backup. This is why we selected 2 log file backups in addition to the logs from the full backup, because each one was a differential backup and truncated the logs after it was complete. No cumulative backups are shown here, but note that they do not truncate logs. Because of this, they contain all log files since the last full backup. They have the disadvantage of each successive cumulative backup being larger because it includes all logs since the last full, whether those logs had been backed up before or not. However, the benefit is that in a restore, you only need to select the full backup and the most recent cumulative backup.
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 button. This brings up the Restore Marked Files dialog. We click on the Microsoft Exchange tab.
We see two options for replaying log files, 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 log files 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.
You must specify a Temporary location for log files. This is where the log files will be restored to so they can be replayed. Once they are played forward, they are deleted. It is important that this temporary path exists on the client, as it is not created on the fly. If the path does not exist, the restore will fail.
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 anytime a database needs to be dismounted, it is recommended that dismounting be done from the Exchange System Manager. 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, and is unavailable since we are restoring Exchange 2003 from a streaming backup.
Next, we click on the General tab. Since we are restoring to an RSG, we need to select the 2nd radio button, Restore everything to a different location (maintaining existing structure). In the Destination setting, we need to change the original Storage Group name to the RSG name. For this demonstration, we are using the Exchange 2003 default, "Recovery Storage Group". No other settings are applicable for now, 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 Job Overview tab we can see our database and the log files from the full and two differentials. In the Detailed Status tab, we can see some further information about the progress: connecting to the client, starting the bptm process to read from the images. For this demonstration, we should see 3 sub-jobs start as part of Job ID 582, namely we should see 3 different restores, one for the full and two 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 and we see the final differential completed also. We also see that there are messages about remaining jobs. After the first job, it said there were two jobs remaining and, therefore, recovery would be deferred. When we had one job remaining, recovery was still being deferred. After the last differential, it says there were no jobs remaining and the recovery will 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 go back to the client and look at the Exchange System Manager. The database still appears to be in a down state. We click the refresh button in the toolbar to refresh the view information. Here we can see that it is now mounted and that there are mailboxes inside it.
This video may be viewed by clicking on the following link: www.symantec.com/tv/products/details.jsp