Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Procedures: Che backup review #2140

Merged
merged 3 commits into from
Oct 21, 2021
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@
:context: backup-and-disaster-recovery


{prod} Operator can create backups of {prod-short} instances and restore them from a backup snapshot if needed. The following chapter describes ways of preparing such backups and their use in the follow-up recovery phase:
{prod-short} Operator can create backups of {prod-short} instances and restore them from a backup snapshot if needed. The following chapter describes ways of preparing such backups and their use in the follow-up recovery phase:

* xref:managing-backups-using-cli.adoc[]
* xref:managing-backups-using-custom-resources.adoc[]
Expand All @@ -21,11 +21,12 @@
* Backup snapshots are bound to their own specific cluster and must be used only there.
====

{prod} Operator creates a new backup on every {prod-short} update.
If a backup server is xref:define-backup-server-for-operator.adoc[configured], then it is used to store the backup.
If no backup server configured, then internal backup server is used.
If there is more than one backup server configured, the server with `che.eclipse.org/backup-before-update: true` annotation is used.
If none have the annotation, then internal backup server is used.
* {prod-short} Operator creates a new backup on every {prod-short} update.
* xref:define-backup-server-for-operator.adoc[Configured] backup server is automatically used to store the backup.
* When a {prod-short} administrator configures more than one backup server, the {prod-short} Operator uses the server with the `che.eclipse.org/backup-before-update: true` annotation by default.
* {prod-short} Operator uses the internal backup server:
** Every time the {prod-short} administrator does not configure the backup server.
** When several backup servers do not have any annotation.

.Additional resources

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
= Managing backups using {prod-cli}


The following section describes how to create backups of {prod-short} installation and do recovery using {prod-cli}.
The following section describes how to create and use backups of a {prod-short} installation to perform a recovery or a rollback to a previous version using `{prod-cli}`.

.Prerequisites

Expand All @@ -20,55 +20,59 @@ include::partial$snip_internal-backup-server-warning.adoc[]
[id="cli-creating-a-new-backup"]
== Creating a new backup

. Create a backup and send it to the pre-configured backup server:
. To create a backup snapshot and send it to a pre-configured backup server:
+
[source,shell,subs="+quotes,+attributes"]
----
$ {prod-cli} server:backup --repository-url=__<repository-url>__ --repository-password=__<repository-password>__
$ {prod-cli} server:backup --repository-url=__<repository-url>__ --repository-password=__<repository-password>__
----
+
* You can create other backups to the same backup server using the `server:backup` command with no arguments.
* Using the `server:backup` command with no arguments for the first time will configure and use an internal backup server.

* It is possible to create other backups to the same backup server using the `server:backup` command with no arguments.
* After using the `server:backup` command with no arguments for the first time on installation of {prod-short}, an internal backup server is configured and used.


[id="cli-restoring-from-backup"]
== Restoring from a backup

. Recover to the previous state of {prod-short}:
A {prod-short} admin can use an existing snapshot of a particular {prod-short} version to restore a desired state or version. The following instructions describe several variations of the restoration command. Adjust the command arguments according to your use case.

* To restore the previous functional state of the same version of {prod-short}:
+
[source,shell,subs="+quotes,+attributes"]
----
$ {prod-cli} server:restore --repository-url=__<repository-url>__ --repository-password=__<repository-password>__ --snapshot-id=__<snapshot-id>__
----

. Recover to different than exiting version of {prod-short}:

* To roll back to a version different from the current version of {prod-short}:
+
[source,shell,subs="+quotes,+attributes"]
----
$ {prod-cli} server:restore --version=__<version>__ --snapshot-id=__<snapshot-id>__
----
$ {prod-cli} server:restore --version=__<version>__ --snapshot-id=__<snapshot-id>__ --repository-url=__<repository-url>__ --repository-password=__<repository-password>__
---
+
This performs a version rollback and restores a snapshot made from a previous version of {prod-short}. The provided snapshot must be created from the version of {prod-short} to which you want to roll back.
+
[NOTE]
====
Provided snapshot must be created from the version of {prod-short} to which recover is requested.
====
NOTE: If you have a dedicated backup repository for each {prod-short} version and want to use the most recent backup for the version, you can provide the `latest` argument as a snapshot ID. By doing so, the `latest` argument will be converted to the latest known ID in the given repository, which will be then used by the {prod-short} Operator to recover.

* If you have a dedicated backup repository for each {prod-short} version and want to use the most recent backup for the version,
you may provide `latest` as snapshot ID and it will be converted to the latest ID in the given repository.

. Recover to the state described by an existing backup Custom Resource object:
* To restore a state described by an existing backup Custom Resource:
+
[source,shell,subs="+quotes,+attributes"]
----
$ {prod-cli} server:restore --backup-cr-name=__<CheClusterBackupCRName>__
----

. Recover to the previous version after update:
+
{prod} automatically creates a backup when upgrading to a newer version.
To return to the previous installed version run:

* To roll back a version upgrade of {prod-short}:
+
[source,shell,subs="+quotes,+attributes"]
----
$ {prod-cli} server:restore --rollback
----
+
This recovers the version that {prod-short} was using before upgrading to a later version.
+
NOTE: {prod-short} Operator automatically creates a backup before every upgrade.

Original file line number Diff line number Diff line change
Expand Up @@ -67,10 +67,10 @@ spec:

[NOTE]
====
It is impossible to recover to a different version of {prod-short} using this approach.
To do it, use `{prod-cli}` (see xref:managing-backups-using-cli.adoc#cli-restoring-from-backup[here]).
The approach described in this chapter can not be used to recover to a different version of {prod-short}. To recover {prod-short} to another version, use the `{prod-cli}` tool. See the xref:managing-backups-using-cli.adoc#cli-restoring-from-backup[] chapter for more information.
====


. Create a new object of `CheClusterRestore` to recover a {prod-short} installation from a backup:
+
[source,yaml,subs="+attributes"]
Expand Down