General Considerations
Last updated
Last updated
It is very important to back up the Catalog regularly. It is equally important to know where the Catalog backup resides. Specifically, you need to know the destination media volume and the location of the Catalog backup on the media. However, the location of the backup Catalog is kept in the Catalog itself; thus, if the Catalog is lost, the location information is lost as well.
To be prepared for a disaster recovery situation where the Catalog is lost, you need to take the following critically important steps:
Define a Catalog backup job and schedule it to run daily.
Enable e-mail reporting in the Catalog backup job definition. Emailing the Catalog backup job report and archiving that report off-site will help identify tapes and partitions needed for Catalog restore.
Also, note the following important recommendations:
Set Catalog backup retention to be as long as your longest data protection archives. For example, if you are required to retain server backups for 5 years on tape media, retain Catalog backups for at least that long. If you cannot retain all Catalog backups for this long, consider defining multiple backup schedules in the Schedule Job dialog to retain some archives long-term.
Create a separate media pool for Catalog backup media. This step is not essential, but it is strongly recommended. It can help you locate media quickly.
Retain an offsite copy of your Catalogic DPX installation media. The installation media can always be downloaded from your MySupport account; however, ready access to the media and patch sets helps to speed the recovery process and avoid challenges with Internet connectivity during a disaster recovery situation.
The destination media can be tape or Disk Directory. You can also employ BMR as part of the protection strategy. BMR provides high-performance bare metal disaster recovery capability. You must still perform catalog backups, however BMR can assist in recovering the server quickly. See Bare Metal Recovery (BMR) Backup.
Important. Backing up to a local disk does not protect your data if the disk fails.
See also. For the latest system compatibility details regarding supported hardware, file systems, applications, operating systems, and service packs, see the .
There are several different strategies for protecting catalog data. The most important items are to back up the catalog frequently, move the catalog backup data to a safe location, keep record of where the catalog data is, and retain the catalog backup to cover the retention period of your longest archives.
The recommended strategies for catalog backup are as follows:
Tape drive attached to the master server
Tape drive attached to a remote device server
DiskDirectory dedicated for Catalog backup
Directly attach at least one tape drive to the master server. Back up the Catalog directly to a tape and send this tape offsite. Retain the catalog backup job log with this Catalog backup media.
It is strongly recommended to use a separate media pool dedicated to Catalog backup operations and to retain Catalog backup job reports, which should be emailed or copied to a location where they can be easily accessed. These steps facilitate finding and recovering the master server data in the event of a disaster.
If you do not follow the recommendation to use a dedicated media pool and decide to mix Catalog backups with other file-level backups, be aware that backup retentions could prevent tapes from being free if the Catalog backup is retained on a long retention cycle. If you nevertheless decide to mix backups on media, it is recommended to use a new tape for each Catalog backup. This is done by setting the Tape Usage option to Use a new Tape. Setting the option ensures that the Catalog backup is always on the first tape partition, making it much easier to locate and restore from the tape when no other data is available. Ensure you retain a record of the Catalog backup and send media offsite.
This is similar to a tape drive attached to the master server. If the device server is located at the same site as the master server, ensure the Catalog backups are sent offsite. If you have a device server at a remote location, you can accomplish the Catalog backup and offsite storage simultaneously. Always retain the Catalog backup job logs, especially if the offsite Catalog backup media mix with other tape backups or if the media pool reuses Catalog backup media for multiple catalog backups.
The Catalogic DPX Open Storage Server environments typically have a tape library attached to the Catalogic DPX Open Storage Server for the Catalogic DPX Archive capability. The Catalogic DPX Open Storage Server is a device server like any other and can handle Catalog backups to tape.
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 either on the master server, or on 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.
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. For more details, See Catalog Restore.
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.
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.
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.
The following are Catalog backup strategies that are not recommended. Although Catalog backup in some of these cases may succeed, the recovery may not be possible if the master server is not available to coordinate the restore process.
The Catalog cannot be backed up directly to an NDMP-attached tape drive. In cases where a tape drive cannot be attached to the Catalogic DPX device server, ensure you know where the catalog backup is retained and how to recover it. Do not move Catalog backups to NDMP attached storage. NDMP restore requires Catalog data on the master server. You cannot recover NDMP data unless the master server has the NDMP tape backup in its Catalog. Thus, in a disaster where the primary catalog backup media (DiskDirectory) is lost, the archive via NDMP will not help, since you will have no way to directly recover that data without the master server Catalog.
Block backup can be used to protect the master server, but that does not guarantee that the Catalog is in a consistent state. You must perform a separate Catalog backup. See Back up to Local Storage Protected with Block Backup above.
Consumer-grade removable USB storage is not an ideal medium for DiskDirectory management. Backups may succeed, but they would require very careful administration, and you would need to maintain a detailed accounting of backups and devices. Volser file names will likely be duplicated across multiple devices, adding to restore time confusion.
Agent-based and agentless virtualization generally requires a master server with a viable Catalog to run the restore. For disaster recovery testing, other testing, or temporary needs requiring older Catalog data, you can virtualize a master server if that is followed with the desired Catalog restore. However, note that you generally cannot perform virtualization to the original IP address. This limitation may cause local cmagent configuration issues, and the virtualization will likely invalidate the licensing. For real disaster recovery scenarios, BMR followed by a Catalog restore is preferred.