DiskDirectory for Catalog backup

DiskDirectory (tape backup to disk) can be used for Catalog backup.

Attention! Ensure the DiskDirectory volumes are protected so that if the master server is lost, the desired DiskDirectory volser files can be copied to the new master server for master server recovery.

Note the following considerations when using DiskDirectory for Catalog backup:

• DiskDirectory volsers only contain a single partition, do not have any specific bounds that limit space usage, and disk space used is not reclaimed at Condense time, though the volser is Empty and flagged for re-use for new data.

• DiskDirectory volser storage can easily grow to consume all available volume space, so it is important to make sure that running out or DiskDirectory space does not affect other unrelated server functions.

• It is very important to host DiskDirectory volsers on a volume that does not compete for disk space with other local machine needs. For example, do not host DiskDirectory storage on the volume that contains the master server software or Catalog, and do not host DiskDirectory volsers on any volumes shared with application data such as SQL Server, Oracle, or Exchange.

• If DiskDirectory volsers are hosted on the Catalogic DPX Open Storage Server, use a separate volume and do not attempt to share storage between DiskDirectory and the Catalogic DPX Open Storage Server backups, since the two types of backup use disk space in different ways and ultimately interfere with one another.

• DiskDirectory backup can be hosted on either the master server, or a remote device server, if necessary.

• The data protection administrator must arrange for DiskDirectory volsers to be copied, moved, or otherwise archived to a safe location where they can be accessed in the event of a disaster recovery. Long-term archival of catalog data by a secondary process such as NDMP is not a valid strategy because NDMP restore requires catalog data to find and direct the restore process.

• When using DiskDirectory, it is recommended to set the Job Destination Options Tape EOJ Usage to Unload Tapes. This allows any empty volsers to be used even if new volsers exist. Otherwise, new volsers are always preferred until no new volsers are remaining. With DiskDirectory, it is a good practice to use the first tapes marked Empty. This helps reclaim disk space held by the expired backup data.

The following are common methods for Catalog backup to DiskDirectory:

Back up to local storage protected with Block backup

In this method, the master server performs Catalog backup to local storage and then uses Block backup for protection. Perform a Block backup to an offsite NetApp storage system. Alternatively, use SnapMirror to replicate a Block backup to another NetApp storage system.

For recovery, restore the entire master server with BMR, then restore the Catalog from the local DiskDirectory repository. If a BMR backup of the master server is not included or available, then you can manually manipulate the Block backup data to present the DiskDirectory data via an iSCSI LUN to the new master server and perform the restore.

Connect a NetApp LUN and use SnapMirror

In this method, a NetApp LUN is connected to the master server, and the LUN is used to hold Catalog backup DiskDirectory volsers. SnapMirror is configured to replicate this LUN to another offsite NetApp storage system after the Catalog backup is completed.

For recovery, the backup administrator must know where the Catalog backup LUN exists and must arrange for it to be mounted to the new master server. Once the LUN is presented and the data is visible, the administrator needs to know which volser to use for Catalog restore. Typically this is the volser with the most recent modification date.

Connect a CIFS/NFS share and replicate offsite

Another server is used to present a CIFS or NFS share to the master server. This share is used to hold the Catalog backup DiskDirectory volsers. This share could be a NetApp storage system or any other suitable storage server. The storage server replicates the DiskDirectory volsers offsite. For NetApp storage systems, you can use Snapmirror or SnapVault. You can also use a server with the NetApp OSSV agent to perform Snapvault backups to NetApp storage. Additionally, you can run automated jobs on a Windows or Linux machine to copy new data to an alternate location.

For recovery, you need to know the location of volser files, and you need to arrange for the required volser files to be copied back to the new master server for Catalog restore. If you use a network share for DiskDirectory storage and you need to run a tape backup of this as well, ensure you set the source job option Skip NFS Volumes to No.

Backup on local storage and then to tape

In this method, you run Catalog backup to DiskDirectory hosted on the master or a remote device server and then use tape backup to archive this data offsite. This method retains a local copy for convenience and a remote copy for disaster recovery. It is essential to know where the tapes and partitions for the second stage backup are located. To ensure you have this information, save e-mail job reports or archive the job logs. Archive job logs on a long-term basis, as they may be needed at recovery time for reference.

For recovery, the backup administrator must configure the new master server to run a tape mode restore from the second stage backup. The information for the required tapes and partitions must be recovered from the previous backup job log. Once the necessary volser is recovered, you can then run a Catalog restore from DiskDirectory.