Preserve tape media label & description in Backup Exec 2012

If you want to use the description field of a tape in Backup Exec to identify the backup media set. You will notice once tape is rewritten or formatted the description is lost.

These fields can come in handy for example when you are trying to identify tape 1 as week 1 or as month January.

To change this behaviour, follow this procedure:

  1. Use regedit to locate the following key HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Backup Exec for Windows\Adamm.
  2. within the ADAMM key create a DWORD value called: PreserveMediaDescriptions.
  3. Set the value to 1 to maintain the media descriptions during overwrites.
  4. Restart the Backup Exec services.

More information can be found in this technote.

Registry change after installing Backup Exec 2010/2012 on a Hyper-V 2008R2 node

Installation of Symantec Backup Exec 2012 is fully supported on Windows 2008R2 Hyper-V nodes as described in the Software Compatibility List. However after rebooting the node, Hyper-V throws the following errors. Important to note is that the cluster itself is online without any warnings or errors as described in this post. The errors are visible after live migrating a virtual machine to the impacted target host or when you attempt to start a virtual machine on the impacted node.

‘VM Name’ failed to start.

Microsoft Emulated IDE Controller (Instance ID {########-####-####-####-############}): Failed to Power on with Error: ‘A device attached to the system is not functioning.’

Failed to open attachment ‘Drive Letter:\path\Virtual Hard drivers\VMNAME_########-####-####-####-############.vhd’. Error: ‘A device attached to the system is not functioning’

Failed to open attachment ‘Drive Letter:\path\Virtual Hard drivers\VMNAME_########-####-####-####-############.vhd’. Error: ‘A device attached to the system is not functioning’

and

‘VM Name’’ Microsoft Emulated IDE Controller (Instance ID {########-####-####-####-############}): Failed to Power on with Error: ‘A device attached to the system is not functioning.’ (0x8007001F) (Virtual Machine ID: ########-####-####-####-############)

Some research resulted in the following conclusion:

  1. In the Kernel Mode the following components exist:
    • Fsdepends.sys: File System Dependency Manager Mini Filter Driver
    • Vhdmp.sys: VHD Miniport Driver
    • vdrvroot.sys: Virtual Drive Root Enumerator
  2. The VirtDisk.dll uses the above mentioned components for starting the VDS VHD API’s.
  3. And those are used for the Virtual Disk Service which is configured with a manual startup type…

.
Continue reading

Why Backup Exec CASO catalog replication is not a redundant solution

I started with a Backup Exec 2012 project for a larger company some months ago. One of their demands was to build a high-available solution with enough scalability for the next two years. The first thing that pops-up in my mind was an implementation of a Backup Exec Central Administration Server Option (CASO) with catalog replication. That should do the trick!

What are catalogs? The catalog and the database are required to perform restores of the data that has been written to tape. When losing the catalog, you are unable to select data to be restored. Compare it with a book without an index. You know it’s somewhere in the book, but can’t tell if it’s in chapter 1 or in chapter 25.. Ofcourse you have the ability to rebuild your catalog by performing a “catalog media” job. Needless to say this is a time-consuming job!

During the implementation, it came to my attention that this was not a redundant setup. I started a search with the best consultant on the world = Google and I was quiet disappointed with the results. Apparently nobody posed this question before or has written something about it. I saw this as an opportunity and wanted to clear this one out.

First of all, there are three ways catalogs can be stored. These are described in the Backup Exec 2012 Administrator’s Guide.

Continue reading

How to restore share information by using Backup Exec 2012

Some time ago, someone contacted me regarding configuration data he lost during cluster disk migrations. Apparently he performed a wrong action whereby all the share information was lost. It should be quiet easy to recreate them, but the customer had no documentation or whatsoever about it.

So there was only one solution… trying to restore the system state of the server to another location. During this process we came across with the issue that share information of a cluster is not stored in the “normal” location.

Continue reading