System Recovery Using Symantec Backup Executive System Recovery

When a tech support call to a large hardware manufacturer left my laptop unbootable, I found myself cursing the heavens. After I had calmed down, I remembered that my data was being protected by Symantec Backup Executive System Recovery 8. Perhaps this was not going to be as bad as I had initially feared. This article details my adventure into the not-so-well-documented world of system recovery.

For those that are not familiar with Symantec Backup Executive System Recovery (BESR from here on out), the premise behind the product is quiet simple - install an agent on the computer and at scheduled intervals a backup of your entire hard drive is automatically captured in the background and placed on a second drive type of your choosing. A form of incremental backup is also available for a subset of the files on your hard drive (for example My Documents, My Favorites, etc). There are several other unique features to the product that I will discuss later in this article.

Altiris users might already be familiar with Altiris Recovery Solution to perform a similar function. While there are three versions of Recovery Solution (local, server and mixed), the fairest comparison between BESR would be Altiris Local Recovery Pro. I will point out that in the current version of BESR, Recovery Solution fans will be disappointed in that Redundant Block Elimination (RBE) and Redundant File Elimination (RFB) technologies are not currently available in BESR. Symantec Product Manager's are working hard to reconcile some of these gaps between the two solutions.

Like most laptop users, my laptop has one internal 80GB hard drive. BESR is configured to back up my data to an external USB 2.0 Seagate 100GB drive twice a day. It is also possible to backup to a second hard drive or even a network location. And for corporate environments, there is a management server for the product that can be used. In working with BESR 7 and now 8 over the past six months, I've learned that as a best practice the hard drive that is backing up the data should be at least 20% larger in size than the source hard drive. This ensures that BESR can store multiple copies of the incremental backup files along with multiple recovery points.

Another important point about BESR to understand is that in order to do a full restore of a system, a BESR Recovery CD is required. Symantec provides an ISO with the installation media and administrators should have a copy of this ISO burned to a CD. To launch a full system recovery, insert the Recovery CD into the system, boot from the CD and then walk through the wizard to begin the backup.

Things get a little more complicated when you introduce virtualization into the mix. In my scenario, I was waiting for the hardware manufacturer to show up with a new motherboard for my laptop. Being without my data for two days wasn't an option and looking at the physical equipment I had available, I decided to restore the data to a VMware virtual machine.

The following steps detail how to properly configure the VMware virtual machine:

1. Make sure the removable hard drive with the BESR backup is NOT connected to the machine with VMware installed.
2. Open VMware Workstation 6 and create a new Virtual machine with at least 512MB of RAM and a hard drive size that is the same size as the original machine.
3. As indicated in the screenshot below, make sure the USB Controller is part of the hardware profile for the VM. It is critical that the Connections option "Automatically connect new USB devices to this virtual machine when it has focus" is enabled.
   
   

   Click to view.

4. Change the VMware CD-ROM to point directly to the BESR Recovery CD ISO file, rather than attempting to let the VM boot from the physical recovery CD.
5. Turn on the VM and the BESR Recovery CD will begin loading.
6. When prompted by the BESR Recovery CD, Agree to the Symantec License Agreement
7. This step is the tricky part. Immediately after accepting the license agreement a 10 second prompt will appear asking if networking services are necessary. During this 10 second timeframe, Windows PE Plug and Play detection is available. Plug in the removable hard drive during this 10 second window. If done properly, VMware will recognize the drive has been attached and will enable the device as indicated by the USB icon in the lower right-hand corner of the VMware window.
8. If everything worked properly the BESR Recovery Disk is now loaded as indicated in the screenshot below:
   
   

   Click to view.

9. Choose the option Recover My Computer to launch the "Recover My Computer Wizard"
10. After several more choices, the recovery process will begin.
11. When the recovery process is complete, reboot the system and your system is back up and running.

Depending on a variety of factors, the previous process may work great - or if you are cursed like me, it may not. After sitting through a 2 hour 22 minute and 32 second recovery of my 74.6 GIG of data, the VMware image rebooted, and proceeded to hang at a black screen indefinitely. But hope is not lost - it was now time to attempt a BESR physical to virtual recovery.

Earlier in this article I mentioned BESR has some unique features. One of these features is the ability for the product to convert its own backup files to VMware virtual hard drives. This feature is available from the BESR console along with several other options (as seen in the screenshot below).

Click to view.

Using my desktop PC (also running BESR), I launched the BESR console, chose the Tools option, and selected Convert to Virtual Disk. It is worth noting that prior to launching the console I plugged in the USB removable hard drive where the backup of the original system was stored. The "Convert to Virtual Disk Wizard" is then launched.

The Virtual Disk Wizard can be a bit confusing in this scenario. Remember that in my case BESR is running on my desktop computer and backing pp my desktop computer to Recovery Point A. I've plugged in the hard drive from my laptop which is Recovery Point B. BESR doesn't understand this. The result is that immediately after clicking "Next" on the "Convert to Virtual Disk Wizard" the "Source" screen is displayed showing the dates available for the backups of my desktop system - not the laptop that I'm trying to restore. To correct this, change the "View By" option from its default setting of "Date" to be "File Name," then browse to the location of the backup files. Once this is selected, finish the wizard and kick off the conversion.

For comparison, I mentioned early that it took BESR 2 hours, 22 minutes, and 32 seconds to recovery 74.6 GIG of data. The conversion process from the backup to the virtual hard drive completed in 66 minutes and 15 seconds.

Now if you are like me, reading through hundreds of pages of documentation is not how I like to spend my weeknights. In fairness to Symantec, perhaps the following major caveats are explained in the product documentation:

• The conversion process examines how much data is stored in the file and will create a virtual hard drive for EXACTLY the amount of hard drive space that was backed up. In my case, I had 74.6 GB of data, now I have a 74.6 GB virtual hard drive. I could find no way to configure these settings to create a larger virtual hard drive.
• I used VMware Workstation 6 as my virtual environment. Upon booting the VM, I was greeted with the following message from VMware Workstation:
  
  

  Click to view.

• Fearing the worst for my data, I chose "No" at which point a second VMware warning is now displayed:
  
  

  Click to view.

• The implication of both of these messages is that it is going to be more work to make sure things continue to function in the virtual environment than I had anticipated.
• A third message confirms that VMware Tools is not installed in the VM. This should be done as soon as possible.
• Much to my horror, part of the conversion process from physical to virtual involves the virtual hard drive being programmed to run Microsoft Sysprep as soon as Windows boots. Again, I can find no way to alter this behavior.

While running Sysprep gives Windows a chance to recognize the new virtual hardware instead of the physical hardware that was previously installed, the Sysprep process does not preserve the existing domain setup and configuration -instead it prompts for credentials to rejoin the domain. This is a problem for remote users such as me who VPN back into a corporate office - thus leaving my restored machine unable to join the domain. I suspect that I'm in the minority on this one so perhaps this is not such a big deal for most users. This product can also be run on servers and so this might be a bigger problem in that arena. Either way it is a good point to remember.

Despite the bumpy road, the end result is that my data was safely restored and I was able to access the information I needed.