Skip to content

Ensure there is no confusion about the scope of rancher-backup #1701

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

philippebi
Copy link

Add a note to the documentation to ensure there is no confusion about the scope of the rancher-backup application.

Copy link
Contributor

@LucasSaintarbor LucasSaintarbor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@philippebi Made a small suggestion. May you add this note to versioned_docs/version-2.11/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/backup-restore-and-disaster-recovery.md and any other versions prior to v2.11 if needed?

@@ -13,6 +13,11 @@ The `rancher-backup` operator is used to backup and restore Rancher on any Kuber

The backup-restore operator needs to be installed in the local cluster, and only backs up the Rancher app. The backup and restore operations are performed only in the local Kubernetes cluster.

:::note

`rancher-backup` handles the backup and restore of Rancher's core components only. It does not include applications deployed from the local cluster repositories, such as `rancher-monitoring` or `rancher-logging`, in the backup process. To back up these applications, consider using third-party tools or manually exporting and redeploying Helm charts and custom resources.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
`rancher-backup` handles the backup and restore of Rancher's core components only. It does not include applications deployed from the local cluster repositories, such as `rancher-monitoring` or `rancher-logging`, in the backup process. To back up these applications, consider using third-party tools or manually exporting and redeploying Helm charts and custom resources.
`rancher-backup` only handles backing up and restoring Rancher's core components. It does not back up applications deployed from the local cluster repositories, such as `rancher-monitoring` or `rancher-logging`. To back up these applications, consider using third-party tools or manually exporting and redeploying Helm charts and custom resources.

@philippebi
Copy link
Author

I recently discovered that the situation is a bit more complex than I initially thought, and my previous examples may not have been the best, as some components of rancher-monitoring and rancher-logging, such as secrets, namespaces, service accounts, roles, and role bindings, are indeed backed up. However, these two applications are not fully restored automatically, and their Helm charts need to be manually reinstalled after the restore process.

I would add this line to clarify this:

rancher-backup only handles backing up and restoring Rancher's core components. It does not back up applications deployed from the local cluster repositories. To back up these applications, consider using third-party tools or manually exporting and redeploying Helm charts and custom resources.

In the case of rancher-monitoring and rancher-logging, although their Helm charts must be manually reinstalled, their Kubernetes resources (e.g., namespaces, secrets, service accounts, roles, and role bindings) are part of the Rancher backup. It is necessary to ensure that both charts are working exactly as they did prior to the backup once reinstalled.

What do you think about it ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants