Copy of CommServe® Availability

High availability for the CommServe^® server is essential to allow normal CommCell^® operations to run. If the CommServe server goes offline, data protection and recovery jobs are affected.

This is especially important when considering the following key points:

• Meeting backup windows – During data protection jobs, if the CommServe server is not reachable, the client continues backing up data to a MediaAgent by default for 20 minutes. The 'Network Retries' determines the maximum time interval and number of attempts to contact the CommServe system. The default is 40 retries at 30 second intervals.
• Restores – The CommServe server must be available to browse and recover data within a CommCell environment.
• Deduplication database consistency – In the event of a CommServe failure, all Deduplication Databases (DDBs) within a CommCell environment will be in an inconsistent state. When the CommServe metadata is restored, all DDBs must be brought back to a consistent state. This process brings the DDBs to a state as they existed based on the point-in-time of the CommServe database restore point. This could result in losing some backup data if the backups completed after the most recent CommServe DR backup.
• Archive stub recalls – When using Commvault archiving, stub recalls require the CommServe server to be present. The HSM recall service redirects all item retrieval requests to the CommServe server which then locates which MediaAgent and media contains the data.

CommServe^® server availability overview

Hot / Cold Standby

A hot or cold standby CommServe^® server consists of a physical or virtual machine with the CommServe software pre-installed. The DR backup Export process directs metadata exports to the standby CommServe server. In the event that the production CommServe server is not available, the standby CommServe server can quickly be brought online.

When using a hot / cold standby CommServe server consider the following key points:

• It is critical that both the production and standby CommServe servers have the same Feature Release and Maintenance Release installed. After applying updates to the production CommServe server, ensure the same updates are applied to the standby CommServe server.
• Multiple standby CommServe servers can be used. For example, an on-site standby and an off-site DR CommServe server. Use post script processes to copy the raw DR Metadata to additional CommServe servers.
• A standby CommServe server can be a multi-function system. The most common multi-function system would be installing the CommServe software on a MediaAgent.
• If a virtual environment is present, consider using a virtual standby CommServe server. This avoids problems associated with multi-function standby CommServe servers and eliminates the need to invest in additional hardware. Ensure the virtual environment is properly scaled to handle the extra load that may result when activating the virtual standby CommServe server.

Virtualization

Some customers with virtual environments are choosing to virtualize the production CommServe server. A virtualized CommServe server has an advantage of using the hypervisors high availability functionality (when multiple hypervisors are configured in a cluster) which reduces costs since separate CommServe hardware is not required. Although this method could be beneficial, it should be properly planned and implemented.

If the virtual environment is not properly scaled, the CommServe server could become a bottleneck when conducting data protection jobs. In larger environments where jobs run throughout the business day, the CommServe server activity may have a negative performance impact on production servers.

When virtualizing the CommServe server, it is still critical to run the CommServe DR backup. In the event of a disaster, the CommServe server may still have to be reconstructed on a physical server. Do not rely on the availability of a virtual environment in the case of a disaster. Follow normal Commvault software best practices in protecting the CommServe metadata.

Clustering

The CommServe^® server can be deployed in a clustered configuration. This provides high availability for environments where CommCell operations run 24/7. Clustering the CommServe server is a good solution in large environments where performance and availability are critical.

Note that a clustered CommServe server is not a DR solution, therefore a standby CommServe server must be planned for at a DR site.

Another benefit for using a clustered CommServe server is when using Commvault OnePass^® archiving. Archiving operations are configured to create stub files which allow end users to initiate recall operations. For the end user recall to complete successfully the CommServe server must be available. Having the CommServe server clustered ensures that recalls can be accomplished.

CommServe Failover

CommServe failover provides methods for log shipping CommServe database data to a pre-configured standby CommServe server.

For more information, refer to the Commvault Online Documentation sections, 'Setup a Standby CommServe Host for Failover' and 'Testing Disaster Readiness'.