Prerequisites

The following considerations apply to Block backup to the legacy Catalogic Open Storage Server, vStor or the NetApp storage:

• For any volume backed up in a Block backup job, the initial backup is a base backup, and all subsequent backups are incremental, where only changed blocks are transferred.

• An instance of a Block backup (base or incremental) is a virtual image of the entire source volume at a particular point in time.

• Defining a new Block backup job with a new job name directs Catalogic DPX to perform a base backup.

• Some conditions may require a base backup instead of an incremental one. See Forcing a Base Backup.

• A Block backup of a volume that is currently being backed up by an Image backup or a different backup may fail. Ensure you do not run Image and Block backups of the same volume at the same time.

• System State and System Table are supported for Block backups. See Backing Up System State in the DPX 4.9.x Reference Guide.

Note. By default, the Catalogic DPX Block Data Protection System State restore does not restore SPF files because of the time and storage required. For SPF restores, BMR is recommended. If you must restore SPF files without using BMR, contact the Catalogic Software Data Protection Technical Support team.

• For Block backup jobs, the status of a job must be Waiting before you can suspend it.

• After five minutes (300 seconds), if there is no progress on a file backup job, the job will be canceled. This is to prevent file hangups from holding up additional jobs that may be waiting to run.

• If your backup source (primary system) is in a remote location and is to be backed up over a slow link, contact Catalogic Software Data Protection Technical Support for possible alternatives to improve performance.

• In NetApp environments, Catalogic DPX provides two levels of backup instance verification for the Catalogic DPX Block Data Protection. These are described in Verifying a Block Backup by Using iSCSI Mapping in the DPX 4.9.x User’s Guide. Verification procedures for applications are described in Verifying Application Backups in the DPX 4.9.x User’s Guide.

• A failure, such as a system error or communication interruption, that occurs during the Catalogic DPX Block Data Protection processing on a node may cause all the Catalogic DPX Block Data Protection application backups (Oracle, SQL Server, Exchange, Bare Metal Recovery) to fail on that node. If the problem occurs during the preliminary phase of the Catalogic DPX Block Data Protection processing, all backup tasks on the node will fail. If it occurs during backup processing, other backup tasks on the node will generally run successfully. In either case, backups on other nodes are not affected.

The following considerations apply only to Block backup to the NetApp storage:

• The number of concurrent backups is limited by the number of NDMP connections supported by the destination NetApp storage system. Each volume in a backup job requires a connection. Consult the NetApp documentation to determine the maximum connections supported by your NetApp storage system.

• Due to the NetApp storage system limitations, Block backup job names should be kept short. The job name becomes part of the qtree name on the NetApp storage system. If a qtree name is too long, you may be prevented from seeing volumes on the NetApp storage system.

• There is a one-to-one relationship between a backup job and a volume on the NetApp storage system. Each defined backup job must be associated with a destination volume dedicated to that job, even though the job may back up multiple servers. Do not use a single destination volume to store backups from more than one Catalogic DPX backup job. For additional details on best practices related to configuring and using the NetApp volumes and creating the Catalogic DPX backup jobs, see the DPX Best Practices Guide in the Catalogic Knowledge Base.

• When you open a previously saved Block backup job and change either the source or destination, the management console is aware of changes to the job definition and automatically attempts to delete qtrees through the Catalogic DPX condense operation. For additional information, see Considerations When Modifying a Block Backup Job in the DPX 4.9.x User’s Guide and read the knowledge base article 45784.

• DPX 4.4.0 or later is required for Block backup support of Clustered Data ONTAP 8.3.1 RC1 and later.

The following considerations apply only to Block backup to the Catalogic Open Storage Server:

• To run a Block backup to the Catalogic Open Storage Server, storage must be made available to the DPX open storage server as physical or logical volumes. A typical setup provisions storage at one or more Windows drive letters, like D: and E:. Do not use system drives, such as the C: drive, for the Catalogic DPX Open Storage Server.

• Snapshot verification is available for DPX open storage. By running snapshot verification, you can quickly detect snapshot corruption. For more information, read the knowledge base article 46745.

• The Catalogic DPX Archive destinations are optionally selected when the Catalogic DPX Block Data Protection job is scheduled. See Protecting Block Backups in the DPX 4.9.x User’s Guide.

• In DPX open storage environments, occasionally there is the need to transfer data to a different open storage volume or server. For procedural details, read the knowledge base article 46746. The process facilitates the transfer of data on DPX open storage to a different volume or storage server and provides the ability to replace or upgrade the Catalogic DPX Open Storage Server itself.