Restore OpenStack from a Backup¶
You can restore StarlingX OpenStack from a backup.
Prerequisites
You must have a backup of your StarlingX OpenStack installation as described in Back up OpenStack.
You must have an operational StarlingX deployment.
Procedure
Delete the old OpenStack application and upload it again.
Note
Images and volumes will remain in Ceph.
Note
To remove the OpenStack application, first you need to remove all OpenStack resources (including VMs) and then remove the OpenStack.
If the application fails to re-apply due to VMs orphaned from the previous remove, check Uninstall OpenStack for more details.
~(keystone_admin)$ system application-remove stx-openstack ~(keystone_admin)$ system application-delete stx-openstack ~(keystone_admin)$ system application-upload stx-openstack.tgz
Restore StarlingX OpenStack.
You can choose either of the following options:
Restore a Distributed Cloud subcloud platform and StarlingX OpenStack. This option is applicable only to Distributed Cloud deployments. It restores the subcloud platform and prepares StarlingX OpenStack data by using DCManager from the Centralized Cloud. After the platform restore completes, you must finish the StarlingX OpenStack application restoration on the subcloud using the standard StarlingX OpenStack restore procedure. For more information, see Restore Distributed Cloud Subcloud.
Restore only StarlingX OpenStack system data. This option will not restore the Ceph data (that is, it will not run commands like rbd import). This procedure will preserve any existing Ceph data at restore-time. For more information, see Restore only application system data.
Restore StarlingX OpenStack system data, Cinder volumes and Glance images. You’ll want to run this step if your Ceph data will be wiped after the backup. For more information, see Restore application system data, cinder volumes and glance images.
Restore Distributed Cloud Subcloud¶
This section describes how to restore a Distributed Cloud subcloud using backup files generated by the DCManager backup procedure.
Restore a DC Subcloud Platform and StarlingX OpenStack¶
Use this procedure to restore the subcloud platform and partially restore the StarlingX OpenStack application in a Distributed Cloud deployment. Initiate the restore from the Centralized Cloud using DCManager.
Use the following procedure to restore the subcloud platform and prepares StarlingX OpenStack data. After the platform restore completes, you must finish restoring the StarlingX OpenStack application directly on the subcloud by using the standard StarlingX OpenStack restore steps.
Procedure
Create a restore override file required for StarlingX OpenStack:
cat << EOF > <subcloud>-restore.yaml restore_extra_items: - "etc/dcdbsync/dcdbsync_openstack.conf" EOF
Run the DCManager restore command using the local backup files:
dcmanager subcloud-backup restore \ --local-only \ --subcloud <subcloud> \ --sysadmin-password <sysadmin-password> \ --restore-values <subcloud>-restore.yaml
This command restores the subcloud platform and partially restores the StarlingX OpenStack application.
After the restore completes, access the subcloud and complete the StarlingX OpenStack application restoration.
Remove, delete, and upload the StarlingX OpenStack application tarball:
system application-remove |prefix|-openstack system application-delete |prefix|-openstack system application-upload |prefix|-openstack
Run the restore playbook to completely restore the StarlingX OpenStack application:
ansible-playbook /usr/share/ansible/stx-ansible/playbooks/restore_openstack.yml \ -e 'initial_backup_dir=/opt/platform-backup/backups/<release>/ \ ansible_become_pass=<password> \ admin_password=<password> \ backup_filename=<backup_file_name.tgz> \ openstack_app_name=|prefix|-openstack'
Restore Only StarlingX OpenStack on a DC Subcloud¶
Use this procedure to restore only the StarlingX OpenStack application on a DC subcloud. This restore method is identical to the procedure used for isolated (non-Distributed Cloud) systems.
Procedure
Remove, delete, and upload the StarlingX OpenStack application tarball:
system application-remove |prefix|-openstack system application-delete |prefix|-openstack system application-upload |prefix|-openstack
Run the restore playbook to complete the StarlingX OpenStack restoration:
ansible-playbook /usr/share/ansible/stx-ansible/playbooks/restore_openstack.yml \ -e 'initial_backup_dir=/opt/platform-backup/backups/<release>/ \ ansible_become_pass: "<password>" \ admin_password: "<password>"" \ backup_filename: "<backup_file_name.tgz>" \ openstack_app_name: "|prefix|-openstack"
Restore only application system data¶
Run the following command:
~(keystone_admin)$ ansible-playbook /usr/share/ansible/stx-ansible/playbooks/ restore_openstack.yml -e "@localhost-restore.yaml"
cat << EOF > localhost-restore.yaml
---
ansible_become_pass: "<admin_password>"
admin_password: "<admin_password>"
initial_backup_dir: "<location_of_backup_filename>"
backup_filename: "<openstack_tgz_backup_filename>"
Restore application system data, cinder volumes and glance images¶
Run the following command:
~(keystone_admin)$ ansible-playbook /usr/share/ansible/stx-ansible/playbooks/ restore_openstack.yml -e "@localhost-restore.yaml"
cat << EOF > localhost-restore.yaml --- ansible_become_pass: "<admin_password>" admin_password: "<admin_password>" initial_backup_dir: "<location_of_backup_filename>" backup_filename: "<openstack_tgz_backup_filename>" restore_cinder_glance_data="true" ... EOF
When this step has completed, the Cinder, Glance and MariaDB services will be up, and Mariadb data restored.
Restore Ceph data.
Restore Cinder volumes using the rbd import command.
For example:
~(keystone_admin)$ rbd import -p cinder-volumes /tmp/611157b9-78a4-4a26-af16-f9ff75a85e1b
Where
tmp/611157b9-78a4-4a26-af16-f9ff75a85e1bis a file saved earlier at the backup procedure as described in Back up OpenStack.Restore Glance images using the image-backup script.
For example, if we have an archive named
image_3f30adc2-3e7c-45bf-9d4b-a4c1e191d879.tgzin the/opt/backupsdirectory, we can use restore it using the following command:~(keystone_admin)$ sudo image-backup.sh import image_3f30adc2-3e7c-45bf-9d4b-a4c1e191d879.tgz
Use the tidy_storage_post_restore utility to detect any discrepancy between Cinder/Glance DB and rbd pools:
~(keystone_admin)$ tidy_storage_post_restore <log_file>
After the script finishes, some command output will be written to the log file. They will help reconcile discrepancies between the StarlingX OpenStack database and CEPH data.
Run the playbook again with the
restore_openstack_continueflag set totrueto bring up the remaining OpenStack services.~(keystone_admin)$ ansible-playbook /usr/share/ansible/stx-ansible/playbooks/ restore_openstack.yml -e "@localhost-restore.yaml"
cat << EOF > localhost-restore.yaml --- ansible_become_pass: "<admin_password>" admin_password: "<admin_password>" initial_backup_dir: "<location_of_backup_filename>" backup_filename: "<openstack_tgz_backup_filename>" restore_openstack_continue="true" ... EOF