Blog: Backup Exec

Since Veritas took over Backup Exec from Symantec, we’ve had issues getting licensing migrated and renewed for various reasons.  

For one customer we had recently renewed maintenance for one year and needed to apply the license to the Backup Exec console. In the console, I could see there were product licenses and maintenance licenses. The maintenance licenses had indeed expired. 

When I went to the Veritas licensing portal to retrieve the licenses, they showed an expiration date in one year from now. I downloaded the new licenses, but no matter what I tried to import or delete existing licenses, it never would display the new maintenance expiration dates.

I called Veritas and they changed the way maintenance licenses are managed from the Veritas portal; they are not managed on the Backup Exec console any longer.  You can ignore the dates for the maintenance contract now since they moved over to Veritas.


 

After migrating from SBS 2003 to Server 2008 R2, and upgrading Backup Exec from 12.5 to 2010 R3, I received an email stating backup had failed. [more] 

The error wasn’t too helpful and stated: “Final Error: 0xe00084af - The directory or file was not found, or could not be accessed.” and “Directory C:\WINDOWS\SYSVOL\sysvol\DOMAIN.com\DO_NOT_REMOVE_NtFrs_PreInstall_Directory was not found, or could not be accessed.” 

After some searching through the Symantec KB, I stumbled upon this article -- http://www.symantec.com/docs/TECH209355 -- which stated that this error may occur when conducting a volume-level backup of the system drive after applying Backup Exec 2010 R3 Service Pack 3. There wasn’t a fix for the problem, but their was a workaround which stated "Create a new backup job by selecting the server from “Favorite Resources” or “User-defined Selections” "

Sure enough, selecting the resources so that it would back up via file://servername/c$ instead of C: allowed it to function correctly.


 

Do you remember playing those games where you would look at two seemingly “identical” pictures and try to spot the 5 differences between the two? I’d like to play that, except there’s only one difference between these two:

Here’s the situation. We’re hosting files off of a CIFS share on our NetApp device. We needed to back up this CIFS data using Backup Exec. I went through and set up NDMP on both the NetApp and Backup Exec so that the communication could be established for Backup Exec to connect to the CIFS share and grab a copy of the data. In order to get the resource credentials to show successful, I had to set the Logon Account for the NetApp to be our domain Backup Exec Service Account (BESA) and the actual CIFS share to be the NDMP user account I had created for backup.

Secondly, there is another gotcha associated with how to set up the NDMP account for backup. If you use the root account, you can simply use the regular password as if you were logging into the NetApp device from the backup server. However, if you decide to create a new account, you must encrypt the account on the NetApp device. To create the account, do the following:

useradmin user add <login_name> -g “Backup Operators”
(Type in the password)
ndmp password <login_name>

The output after the password is what you will copy and paste into the backup server so that the NDMP user can authenticate.


 

We recently ran into a problem where a job in Backup Exec was failing when backing up the vmdk using Virtual Consolidated Backup (VCB).  Backup Exec was reporting the following error message: and reportint the following error message:  "The Virtual Machine resource is not responding."  After some trouble shooting and research we discovered an unallocated disk may cause Backup Exec to fail with that error when another allocated disk is beng backed up.  This turned out to be the problem in our case as we had an unallocated disk. [more]

Here is some more informatino about the issue from Symantec: http://www.symantec.com/business/support/index?page=content&id=TECH174797


 

Block level vmdk backups have limitations that will GET YOU.  Backup Exec and Veeam both have the ability to backup the vmdk files in a VMware environment and still retain enough information in the backup set to do individual file level restores.  However, both products will ONLY work if you have vmdk disks partitioned using the MBR (Master Boot Record) type tables and NOT the more modern GPT (Guid Partition Table) structure.


 

I was setting up Backup Exec 12.5 to function as a VCB proxy to back up our VMs at a VMDK level and ran into a few problems. Version 12.5 has this functionality built in so it was fairly simple to back up a VM from the SAN to the VCB proxy. Restoring it back to the vCenter cluster, on the other hand, was a different story. The first problem I ran into was in running a simple restore. The job would fail as it would try and convert the machine. Simple fix: Install VMWare Converter Standalone on the proxy. [more]

Problem 2: The job would fail and give me a suggestion that I might try restoring the machine as a redirected restore job.

Problem 3: When I tried to set up the job for a redirected restore, I receive “Access is denied.” when it attempts to connect to the vCenter and datastores.

Solution: UAC was causing the access to be denied. If I started Backup Exec as an administrator or disabled UAC on the machine, I was able to get access to the datastores and set up the redirected restore. From there, my restore jobs were successful. Now I did run into other slight problems with this restore, but I’ll save that for another time.


 

In troubleshooting a SBS 2003 Server, it was discovered that the system drive was almost out of space.  Upon further investigation, most of the disk space was being consumed in the %WINDIR%\Installer folder.  In that folder were numerous MSI files that were over 100 MB each over and over. 

It was noted that earlier in the week, an update for Backup Exec kept trying to install and failed until the server was rebooted by the customer.  After rebooting the server, the install took, but all of those failed attempts seemingly left these orphaned MSI files created each hour the server tried to install the update.

In order to clean out the orphaned files in this folder, you will need to run “MSIZAP.exe T!”.  You can obtain the MSIZAP file from: http://support.microsoft.com/default.aspx?scid=kb;en-us;290301.  Syntax for running MSIZAP can also be found here: http://msdn.microsoft.com/en-us/library/aa370523.aspx. [more]

After running this program, it deleted over half of the files in the Installer directory and reclaimed approximately 10 GB of hard disk space.  It was noted that the duplicate 100 MB+ files were removed.


 

To export a selection list in Backup Exec – edit job, select Submit, copy and paste.  This will give you a nice text version suitable for saving, searching, etc.  Portions of this can be copied and pasted back into the text view of the selection list.

The selection lists are accessible in the SQL server in the BEDB database in the vwScriptPropertiesBackup view.  The fields of interest are ScriptName, ScriptDescription, DeviceSelectionName, PathName, and FileName. A SQL command like this could be used to list these fields.

SELECT [ScriptName]
      ,[ScriptDescription]
      ,[DeviceSelectionName]
      ,[PathName]
      ,[FileName]
  FROM [BEDB].[dbo].[vwScriptPropertiesBackup]

You could set up a DSN and access this with Excel, or use the sqlcmd from the command line.  Adding a WITH clause to select a particular selection list could be useful also.

UPDATE:  This is not applicable to BackupExec 2010.  Instead, you can go to the Job Setup tab, find the selection list, right click "View Summary", and then highlight and copy the text from the window that pops up.


 

We recently ran into a problem where one of our customer's servers was randomly rebooting. It looked like the cause of this was the updates from Backup exec that were being downloaded and installed. We checked backup exec and it was not set to install updates at all. After some research we found that they updates were being installed even though it wasn't set to do so. [more]

We noticed the updates were occurring the same time as the SMSE updates. After researching with Symantec I found that by default Backup Exec is registered with LiveUpdate and is configured to receive updates ANYTIME LiveUpdate is run from ANY Symantec application configured to use LiveUpdate. Thus every time that SMSE started LiveUpdate it would install Backup Exec updates as well. I downloaded a utility (BeUpdateOps.exe) that I used to unregister Backup Exec from LiveUpdate and this stopped the random reboots.


 

When using the Advanced Open File Option with Backup Exec, make sure you check the Job Log to see if it is actually getting used correctly. I wanted to use it to back up VMWare Server virtual machines at CITBA. The job was running successfully, so I thought it was working correctly. We started getting calls that VMs running on that server could not be reached by users trying to RDP to them. Once the OSE connected to them via the VMWare Server console, the app would show an "access denied" error (only once) and then go away and stuff would start working. [more]After research, it was discovered that Backup Exec was actually using standard backup (not AOFO) to backup the VM vmdk files thus causing a file lock issue with VMWare Server. Note the very inconspicuous log below.

You can find this is the "Job History" tab of the job log. The reason was that no AOFO licenses were installed. So, the moral of the story is Backup Exec will let you select the AOFO option in a backup job and let you deploy the Backup Exec agent with the AOFO option even in you don't have the license installed. Thus, making you think AOFO will actually work, but don’t be fooled. It doesn't.