NetBackup™ for OpenStack Administrator's Guide
- Introduction
- Deploying NetBackup for OpenStack
- Requirements
- NetBackup for OpenStack network considerations
- Existing endpoints in OpenStack
- OpenStack endpoints required by NetBackup for OpenStack
- Recommendation: Provide access to all OpenStack Endpoint types
- Backup target access required by NetBackup for OpenStack
- Example of a typical NetBackup for OpenStack network integration
- Other examples of NetBackup for OpenStack network integrations
- Preparing the installation
- Spinning up the NetBackup for OpenStack VM
- Installing NetBackup for OpenStack Components
- Installing on RHOSP
- 1. Prepare for deployment
- 2] Upload NetBackup for OpenStack puppet module
- 3] Update overcloud roles data file to include NetBackup for OpenStack services
- 4] Prepare NetBackup for OpenStack container images
- 5] Provide environment details in nbos_env.yaml
- 6] Deploy overcloud with NetBackup OpenStack environment
- 7] Verify deployment
- 8] Additional Steps on NetBackup for OpenStack Appliance
- 9] Troubleshooting for overcloud deployment failures
- Installing on Ansible OpenStack Ussuri
- Installing on RHOSP
- Configuring NetBackup for OpenStack
- Post Installation Health-Check
- Uninstalling NetBackup for OpenStack
- Uninstalling from RHOSP
- Clean NetBackup for OpenStack Datamover API service
- Clean NetBackup for OpenStack Datamover Service
- Clean NetBackup for OpenStack haproxy resources
- Clean NetBackup for OpenStack Keystone resources
- Clean NetBackup for OpenStack database resources
- Revert overcloud deploy command
- Revert back to original RHOSP Horizon container
- Destroy the NetBackup for OpenStack VM Cluster
- Uninstalling from Ansible OpenStack
- Uninstall NetBackup for OpenStack Services
- Destroy NetBackup for OpenStack Datamover API container
- Clean openstack_user_config.yml
- Remove NetBackup for OpenStack haproxy settings in user_variables.yml
- Remove NetBackup for OpenStack Datamover API inventory file
- Remove NetBackup for OpenStack Datamover API service endpoints
- Delete NetBackup for OpenStack Datamover API database and user
- Remove nbosdmapi rabbitmq user from rabbitmq container
- Clean haproxy
- Remove certificates from Compute nodes
- Destroy the NetBackup for OpenStack VM Cluster
- 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 snapshots
- List of snapshots
- Creating a snapshot
- Snapshot overview
- Delete snapshots
- Snapshot Cancel
- About restores
- List of Restores
- Restores overview
- Delete a Restore
- Cancel a Restore
- One-Click Restore
- Selective Restore
- In-place restore
- Required restore.json for CLI
- About file search
- Navigating to the file search tab in Horizon
- Configuring and starting a file search in Horizon
- Start the File Search and retrieve the results in Horizon
- Doing a CLI File Search
- About snapshot mount
- Create a File Recovery Manager Instance
- Mounting a snapshot
- Accessing the File Recovery Manager
- Identifying mounted snapshots
- Unmounting a snapshot
- About schedulers
- Disable a schedule
- Enable a schedule
- Modify a schedule
- About email notifications
- Requirements to activate email Notifications
- Activate/Deactivate the email Notifications
- 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
- Scenario
- Prerequisites for the disaster recovery process
- Disaster recovery of a single policy
- Copy the policy directories to the configured NFS Volume
- Make the Mount-Paths available
- Reassign the policy
- Add admin-user to required domains and projects
- Discover orphaned policies from NFS-Storage of Target Cloud
- List available projects on Target Cloud in the Target Domain
- List available users on the Target Cloud in the Target Project that have the right backup trustee role
- Reassign the policy to the target project
- Verify that the policy is available at the desired target_project
- 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
- Add admin-user to required domains and projects
- Discover orphaned policies from NFS-Storage of Target Cloud
- List available projects on Target Cloud in the Target Domain
- List available users on the Target Cloud in the Target Project that have the right backup trustee role
- Reassign the policy to the target project
- Verify that the policy is available at the desired target_project
- Restore the policy
- Reconfigure the Target NetBackup for OpenStack installation back to the original one
- Clean up
- Troubleshooting
- General Troubleshooting Tips
- Using the nbosjm CLI tool on the NetBackup for OpenStack Appliance
- Health check of NetBackup for OpenStack
- Important log files
- Troubleshooting NBOSDM container in offline state due to unavailable mount point
- About permission denied error when same NFS share path is used across multiple OpenStack distributions
- Index
Reassigning policies
OpenStack administrators are able to reassign a policy to a new owner. This involves the possibility to migrate a policy from one cloud to another or between projects.
Warning:
Reassigning a policy only changes the database of the target NetBackup for OpenStack installation. Now that it is managed by a different NetBackup installation, the original source installation is not updated.
Use the following CLI command to reassign a policy:
nbosjm policy-reassign-policies
[--old_tenant_ids <old_tenant_id>]
[--new_tenant_id <new_tenant_id>]
[--policy-ids <policy-id>]
[--user_id <user_id>]
[--migrate_cloud {True,False}]
[--map_file <map_file>]
--old_tenant_ids <old_tenant_id> Specify old tenant ids from which policies need to reassign to new tenant. Specify multiple times to choose policies from multiple tenants.
--new_tenant_id <new_tenant_id> Specify new tenant id to which policies need to reassign from old tenant. Only one target tenant can be specified.
--policy-ids <policy-id> Specify policy ids which need to reassign to new tenant. If not provided then all the policies from old tenant will get reassigned to new tenant. Specifiy multiple times for multiple policies.
--user_id <user_id> Specify user id to which policies need to reassign from old tenant. only one target user can be specified.
--migrate_cloud {True,False} Set to True if you want to reassign policies from other clouds as well. Default if False
--map_file Provide file path(relative or absolute) including file name of reassign map file. Provide list of old policies mapped to new tenants. Format for this file is YAML.
A sample mapping file with explanations is shown below:
reassign_mappings:
- old_tenant_ids: [] #user can provide list of old_tenant_ids or
policy-ids
new_tenant_id: new_tenant_id
user_id: user_id
policy-ids: [] #user can provide list of old_tenant_ids or policy-ids
migrate_cloud: True/False #Set to True if want to reassign policies from
# other clouds as well. Default is False
- old_tenant_ids: [] #user can provide list of old_tenant_ids or
policy-ids
new_tenant_id: new_tenant_id
user_id: user_id
policy-ids: [] #user can provide list of old_tenant_ids or policy-ids
migrate_cloud: True/False #Set to True if want to reassign policies from
# other clouds as well. Default is False