starlingx/docs
Code Issues Proposed changes

Centralized B&R

Browse Source 
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 <elisamaraaoki.goncalves@windriver.com>
Change-Id: Iba938731f1ab188e41c9ab1dea09badef37bfd5a
This commit is contained in:
Elisamara Aoki Goncalves 2022-12-13 16:24:55 -03:00
parent 3ac3d95ff0
commit 375088f5fd
6 changed files with 664 additions and 119 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
doc/source/backup/kubernetes/index-backup-kub-699e0d16c076.rst
View File

@ -24,3 +24,4 @@ System and storage restore
running-restore-playbook-locally-on-the-controller
system-backup-running-ansible-restore-playbook-remotely

278
doc/source/dist_cloud/kubernetes/backup-a-subcloud-group-of-subclouds-using-dcmanager-cli-f12020a8fc42.rst Normal file
View File

@ -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/<subcloud-name>/<release-version>``.
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/<release-version>``). 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/<release-version``>)
``--subcloud <subcloud-name>``
The subcloud to perform the backup operation on.
``--group <subcloud-group-name>``
The group of subclouds to perform backup operations on.
``--backup-values <yaml-file>``
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
<running-ansible-backup-playbook-locally-on-the-controller>` for the list
of configurable system backup parameters
``--sysadmin-password <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 <yaml-file>`` option. The ``--backup-values <yaml-file>``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/<subcloud>/<release>/``.
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 <subcloud> --sysadmin-password <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 <subcloud> --local-only --sysadmin-password <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 <subcloud> --local-only --registry-images --sysadmin-password <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 <subcloud> --local-only --backup-values backup_overrides.yaml --sysadmin-password <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 <group> --sysadmin-password <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 |
+----+-----------+------------+--------------+---------------+---------+---------------+-----------------+

89
doc/source/dist_cloud/kubernetes/delete-subcloud-backup-data-using-dcmanager-cli-9cabe48bc4fd.rst Normal file
View File

@ -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 <subcloud-name>``
The subcloud whose backup data should be removed
``--group <subcloud-group-name>``
The group of subclouds whose backup data should be removed
``--sysadmin-password <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 <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 <subcloud> --sysadmin-password <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 <group>

4
doc/source/dist_cloud/kubernetes/index-dist-cloud-kub-95bef233eef0.rst
View File

@ -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

293
doc/source/dist_cloud/kubernetes/restore-a-subcloud-group-of-subclouds-from-backup-data-using-dcmanager-cli-f10c1b63a95e.rst Normal file
View File

@ -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/<release-version>``). 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 <subcloud-name>``
The subcloud to restore.
``--group <subcloud-group-name>``
The group of subclouds to restore.
``--restore-values <yaml-file>``
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
<running-restore-playbook-locally-on-the-controller>` for the list of
configurable system restore parameters.
``--sysadmin-password <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 <yaml-file>`` 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 <subcloud-name> --with-install --sysadmin-password <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 <subcloud-name> --with-install --sysadmin-password <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 <subcloud-name> --with-install --local-only --sysadmin-password <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 <subcloud-name> --local-only --registry-images --sysadmin-password <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 <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 <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 <group> --with-install --sysadmin-password <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
<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
<restoring-starlingx-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

118
doc/source/dist_cloud/kubernetes/restoring-subclouds-from-backupdata-using-dcmanager.rst
View File

@ -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 <restoring-starlingx-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 <system-backup-running-ansible-restore-playbook-remotely>`,
and, :ref:`Run Restore Playbook Locally on the Controller <running-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 <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 <restoring-starlingx-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