From 375088f5fd418e8df0bbb73725c2dde6351709ef Mon Sep 17 00:00:00 2001 From: Elisamara Aoki Goncalves Date: Tue, 13 Dec 2022 16:24:55 -0300 Subject: [PATCH] Centralized B&R Create Backup and Restore using DCManager CLI Move sections do distributed cloud Delete older section Restoring a Subcloud from Backup Data Using DCManager CLI Fix conflict Story: 2010116 Task: 46548 Signed-off-by: Elisamara Aoki Goncalves Change-Id: Iba938731f1ab188e41c9ab1dea09badef37bfd5a --- .../index-backup-kub-699e0d16c076.rst | 1 + ...louds-using-dcmanager-cli-f12020a8fc42.rst | 278 +++++++++++++++++ ...-data-using-dcmanager-cli-9cabe48bc4fd.rst | 89 ++++++ .../index-dist-cloud-kub-95bef233eef0.rst | 4 +- ...-data-using-dcmanager-cli-f10c1b63a95e.rst | 293 ++++++++++++++++++ ...clouds-from-backupdata-using-dcmanager.rst | 118 ------- 6 files changed, 664 insertions(+), 119 deletions(-) create mode 100644 doc/source/dist_cloud/kubernetes/backup-a-subcloud-group-of-subclouds-using-dcmanager-cli-f12020a8fc42.rst create mode 100644 doc/source/dist_cloud/kubernetes/delete-subcloud-backup-data-using-dcmanager-cli-9cabe48bc4fd.rst create mode 100644 doc/source/dist_cloud/kubernetes/restore-a-subcloud-group-of-subclouds-from-backup-data-using-dcmanager-cli-f10c1b63a95e.rst delete mode 100644 doc/source/dist_cloud/kubernetes/restoring-subclouds-from-backupdata-using-dcmanager.rst diff --git a/doc/source/backup/kubernetes/index-backup-kub-699e0d16c076.rst b/doc/source/backup/kubernetes/index-backup-kub-699e0d16c076.rst index 677fc0bdc..c12308e75 100644 --- a/doc/source/backup/kubernetes/index-backup-kub-699e0d16c076.rst +++ b/doc/source/backup/kubernetes/index-backup-kub-699e0d16c076.rst @@ -24,3 +24,4 @@ System and storage restore running-restore-playbook-locally-on-the-controller system-backup-running-ansible-restore-playbook-remotely + diff --git a/doc/source/dist_cloud/kubernetes/backup-a-subcloud-group-of-subclouds-using-dcmanager-cli-f12020a8fc42.rst b/doc/source/dist_cloud/kubernetes/backup-a-subcloud-group-of-subclouds-using-dcmanager-cli-f12020a8fc42.rst new file mode 100644 index 000000000..60d160d9f --- /dev/null +++ b/doc/source/dist_cloud/kubernetes/backup-a-subcloud-group-of-subclouds-using-dcmanager-cli-f12020a8fc42.rst @@ -0,0 +1,278 @@ +.. _backup-a-subcloud-group-of-subclouds-using-dcmanager-cli-f12020a8fc42: + +======================================================== +Backup a Subcloud/Group of Subclouds using DCManager CLI +======================================================== + +A subcloud's system data and optionally container images (from registry.local) +can be backed up using dcmanager command line interface (|CLI|). The subcloud's +system backup data can either be stored locally on the subcloud or on the +system controller. The subcloud's container image backup (from registry.local) +can only be stored locally on the subcloud to avoid overloading central storage +and the network with large amount of data transfer. + +By default, the system controller is used as backup archive storage. Once the +system data backup file has been generated on the subcloud, it will be +transferred to the system controller and stored at a dedicated central location +``/opt/dc-vault/backups//``. + +Backup data creation requires the subcloud to be online, managed, and in +healthy state. + +.. rubric:: |context| + +The |CLI| command :command:`dcmanager subcloud-backup create` can be used to +backup a subcloud or a group of subclouds. The command accepts the following +parameters/options: + +``--local-only`` + Generate a local backup archive and do not transfer to central storage + (default storage location: + ``/opt/platform-backup/backups/``). If not specified, + default is to transfer backup archive to central storage on + systemController. + +``--registry-images`` + Generate backup of container images from registry.local (local storage + only. Default storage location: + ``/opt/platform-backup/backups/) + +``--subcloud `` + The subcloud to perform the backup operation on. + +``--group `` + The group of subclouds to perform backup operations on. + +``--backup-values `` + The yaml file containing the customization parameters for the backup + operation. + + - ``wipe_ceph_osds=false``: To keep the Ceph cluster data intact. + - ``wipe_ceph_osds=true``: To wipe the Ceph cluster entirely + - ``on_box_data=true``: To indicate that the backup data file is under + /opt/platform-backup directory on the local machine + + See :ref:`Run Ansible Backup Playbook Locally on the Controller + ` for the list + of configurable system backup parameters + +``--sysadmin-password `` + If not specified, user will be prompted for the password. Recommend that + this option is ONLY used for automation; i.e., for interactive use, don't + use option and specify password on prompting, so as to avoid sysadmin + password getting into log files. + + +The ``--subcloud/--group`` is a mandatory parameter. + +When ``--registry-images`` option is applied, the entire registry filesystem +which contains both platform and user container images will be backed up. + +Backup data of at most 2 software releases can be retained. Data of the oldest +software release will be removed to make room for data of the newest software +release. At most one set of backup data is stored for each release. The newly +generated set will replace the old one if exists. + +The local storage location of backup data files can be customized using +``--backup-values `` option. The ``--backup-values ``is +specified on the systemController every time you execute ``dcmanager +subcloud-backup create``, so the backup values are easily re-applied to a +subcloud regardless of whether it has been re-installled or not.Storage +location customization and/or backup filename customization can also lead to +complications in restoring a group of subclouds. + +It is not possible to customize the central storage location. Backup data of +all subclouds stored centrally will have the same naming convention and be +stored at ``/opt/dc-vault/backups///``. + + +Back up a single subcloud +------------------------- + +.. rubric:: |prereq| + +- The System Controller is healthy and ready to accept dcmanager related + commands. + +- For central storage, the ``dc-vault`` filesystem has enough storage to + accommodate new subcloud backup files. + +- For local storage, the ``/opt/platform-backup`` partition on the subcloud + has enough storage to accommodate new subcloud backup files(s). + +- The subcloud is managed, online and healthy. + +.. rubric:: |proc| + +To backup a subcloud system data and store the backup file in the central +storage: + +.. code-block:: none + + ~(keystone_admin)]$ dcmanager subcloud-backup create --subcloud --sysadmin-password + +To backup a subcloud system data and store the backup file in default local +storage: + +.. code-block:: none + + ~(keystone_admin)]$ dcmanager subcloud-backup create --subcloud --local-only --sysadmin-password + +To backup a subcloud system data as well as all container images and store the +backup files in default local storage: + +.. code-block:: none + + ~(keystone_admin)]$ dcmanager subcloud-backup create --subcloud --local-only --registry-images --sysadmin-password + +.. note:: + + - The ``--registry-images`` option must only be used with ``--local-only`` + option. + + - The images backup file will contain both platform and user/custom + images that are in the subcloud local registry. + + +To backup a subcloud system data with a custom filename and store the backup +file in default local storage: + +#. Create a yaml file e.g. ``backup_overrides.yaml`` with the following + content: + + .. code-block:: none + + platform_backup_filename_prefix: test_backup + +#. Then, run the command: + + .. code-block:: none + + ~(keystone_admin)]$ dcmanager subcloud-backup create --subcloud --local-only --backup-values backup_overrides.yaml --sysadmin-password + +Sample response to a single subcloud backup: + +.. code-block:: none + + +-----------------------------+----------------------------+ + | Field | Value | + +-----------------------------+----------------------------+ + | id | 7 | + | name | subcloud1 | + | description | None | + | location | None | + | software_version | 22.12 | + | management | managed | + | availability | online | + | deploy_status | complete | + | management_subnet | fd01:176::0/64 | + | management_start_ip | fd01:176::2 | + | management_end_ip | fd01:176::11 | + | management_gateway_ip | fd01:176::1 | + | systemcontroller_gateway_ip | fd01:1::1 | + | group_id | 1 | + | created_at | 2022-12-13 00:09:44.543494 | + | updated_at | 2022-12-13 01:25:16.343380 | + | backup_status | initial | + | backup_datetime | None | + +-----------------------------+----------------------------+ + +To view the progress of subcloud backup, use :command:`dcmanager subcloud show` +or :command:`dcmanager subcloud list` command: + +.. code-block:: none + + ~(keystone_admin)]$ dcmanager subcloud show subcloud1 + + +-----------------------------+----------------------------+ + | Field | Value | + +-----------------------------+----------------------------+ + | id | 7 | + | name | subcloud1 | + | description | None | + | location | None | + | software_version | 22.12 | + | management | managed | + | availability | online | + | deploy_status | complete | + | management_subnet | fd01:176::0/64 | + | management_start_ip | fd01:176::2 | + | management_end_ip | fd01:176::11 | + | management_gateway_ip | fd01:176::1 | + | systemcontroller_gateway_ip | fd01:1::1 | + | group_id | 1 | + | created_at | 2022-12-13 00:09:44.543494 | + | updated_at | 2022-12-13 04:13:46.462597 | + | backup_status | backing-up | + | backup_datetime | None | + | dc-cert_sync_status | in-sync | + | firmware_sync_status | in-sync | + | identity_sync_status | in-sync | + | kubernetes_sync_status | in-sync | + | kube-rootca_sync_status | in-sync | + | load_sync_status | in-sync | + | patching_sync_status | in-sync | + | platform_sync_status | in-sync | + +-----------------------------+----------------------------+ + +If the backup operation completes successfully, the backup_status field will +show as complete and where the backup file is stored (central vs local); and +the ``backup_datetime`` will show the time the backup was taken. + +For example: + +.. code-block:: none + + ~(keystone_admin)]$ dcmanager subcloud list + + +----+-----------+------------+--------------+---------------+---------+------------------+----------------------------+ + | id | name | management | availability | deploy status | sync | backup status | backup datetime | + +----+-----------+------------+--------------+---------------+---------+------------------+----------------------------+ + | 4 | subcloud1 | managed | online | complete | in-sync | complete-local | 2022-12-12 18:47:10.221813 | + | 7 | subcloud2 | managed | online | complete | in-sync | complete-central | 2022-12-13 04:17:15.281068 | + +----+-----------+------------+--------------+---------------+---------+------------------+----------------------------+ + +If the backup operation fails, :command:`dcmanager subcloud errors` command can +be used to view the error. + +Back up a group of subclouds +---------------------------- + +The above ``subcloud-backup create`` operations can be performed for a group of +subclouds simultaneously by replacing ``--subcloud`` option with ``--group`` +option. For instance, to backup system data for a group of subclouds and store +the backup files in the central storage: + +.. code-block:: none + + ~(keystone_admin)]$ dcmanager subcloud-backup create --group --sysadmin-password + +If all subclouds in the group are unmanaged or offline, an error message will +be displayed. If some of the subclouds in the group meet backup operation +criteria, a list will be displayed. + +Sample group backup response: + +.. code-block:: none + + +----+-----------+-------------+----------+------------------+------------+--------------+---------------+-------------------+---------------------+-------------------+-----------------------+-----------------------------+----------+----------------------------+----------------------------+---------------+-----------------+ + | id | name | description | location | software_version | management | availability | deploy_status | management_subnet | management_start_ip | management_end_ip | management_gateway_ip | systemcontroller_gateway_ip | group_id | created_at | updated_at | backup_status | backup_datetime | + +----+-----------+-------------+----------+------------------+------------+--------------+---------------+-------------------+---------------------+-------------------+-----------------------+-----------------------------+----------+----------------------------+----------------------------+---------------+-----------------+ + | 8 | subcloud1 | None | None | 22.12 | managed | online | complete | fd01:15::0/64 | fd01:15::2 | fd01:15::11 | fd01:15::1 | fd01:1::1 | 2 | 2022-12-13 18:23:03.883068 | 2022-12-13 21:28:10.190154 | initial | None | + | 9 | subcloud2 | None | None | 22.12 | managed | online | complete | fd01:176::0/64 | fd01:176::2 | fd01:176::11 | fd01:176::1 | fd01:1::1 | 2 | 2022-12-13 19:27:55.115604 | 2022-12-13 21:28:17.221334 | initial | None | + +----+-----------+-------------+----------+------------------+------------+--------------+---------------+-------------------+---------------------+-------------------+-----------------------+-----------------------------+----------+----------------------------+----------------------------+---------------+-----------------+ + +To view the progress of subcloud group backup, use :command:`dcmanager subcloud list` +or :command:`dcmanager subcloud-group list-subclouds` command. + +.. code-block:: none + + ~(keystone_admin)]$ watch dcmanager subcloud list + + +----+-----------+------------+--------------+---------------+---------+---------------+-----------------+ + | id | name | management | availability | deploy status | sync | backup status | backup datetime | + +----+-----------+------------+--------------+---------------+---------+---------------+-----------------+ + | 8 | subcloud1 | managed | online | complete | in-sync | backing-up | None | + | 9 | subcloud2 | managed | online | complete | in-sync | backing-up | None | + +----+-----------+------------+--------------+---------------+---------+---------------+-----------------+ + diff --git a/doc/source/dist_cloud/kubernetes/delete-subcloud-backup-data-using-dcmanager-cli-9cabe48bc4fd.rst b/doc/source/dist_cloud/kubernetes/delete-subcloud-backup-data-using-dcmanager-cli-9cabe48bc4fd.rst new file mode 100644 index 000000000..6a2b6df8f --- /dev/null +++ b/doc/source/dist_cloud/kubernetes/delete-subcloud-backup-data-using-dcmanager-cli-9cabe48bc4fd.rst @@ -0,0 +1,89 @@ +.. _delete-subcloud-backup-data-using-dcmanager-cli-9cabe48bc4fd: + +=============================================== +Delete Subcloud Backup Data Using DCManager CLI +=============================================== + +Subcloud backup data stored centrally or locally can be removed using dcmanager +command line interface (|CLI|). Backup data removal from the local storage +requires the subcloud to be managed and online. This restriction does not apply +to data removal from central storage. + +When a subcloud is deleted, its backup data in central storage is automatically +removed. + +.. rubric:: |context| + +The |CLI| command :command:`dcmanager subcloud-backup delete` can be used to +delete backup data for a subcloud or a group of subclouds. By default, the +command removes the subcloud backup data on the central systemController. The +command accepts the following parameters/options: + +``release`` + Mandatory parameter specifying the which release's backup to remove + +``--local-only`` + Remove backup data for the specified release on the subcloud + +``--subcloud `` + The subcloud whose backup data should be removed + +``--group `` + The group of subclouds whose backup data should be removed + +``--sysadmin-password `` + Only required if using --local-only option. If not specified when using + --local-only option, user will be prompted for the password. Recommend that + this option is ONLY used for automation; i.e., for interactive use, do not + use option and specify password on prompting, so as to avoid sysadmin + password getting into log files. + + +The release version and ``--subcloud/--group`` are mandatory parameters. + +This operation has one caveat. After this command is carried out successfully, +both backup_status and ``backup_datetime`` fields will be set to 'unknown' and +'None' respectively even though there might be another set of backup data in +either central storage or local storage. + + +Delete backup data for a single subcloud +---------------------------------------- + +.. rubric:: |prereq| + +- The System Controller is healthy and ready to accept dcmanager related + commands. + +- The release version is valid. + +- The subcloud is managed and online (applicable to backup data removal from + local storage only). + +.. rubric:: |proc| + +To delete backup data for |prod| |prod-ver| from central storage: + +.. code-block:: none + + ~(keystone_admin)]$ dcmanager subcloud-backup delete 22.12 --subcloud + +To delete backup data for |prod| |prod-ver| from local storage: + +.. code-block:: none + + ~(keystone_admin)]$ dcmanager subcloud-backup delete 22.12 --local-only --subcloud --sysadmin-password + + +Delete backup data for a group of subclouds +------------------------------------------- + +The above subcloud-backup delete operations can be performed for a group of +subclouds simultaneously by replacing ``--subcloud`` option with ``--group +option``. For instance, to delete backup data for |prod| |prod-ver| for a group +of subclouds from central storage: + +.. code-block:: none + + ~(keystone_admin)]$ dcmanager subcloud-backup delete 22.12 -group + diff --git a/doc/source/dist_cloud/kubernetes/index-dist-cloud-kub-95bef233eef0.rst b/doc/source/dist_cloud/kubernetes/index-dist-cloud-kub-95bef233eef0.rst index d96578af8..2c75958da 100644 --- a/doc/source/dist_cloud/kubernetes/index-dist-cloud-kub-95bef233eef0.rst +++ b/doc/source/dist_cloud/kubernetes/index-dist-cloud-kub-95bef233eef0.rst @@ -52,7 +52,9 @@ Operation changing-the-admin-password-on-distributed-cloud updating-docker-registry-credentials-on-a-subcloud migrate-an-aiosx-subcloud-to-an-aiodx-subcloud - restoring-subclouds-from-backupdata-using-dcmanager + backup-a-subcloud-group-of-subclouds-using-dcmanager-cli-f12020a8fc42 + delete-subcloud-backup-data-using-dcmanager-cli-9cabe48bc4fd + restore-a-subcloud-group-of-subclouds-from-backup-data-using-dcmanager-cli-f10c1b63a95e rehoming-a-subcloud prestage-a-subcloud-using-dcmanager-df756866163f add-a-horizon-keystone-user-to-distributed-cloud-29655b0f0eb9 diff --git a/doc/source/dist_cloud/kubernetes/restore-a-subcloud-group-of-subclouds-from-backup-data-using-dcmanager-cli-f10c1b63a95e.rst b/doc/source/dist_cloud/kubernetes/restore-a-subcloud-group-of-subclouds-from-backup-data-using-dcmanager-cli-f10c1b63a95e.rst new file mode 100644 index 000000000..05600842f --- /dev/null +++ b/doc/source/dist_cloud/kubernetes/restore-a-subcloud-group-of-subclouds-from-backup-data-using-dcmanager-cli-f10c1b63a95e.rst @@ -0,0 +1,293 @@ +.. _restore-a-subcloud-group-of-subclouds-from-backup-data-using-dcmanager-cli-f10c1b63a95e: + +========================================================================== +Restore a Subcloud/Group of Subclouds from Backup Data Using DCManager CLI +========================================================================== + +A subcloud can be restored from its backup data previously stored centrally on +the system controller or locally on the subcloud using dcmanager command line +interface (|CLI|). The subcloud install data must be available for this +operation to proceed. The subcloud must support Redfish Virtual Media Service +(version 1.2 or higher) if remote installation is required. + +.. rubric:: |context| + +The |CLI| command :command:`dcmanager subcloud-backup restore` can be used to +restore a subcloud or a group of subclouds. By default, the restore is done +from subcloud backup data on the central systemController. The command accepts +the following parameters/options: + +``--with-install`` + Perform remote installation of the subcloud prior to execution of restore + procedure. The subcloud must support Redfish Virutal Media Service (version + 1.2 or higher) to use this option. + +``--local-only`` + Use the local backup archive (default local storage + ``/opt/platform-backup/backups/``). If not specified, the + subcloud backup archive on the central systemController will be used. + +``--registry-images`` + Restore saved container images to registry.local as part of restore + procedure (local storage only) + +``--subcloud `` + The subcloud to restore. + +``--group `` + The group of subclouds to restore. + +``--restore-values `` + The yaml file containing the customization parameters. + + - ``wipe_ceph_osds=false``: To keep the Ceph cluster data intact. + - ``wipe_ceph_osds=true``: To wipe the Ceph cluster entirely + - ``on_box_data=true``: To indicate that the backup data file is under + /opt/platform-backup directory on the local machine + + See :ref:`Run Restore Playbook Locally on the Controller + ` for the list of + configurable system restore parameters. + +``--sysadmin-password `` + If not specified, user will be prompted for the password. Recommend that + this option is ONLY used for automation; i.e., for interactive use, don't + use option and specify password on prompting, so as to avoid sysadmin + password getting into log files. + +The ``--subcloud/--group`` is a mandatory parameter. + +"When ``--registry-images`` option is applied, the entire registry filesystem +which contains both platform and user container images will be restored. + +After the subcloud has been re-installed with the desired release version, the +backup archive for that release will be transferred to the subcloud for the +restore operation by default. If ``--local-only`` option is specified, the local +backup archive for the release will be used instead. + +It is possible to specify a custom location of the backup file that resides on +the subcloud using ``--restore-values`` option and by setting +``initial_backup_dir`` and ``backup_filename`` in the provided +``restore_values`` yaml file. Please ensure this custom backup file is not +corrupted and is compatible with software release the subcloud was installed +with. + + +To restore images from a custom backup file on the subcloud using +``--restore-values `` option, the registry_backup_filename parameter +must be set in ``restore_values`` yaml file. + + +Restore a single subcloud +------------------------- + +.. rubric:: |prereq| + +- The System Controller is healthy and ready to accept dcmanager related + commands. + +- The subcloud is unmanaged and is in a valid state for restore operation + (i.e. not being restored, installed, bootstrapped, deployed or rehomed). + +- The subcloud install data is available. + +- The backup file(s) exists and is compatible with the software release the + subcloud is being restored to. + + +.. rubric:: |proc| + +To restore a subcloud, including remote installation, from system backup data +in central storage: + +.. code-block:: none + + ~(keystone_admin)]$ dcmanager subcloud-backup restore --subcloud --with-install --sysadmin-password + +To restore a pre-installed subcloud from system backup data in central storage: + +.. code-block:: none + + ~(keystone_admin)]$ dcmanager subcloud-backup restore --subcloud --with-install --sysadmin-password + +To restore a subcloud, including remote installation, from system backup data +stored in default local storage: + +.. code-block:: none + + ~(keystone_admin)]$ dcmanager subcloud-backup restore --subcloud --with-install --local-only --sysadmin-password + +To restore a subcloud, including remote installation, from system backup and +images backup data in default local storage: + +.. code-block:: none + + ~(keystone_admin)]$ dcmanager subcloud-backup restore --subcloud --local-only --registry-images --sysadmin-password + +.. note:: + + The ``--registry-images`` option can only be used with ``--local-only`` + option. + + +To restore a pre-installed subcloud from system and images backup data stored +at custom location on the subcloud: + +#. Create a yaml file e.g. ``restore_overrides.yaml`` with the following + content: + + .. code-block:: none + + initial_backup_dir: /home/sysadmin/mybackup_dir + backup_filename: test_platform_backup.tgz + registry_backup_filename: test_images_backup.tgz + +#. Then, run the command: + + .. code-block:: none + + ~(keystone_admin)]$ dcmanager subcloud-backup restore --subcloud subcloud1 --local-only –-registry-images --restore-values restore_overrides.yaml --sysadmin-password + +Sample response to a single subcloud restore: + +.. code-block:: none + + +-----------------------------+----------------------------+ + | Field | Value | + +-----------------------------+----------------------------+ + | id | 8 | + | name | subcloud1 | + | description | None | + | location | None | + | software_version | 22.12 | + | management | unmanaged | + | availability | offline | + | deploy_status | restore-failed | + | management_subnet | fd01:15::0/64 | + | management_start_ip | fd01:15::2 | + | management_end_ip | fd01:15::11 | + | management_gateway_ip | fd01:15::1 | + | systemcontroller_gateway_ip | fd01:1::1 | + | group_id | 2 | + | created_at | 2022-12-12 05:29:23.807243 | + | updated_at | 2022-12-13 16:39:48.904037 | + | backup_status | unknown | + | backup_datetime | None | + +-----------------------------+----------------------------+ + +.. note:: + + The subcloud can be restored or restored again while in a failed deploy + state such as: + + - data-migration-failed (upgrade failure) + + - restore-failed (previous restore attempt failed due to a bad backup file) + + - rehome-failed + +To view the progress of subcloud restore, please use :command:`dcmanager subcloud show` +or :command:`dcmanager subcloud list` command: + +.. code-block:: none + + ~(keystone_admin)]$ dcmanager subcloud show subcloud1 + + +-----------------------------+----------------------------+ + | Field | Value | + +-----------------------------+----------------------------+ + | id | 9 | + | name | subcloud2 | + | description | None | + | location | None | + | software_version | 22.12 | + | management | unmanaged | + | availability | offline | + | deploy_status | restoring | + | management_subnet | fd01:176::0/64 | + | management_start_ip | fd01:176::2 | + | management_end_ip | fd01:176::11 | + | management_gateway_ip | fd01:176::1 | + | systemcontroller_gateway_ip | fd01:1::1 | + | group_id | 2 | + | created_at | 2022-12-13 00:09:44.543494 | + | updated_at | 2022-12-13 18:23:20.659138 | + | backup_status | unknown | + | backup_datetime | None | + | dc-cert_sync_status | unknown | + | firmware_sync_status | unknown | + | identity_sync_status | unknown | + | kubernetes_sync_status | unknown | + | kube-rootca_sync_status | unknown | + | load_sync_status | unknown | + | patching_sync_status | unknown | + | platform_sync_status | unknown | + +-----------------------------+----------------------------+ + +If the restore operation completes successfully, the subcloud will become +online and the ``deploy_status`` will be set to 'complete'. + +Please continue with :ref:`Post restore procedure `. + +If the restore operation fails, :command:`dcmanager subcloud errors` command +can be used to view the error. + + +Restore a group of subclouds +---------------------------- + +The above subcloud-backup restore operations can be performed for a group of +subclouds simultaneously by replacing ``--subcloud`` option with ``--group`` +option. For instance, to restore a group of subclouds with remote installation +from their system data in central storage: + +.. code-block:: none + + ~(keystone_admin)]$ dcmanager subcloud-backup restore --group --with-install --sysadmin-password + + +If all subclouds in the group are not in the valid state for restore, an error +message will be displayed. If some of the subclouds in the group meet restore +operation criteria, a list will be displayed. + +Sample group restore response: + +.. code-block:: none + + +----+-----------+-------------+----------+------------------+------------+--------------+---------------+-------------------+---------------------+-------------------+-----------------------+-----------------------------+----------+----------------------------+----------------------------+----------------+----------------------------+ + | id | name | description | location | software_version | management | availability | deploy_status | management_subnet | management_start_ip | management_end_ip | management_gateway_ip | systemcontroller_gateway_ip | group_id | created_at | updated_at | backup_status | backup_datetime | + +----+-----------+-------------+----------+------------------+------------+--------------+---------------+-------------------+---------------------+-------------------+-----------------------+-----------------------------+----------+----------------------------+----------------------------+----------------+----------------------------+ + | 8 | subcloud6 | None | None | 22.12 | unmanaged | online | complete | fd01:15::0/64 | fd01:15::2 | fd01:15::11 | fd01:15::1 | fd01:1::1 | 2 | 2022-12-13 18:23:03.883068 | 2022-12-13 22:14:39.331199 | complete-local | 2022-12-13 22:04:06.232043 | + | 9 | subcloud8 | None | None | 22.12 | unmanaged | online | complete | fd01:176::0/64 | fd01:176::2 | fd01:176::11 | fd01:176::1 | fd01:1::1 | 2 | 2022-12-13 19:27:55.115604 | 2022-12-13 22:15:09.287665 | complete-local | 2022-12-13 22:05:03.785280 | + +----+-----------+-------------+----------+------------------+------------+--------------+---------------+-------------------+---------------------+-------------------+-----------------------+-----------------------------+----------+----------------------------+----------------------------+----------------+----------------------------+ + +After group restore is complete, continue with :ref:`Post restore procedure +` for each subcloud in the group. + +.. _post-restore-procedure: + +Post restore procedure +---------------------- + +**AIO-SX subcloud** + +Resume subcloud audit with the command: + +.. code-block:: none + + ~(keystone_admin)]$ dcmanager subcloud manage + +**AIO-DX/Standard subcloud** + +After the controller-0 has been restored and the subcloud becomes online, +follow the procedure :ref:`Restore Platform System Data and Storage +` to restore the rest of the +subcloud nodes. + +Resume subcloud audit with the command: + +.. code-block:: none + + ~(keystone_admin)]$ dcmanager subcloud manage + + diff --git a/doc/source/dist_cloud/kubernetes/restoring-subclouds-from-backupdata-using-dcmanager.rst b/doc/source/dist_cloud/kubernetes/restoring-subclouds-from-backupdata-using-dcmanager.rst deleted file mode 100644 index 0e7e14854..000000000 --- a/doc/source/dist_cloud/kubernetes/restoring-subclouds-from-backupdata-using-dcmanager.rst +++ /dev/null @@ -1,118 +0,0 @@ - -.. Greg updates required for -High Security Vulnerability Document Updates - -.. _restoring-subclouds-from-backupdata-using-dcmanager: - -========================================================= -Restoring a Subcloud From Backup Data Using DCManager CLI -========================================================= - -For subclouds with servers that support Redfish Virtual Media Service -(version 1.2 or higher), you can use the Central Cloud's CLI to restore the -subcloud from data that was backed up previously. - -Before you start an |AIO-SX| subcloud upgrade or reinstall for the purpose of -restoring the subcloud, see :ref:`prestage-a-subcloud-using-dcmanager-df756866163f`. - -.. rubric:: |context| - -The CLI command :command:`dcmanager subcloud restore` can be used to restore a -subcloud from available system data and bring it back to the operational state -it was in when the backup procedure took place. The subcloud restore has three -phases: - -- Re-install the controller-0 of the subcloud with the current active load - running in the SystemController. For subcloud servers that support - Redfish Virtual Media Service, this phase can be carried out remotely - as part of the CLI. - -- Run Ansible Platform Restore to restore |prod|, from a previous backup on - the controller-0 of the subcloud. This phase is also carried out as part - of the CLI. - -- Unlock the controller-0 of the subcloud and continue with the steps to - restore the remaining nodes of the subcloud where applicable. This phase - is carried out by the system administrator, see :ref:`Restoring Platform System Data and Storage `. - -.. rubric:: |prereq| - -- The SystemController is healthy, and ready to accept **dcmanager** related - commands. - -- The subcloud is unmanaged, and not in the process of installation, - bootstrap or deployment. - -- The platform backup tar file is already on the subcloud in - ``/opt/platform-backup`` directory or has been transferred to the - SystemController. - -- The subcloud install values have been saved in the **dcmanager** database - i.e. the subcloud has been installed remotely as part of :command:`dcmanager subcloud add`. - -.. rubric:: |proc| - -#. Create the ``restore_values.yaml`` file which will be passed to the - :command:`dcmanager subcloud restore` command using the ``--restore-values`` - option. This file contains parameters that will be used during the platform - restore phase. Minimally, the **backup_filename** parameter, indicating the - file containing a previous backup of the subcloud, must be specified in the - yaml file, see :ref:`Run Ansible Restore Playbook Remotely `, - and, :ref:`Run Restore Playbook Locally on the Controller `, - for supported restore parameters. - -#. Restore the subcloud, using the dcmanager CLI command, :command:`subcloud restore` - and specify the restore values, with the ``--with-install`` option and the - subcloud's sysadmin password. - - .. code-block:: none - - ~(keystone_admin) $ dcmanager subcloud restore --restore-values /home/sysadmin/subcloud1-restore.yaml --with-install --sysadmin-password subcloud-name-or-id - - Where: - - - ``--restore-values`` must reference the restore values yaml file - mentioned in Step 1 of this procedure. - - - ``--with-install`` indicates that a re-install of controller-0 of the - subcloud should be done remotely using Redfish Virtual Media Service. - - If the ``--sysadmin-password`` option is not specified, the system - administrator will be prompted for the password. The password is masked - when it is entered. Enter the sysadmin password for the subcloud. - The **dcmanager subcloud restore** can take up to 30 minutes to reinstall - and restore the platform on controller-0 of the subcloud. - -#. On the Central Cloud (SystemController), monitor the progress of the - subcloud reinstall and restore via the deploy status field of the - :command:`dcmanager subcloud list` command. - - .. code-block:: none - - ~(keystone_admin)]$ dcmanager subcloud list - - +----+-----------+------------+--------------+---------------+---------+ - | id | name | management | availability | deploy status | sync | - +----+-----------+------------+--------------+---------------+---------+ - | 1 | subcloud1 | unmanaged | online | installing | unknown | - +----+-----------+------------+--------------+---------------+---------+ - -#. In case of a failure, check the Ansible log for the corresponding subcloud - under ``/var/log/dcmanager/ansible`` directory. - -#. When the subcloud deploy status changes to "complete", the controller-0 - is ready to be unlocked. Log into the controller-0 of the subcloud using - its bootstrap IP and unlock the host using the following command. - - .. code-block:: none - - ~(keystone_admin)]$ system host-unlock controller-0 - -#. For |AIO|-DX and Standard subclouds, follow the procedure, - see :ref:`Restoring Platform System Data and Storage ` - to restore the rest of the subcloud nodes. - -#. To resume subcloud audit, use the following command. - - .. code-block:: none - - ~(keystone_admin)]$ dcmanager subcloud manage