Disaster recovery for universal shares on migrated cloud LSU
The following procedure should be performed after the regular MSDP cloud LSU consolidation.
These universal share disaster recovery steps are supported in BYO, AKS, and EKS environments. For BYO deployments, ensure all prerequisites are met before proceeding with the steps below. See Prerequisites to configure universal shares.
The data from universal shares can only be recovered if at least one point-in-time (PIT) image exists for each share. If no PIT image is available, only the configurations are recoverable. No actual data will be present on the recovered shares.
To verify if the PIT image exists, run the following command:/usr/openv/pdde/vpfs/bin/vpfscld --list
Note:
The migration steps do not retain the original share quota settings. You must manually reset the quotas to their original values after a successful migration.
To recover universal shares on migrated cloud LSU
- Recover universal share configurations.
/usr/openv/pdde/vpfs/bin/vpfscld --migrated_cloud_lsu --lsu <lsu name> --old_sts <old storage server name>
Ensure that there are no duplicate share names between the source and target storage servers to avoid errors. If duplicates exist, back up shares on both servers and delete duplicates from either the source or target.
- Recover NFS share configurations if previously configured on the old storage server:
/usr/openv/pdde/vpfs/bin/vpfscld --migrated_cloud_lsu --download_export_list --share_type nfs --lsu <lsu name> --old_sts <old storage server name>
- Recover SMB share configurations if previously configured on the old storage server:
/usr/openv/pdde/vpfs/bin/vpfscld --migrated_cloud_lsu --download_export_list --share_type smb --lsu <lsu name> --old_sts <old storage server name>
Ensure that SMB users are configured on the target storage server, and their credentials match those on the source storage server.
For more information on authentication setup, See Configuring universal share user authentication.
- Restore data to the shares and recover the metadata:
/usr/openv/pdde/vpfs/bin/vpfs_actions -a disasterRecovery --cloudVolume CLOUDVOLUMENAME --migratedCloudLsu --oldSts <oldSts>
CLOUDVOLUMENAME: Name of the MSDP cloud volume containing the shares you want to restore. If restoring shares from multiple cloud volumes, run this command separately for each volume.
oldSts: The name of the old storage server from which the cloud LSU was migrated.
Note:
(Cloud Scale only) Run the following command to ensure that OCSD process can download and write configuration files to the target MSDP Kubernetes pod disk volume. This is necessary because MSDP processes run as a non-root user:
chown -R msdpsvc:pduser /msdp/data/dp1/pdvol/meta_dir/
After completing the disaster recovery steps, clients may encounter "permission denied" errors when accessing the content of SMB universal shares. One possible reason is a mismatch in the UID/GUID of the owner user between the source and target storage servers. To resolve this, ensure that ownership and permissions of the universal share content are correctly set on the target storage server.
For example, On the MSDP server, verify that the universal share smb1-test has the correct owner (smb_user) and appropriate permissions.
Change the permission: chmod -R 755 /mnt/vpfs_shares/Ia-s/smb1-test
Change the owner: chown -R smb_user:smb_user /mnt/vpfs_shares/Ia-s/smb1-test
- Restart the NetBackup services:
/usr/openv/netbackup/bin/bp.kill_all
/usr/openv/netbackup/bin/bp.start_all
- Clean up the existing universal shares that are associated with the migrated cloud LSU on the old storage server.
- On the client, unmount the old mount points and re-mount using the new export paths.