Use Case: Disaster Recovery Resync Scenario

SystemA is taken down for a period of time (possibly for maintenance), and SystemB is configured as the new DSU.

Considerations

The administrator performs the steps outlined in the disaster recovery failover scenario, to enable SystemB as the new temporary DSU. At some later time, SystemA is back online and you want to use it again as the DSU. All data backed up to SystemB while SystemA was unavailable must now be transferred back to SystemA before re-enabling SystemA as the DSU. The following use case is based on this representative environment:

Two media servers, (that is, mediaserver1 and mediaserver2), that back up to volumes on a NearStore storage system (that is, SystemA).
SystemA contains volumes that are replicated using SnapMirror to another NearStore storage system (that is, SystemB).

To transfer back the data from SystemB to SystemA, and use it as the DSU for NetBackup, complete the following steps:

Steps

Resync the volumes from SystemB to SystemA. SystemA> snapmirror resync -S SystemB:volume1 volume1SystemA> snapmirror resync -S SystemB:volume2 volume2
Run the snapmirror release commands for both volumes on SystemA, as SystemA is no longer the replica source. SystemA> snapmirror release volume1 SystemB:volume1SystemA> snapmirror release volume2 SystemB:volume2
Delete the base Snapshot copies on SystemB (that were originally used by SnapMirror to transfer data from SystemA to SystemB) because these Snapshot copies are not required. For more information, follow Step #4 of the Disaster Recovery Failover Scenario use case.
To confirm that relationships are intact, run the following command for both volumes of SystemA: SystemA> snapmirror update -S SystemB:volume1 volume1SystemA> snapmirror update -S SystemB:volume2 volume2
Break the replicated relationship on SystemA.SystemA> snapmirror break volume1SystemA> snapmirror break volume2

Resync the volumes from SystemA to SystemB. SystemB> snapmirror resync -S SystemA:volume1 volume1SystemB> snapmirror resync -S SystemA:volume2 volume2

This operation might display a message similar to the following, and fail the resync operation:

The resync base snapshot will be: SystemA(0101179629)_volume1.4
These older snapshots have already been deleted from the source and will be deleted from the destination:
    SystemB(0101178726)_volume1.20699
    SystemB(0101178726)_volume1.20698
Are you sure you want to resync the volume? y
Wed Sep 27 12:30:24 PDT [SnapMirror.dst.resync.success:notice]: SnapMirror resync of volume1 to SystemA:volume1 successful.
Transfer started.
Monitor progress with 'snapmirror status' or the SnapMirror log.
SystemB> Wed Sep 27 12:30:26 PDT [SnapMirror.dst.snapDelErr:error]: Snapshot SystemB(0101178726)_volume1.20699 in destination volume volume1 is in use, cannot delete.
Wed Sep 27 12:30:27 PDT [SnapMirror.dst.err:error]: SnapMirror destination transfer from SystemA:volume1 to volume1 : 
SnapMirror transfer failed to complete.

If such a case occurs, complete the following steps to resolve this issue:

The SnapMirror resync operation would have replicated the volume. Therefore, issue a snapmirror break command to break the replica.SystemB> snapmirror break volume1
Manually delete the appropriate Snapshot copy.SystemB> snap delete volume1 SystemB(0101178726)_volume1.20699
Retry the resync operation.

You many need to repeat these steps a few times till no problems occur with the resync operation because of Snapshot copies.

Repeat steps 2-4, on SystemB.

Remove the NEARSTORE_FAILOVER_SERVER entries from the bp.conf file (or registry keys on Windows) that were added during the failover setup (remove what was added in step 2 of the Disaster Recovery Failover use case). After removing those entries, redirect the path from SystemB to SystemA. This new path ensures proper access to backups that were made on SystemB when SystemA was unavailable. The final configuration for each media server is as follows:

On media server...	The following is the content of the bp.conf entry (on UNIX)/registry key (on Windows)...
mediaserver1	NEARSTORE_FAILOVER_SERVER = SystemB:/vol/volume1 SystemA:/vol/volume1
mediaserver2	NEARSTORE_FAILOVER_SERVER = SystemB:/vol/volume2 SystemA:/vol/volume2

Mediaserver1

If mediaserver1 is a UNIX server, remove the bp.conf entry that was added in step 2 of the Disaster Recovery Failover use case, and then add the following new NEARSTORE_FAILOVER_SERVER entry to the /usr/openv/netbackup/bp.conf file: NEARSTORE_FAILOVER_SERVER = SystemB:/vol/volume1 SystemA:/vol/volume1
If mediaserver1 is a Windows server, remove the registry key that is added in step 2 of the Disaster Recovery Failover use case, and then add a registry key at this location: KEY_LOCAL_MACHINE\SOFTWARE\VERITAS\NetBackup\ConcurrentVersion\Config. It should be named NEARSTORE_FAILOVER_SERVER and be of type multi-string value. The value should be: SystemB:/vol/volume1 SystemA:/vol/volume1 For exact location of the registry key for Windows, see the NetBackup Administrators Guide.

Mediaserver2

If mediaserver2 is a UNIX server, remove the bp.conf entry added in step 2 of the Disaster Recovery Failover use case, and then add the following new NEARSTORE_FAILOVER_SERVER entry to the /usr/openv/netbackup/bp.conf file: NEARSTORE_FAILOVER_SERVER = SystemB:/vol/volume2 SystemA:/vol/volume2
If mediaserver2 is a Windows server, remove the registry key that was added in step 2 of the Disaster Recovery Failover use case, and then add a registry key: The new key should be located in: KEY_LOCAL_MACHINE\SOFTWARE\VERITAS\NetBackup\ConcurrentVersion\Config. It should be named NEARSTORE_FAILOVER_SERVER and be of type multi-string value. The value should be: SystemB:/vol/volume2 SystemA:/vol/volume2

Reconfigure the storage units that were originally configured to the volumes on SystemB, to point to the storage units on SystemA, using the following command:/usr/openv/netbackup/bin/admincmd/bpsturep -label storage unit label -nh SystemA

Parent topic: Use cases of the commands used in the failover process