Performing Test Failovers to an Isolated or Bubble Networks

You can perform a test failover to a standby CommServe host that is located in an isolated network that has no connectivity to the production environment.

Before You Begin

  • Set up the standby CommServe host in a way that the network can be isolated, during the test failover. The network must be set up in a way that connections to the production environment—which includes the CommServe host, production MediaAgents and production clients, and all passive CS nodes—can be disconnected during a test failover and reconnected after the test failover is complete.

  • To test restores, do the following:

    • For disk storage and cloud storage, set up a read-only MediaAgent in the standby CommServe host and share the library with the MediaAgent as read-only. For information about how to create a read-only MediaAgent, see Configuring a Replica Library.

    • For HyperScale storage, set up a read-only MediaAgent in the production CommServe host, share the library with the MediaAgent as read-only using DataServer-IP, and then disable the MediaAgent.

    • For tape storage, do the following:

      • Set up a read-only MediaAgent in the standby CommServe host.

      • Configure a separate tape library in the standby CommServe host or partition an existing tape library.

      • Connect the library to the standby CommServe host using the read-only MediaAgent.

      • Export required tapes from the production CommServe host, and then import the tapes to the library in standby CommServe host.

    To test the environment, you might also have to clone some clients or install new clients as test clients in the isolated environment.

  • To disable all other activities in the standby CommServe host, create the keepActivityDisabledPostFailover additional setting. For more information, see Disabling Activities and Schedules After a Planned Failover.

Performing Test Failovers

  1. From the production CommServe hosts, shut down the services associated with the SQL client (or Instance002). If an environment has multiple passive CS nodes, stop the services associated with the SQL client (or Instance002) on all passive nodes as well.

  2. Disconnect and confirm that the standby CommServe host used for testing has no connectivity to production environment, including production CS and all passive CS nodes.

  3. If you use a floating CommServe name, update the DNS server in the standby site to resolve the Commserve DNS name to the standby CommServe host. For more information, see Setting Up Failovers Using a Floating CommServe Name.

  4. From the standby CommServe host, perform an unplanned failover using the Process Manager that is associated with the SQL client (or Instance002). For more information, see Unplanned Failovers.

  5. For a HyperScale environment, do the following:

    1. Set the value as true for the additional settingbEnableDRTesting on the standby CommServe host.

    2. Enable the read-only MediaAgent.

  6. If necessary, perform restore operations using the read-only MediaAgent.

Resetting Test Failovers

  1. From the standby Commserve host, shut down the services associated with the both the CommServe server and the SQL instance.

  2. Delete the following file in the standby CommServe host:

    ContentStore2\iDataAgent\JobResults\CommServeFailover.xml

  3. Change the value of the following key from the registry to 0 on the passive node:

    Computer\HKEY_LOCAL_MACHINE\SOFTWARE\CommVault Systems\Galaxy\Instance002\Base\nCSFailoverLastFailoverTime or /etc/CommVaultRegistry/Galaxy/Instance002/Base/.properties/nCSFailoverLastFailoverTime

  4. If you use a floating CommServe name, remove the DNS record in the standby site that was updated to resolve the Commserve DNS name to standby CommServe host.

  5. Reconnect the standby Commserve network to the production CommServe host.

  6. From the production CommServe host, start the services associated with the SQL client (or Instance002). If an environment has multiple passive CS nodes, start the services associated with the SQL client (or Instance002) on all passive CS nodes.

  7. From the standby CommServe, verify that the services associated with the SQL client (or Instance002) are started.

Loading...