NetBackup™ for OpenStack Administrator's Guide
- Introduction
- Deploying NetBackup for OpenStack
- Requirements
- NetBackup for OpenStack network considerations
- Preparing the installation
- Spinning up the NetBackup for OpenStack VM
- Installing NetBackup for OpenStack Components
- Installing on RHOSP
- Prepare for deployment
- Updating the overcloud roles data file to include NetBackup for OpenStack services
- Verifying the deployment
- Additional Steps on NetBackup for OpenStack Appliance
- Installing on Ansible OpenStack Ussuri
- Installing on Kolla Ussuri
- Pushing NetBackup for OpenStack images to the local registry
- Installing on RHOSP
- Configuring NetBackup for OpenStack
- Post Installation Health-Check
- Uninstalling NetBackup for OpenStack
- Uninstalling from RHOSP
- Uninstalling from Ansible OpenStack
- Uninstalling from Kolla Openstack
- Uninstalling from RHOSP
- Install nbosjm CLI client
- Configuring NetBackup OpenStack Appliance
- Configuring NetBackup Master Server
- NetBackup for OpenStack policies
- Performing backups and restores of OpenStack
- About restores
- Required restore.json for CLI
- Configuring and starting a file search in Horizon
- Performing Backup Administration tasks
- NBOS Backup Admin Area
- Policy Attributes
- Policy Quotas
- Managing Trusts
- Policy import and migration
- Disaster Recovery
- Example runbook for disaster recovery using NFS
- Disaster recovery of a single policy
- Copy the policy directories to the configured NFS Volume
- Make the Mount-Paths available
- Reassign the policy
- Restore the policy
- Clean up
- Disaster recovery of a complete cloud
- Reconfigure the Target NetBackup for OpenStack installation
- Make the Mount-Paths available
- Reassign the policy
- Restore the policy
- Reconfigure the Target NetBackup for OpenStack installation back to the original one
- Clean up
- Troubleshooting
- General Troubleshooting Tips
- Health check of NetBackup for OpenStack
- Important log files
Mount-paths
NetBackup for OpenStack incremental Snapshots involve a backing file to the prior backup taken, which makes every NetBackup for OpenStack incremental backup a synthetic full backup.
NetBackup for OpenStack is using qcow2 backing files for this feature:
qemu-img info 85b645c5-c1ea-4628-b5d8-1faea0e9d549 image: 85b645c5-c1ea-4628-b5d8-1faea0e9d549 file format: qcow2 virtual size: 1.0G (1073741824 bytes) disk size: 21M cluster_size: 65536 backing file: /var/NetBackupOpenStack-mounts/MTAuMTAuMi4yMDovdXBzdHJlYW0= /policy_3c2fbee5-ad90-4448-b009-5047bcffc2ea/snapshot_f4874ed7-fe85- 4d7d-b22b-082a2e068010/vm_id_9894f013-77dd-4514-8e65-818f4ae91d1f/ vm_res_id_9ae3a6e7-dffe-4424-badc-bc4de1a18b40_vda/a6289269-3e72-4085- adca-e228ba656984 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false
As can be seen in the example, the backing file is an absolute path, which makes it necessary, that this path exists so the backing files can be accessed.
NetBackup for OpenStack is using the base64 hashing algorithm for the NFS mount-paths, to allow the configuration of multiple NFS Volumes at the same time. The hash value is calculated using the provided NFS path.
# echo -n 10.10.2.20:/upstream | base64 MTAuMTAuMi4yMDovdXBzdHJlYW0=
If the path of the backing file is not available on the NetBackup for OpenStack VM and Compute nodes, the restores of incremental backups fails.
The tested and recommended method to make the backing files available is creating the required directory path and using mount --bind to make the path available for the backups.
#mount --bind <mount-path1> <mount-path2>
Running the mount - bind command will make the necessary path available until the next reboot. If it is required to have access to the path beyond a reboot, it is necessary to edit the fstab.
#vi /etc/fstab <mount-path1> <mount-path2> none bind 0 0