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

  1. 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
  2. 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

  1. Create a restore override file required for StarlingX OpenStack:

    cat << EOF > <subcloud>-restore.yaml
    restore_extra_items:
      - "etc/dcdbsync/dcdbsync_openstack.conf"
    EOF
    
  2. 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.

  3. After the restore completes, access the subcloud and complete the StarlingX OpenStack application restoration.

  4. Remove, delete, and upload the StarlingX OpenStack application tarball:

    system application-remove |prefix|-openstack
    system application-delete |prefix|-openstack
    system application-upload |prefix|-openstack
    
  5. 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

  1. Remove, delete, and upload the StarlingX OpenStack application tarball:

    system application-remove |prefix|-openstack
    system application-delete |prefix|-openstack
    system application-upload |prefix|-openstack
    
  2. 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

  1. 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.

  2. Restore Ceph data.

    1. 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-f9ff75a85e1b is a file saved earlier at the backup procedure as described in Back up OpenStack.

    2. Restore Glance images using the image-backup script.

      For example, if we have an archive named image_3f30adc2-3e7c-45bf-9d4b-a4c1e191d879.tgz in the /opt/backups directory, we can use restore it using the following command:

      ~(keystone_admin)$ sudo image-backup.sh import image_3f30adc2-3e7c-45bf-9d4b-a4c1e191d879.tgz
      
    3. 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.

  3. Run the playbook again with the restore_openstack_continue flag set to true to 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