Best practices for off-host backup

Keep source volumes and snapped volumes from sharing the same physical disks. Otherwise, any attempt to split the snapshot volume from the original volume fails.

Most hardware and software providers have some limitation about the types of volumes that are transportable. Therefore, Veritas recommends that you use off-host backup jobs only for backing up data for which all dependent volumes can be imported and exported.

The off-host backup fails if any one volume that you select for backup cannot be imported or exported. The off-host backup also fails if the required VSS hardware provider is not on a Veritas-approved compatibility list. You can choose to continue the backup if the off-host backup fails.

The Hitachi Raid Manager log cannot be on a volume that is being snapped. Hitachi executes I/O to its Raid Manager log file during the snapshot commit process, and the VSS coordinator blocks I/O to any drive being snapped. Therefore, if the log directory for Raid Manager is on the volume that is being snapped, then log I/O is blocked and the snap process is deadlocked.

If the Central Admin Server feature (CAS) is installed, you must manually select the storage for the off-host backup. Otherwise, the job may be delegated to a Backup Exec server that does not have off-host capability.

When you run an off-host backup that uses a VSS hardware provider in a Microsoft Cluster (MSCS) environment, the Backup Exec server and the remote computer must not be in the same cluster group. The cluster applications cannot support the devices' logical unit numbers (LUNs) that have duplicate signatures and partition layouts. The snapshots containing the LUNs must be transported to a host computer that is outside the cluster.