Search <book_title>...

NetBackup™ Deduplication Guide

Last Published: 2022-03-28

Product(s): NetBackup (10.0)

Reverting back to Cloud Catalyst from a failed migration

Recovering the NetBackup master server catalog to revert back to Cloud Catalyst is the safest approach for both successful and a failed migration attempts. However, it may be possible to revert to Cloud Catalyst from a failed migration attempt without recovering the master server catalog.

If the failure occurred and the nbdecommission command exits before displaying the following message, then you may be able to revert back to Cloud Catalyst without recovering the master server catalog. The following message is displayed in the output from the command or the admin log file for the nbdecommission command:

Disk pool <new disk pool name> has been successfully 
created with 1 volumes

Migration failures that occur after the Disk pool message is displayed require recovering the master server catalog to revert to Cloud Catalyst.

If you do not recover the master server catalog, you must manually delete the new disk pool, disk volume, cloud storage server, and the MSDP cloud tier server. You must delete these after reverting back to Cloud Catalyst.

The following procedure assumes that the migration fails before the Disk pool message appears in the output. The procedure also assumes that the Cloud Catalyst server is not reused as the MSDP cloud tier server for migration.

Reverting back to Cloud Catalyst after a failed migration

Stop the NetBackup services on the new MSDP cloud tier server.
On the Cloud Catalyst server, ensure that the esfs.json file has ReadOnly set to 0.
If you only need to do restores and do not intend to run new backup or duplication jobs to Cloud Catalyst, then set ReadOnly to 1.
Start the NetBackup services on the Cloud Catalyst server.
Once the Cloud Catalyst storage server has come online, you can proceed with restores, backups, or optimized duplication jobs.
Backup or optimized duplication jobs require that ReadOnly is set to 0 in the esfs.json file.
If running a Cloud Catalyst version 8.2 or earlier, you may need to deploy a new host name-based certificate for the media server. You can deploy the certificate by running the following command on the master server:
```
/usr/openv/netbackup/bin/admincmd/bpnbaz  - ProvisionCert 
<CloudCatalyst host-name>
```
You must restart the NetBackup services on the Cloud Catalyst server.
You may need to run the following command to allow Cloud Catalyst to read from the bucket in the cloud storage:
```
/usr/openv/esfs/bin/setlsu_ioctl 
<cachedir>/storage/proc/cloud.lsu <bucketname>
```
No harm is done if you run this command when it is not needed. If you do run the command, you can see the following output:
```
return code: -1

File exists.
```
(Optional) Remove the entire MSDP cloud sub-bucket folder in cloud storage to avoid wasted space and avoid any problems with future migration to MSDP cloud tier server.

The following procedure assumes that the migration fails on the Cloud Catalyst server that was reused and or reinstalled as an MSDP cloud tier server.

Reverting back to Cloud Catalyst after a failed migration when the Cloud Catalyst server was reused

Stop the NetBackup services on the new MSDP cloud tier server.
Reinstall the Cloud Catalyst server using the same NetBackup version and EEB bundles that were active when migration was performed.
Then contact Veritas Technical Support to use the rebuild_esfs process to recover that Cloud Catalyst server from the data in cloud storage. (The rebuild_esfs process supersedes the old drcontrol method of recovering a Cloud Catalyst server. The drcontrol method is deprecated.)
(Optional) Remove the entire MSDP cloud sub-bucket folder in cloud storage to avoid wasted space and avoid any problems with future migration to MSDP cloud tier server.