rancher
/
fleet-docs
mirror of https://github.com/rancher/fleet-docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add info about restoring backups to GitRepo how-to (#295) 

* Add info about restoring backups to GitRepo how-to

This provides a few bits of advice about steps to take before restoring
a multi-cluster setup with Fleet workloads.

* Fix broken anchor on bundle resources

The top of the page does not need any anchor.

* Propagate doc to version 0.13

A new version has been created, and needs this documented as well.

---------

Co-authored-by: Olivier Vernin <olivier@vernin.me>
This commit is contained in:
Corentin Néau 2025-08-07 22:59:21 +02:00 committed by GitHub
parent 806caa66fa
commit 85d69c962d
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
5 changed files with 138 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
docs/gitrepo-add.md
View File

@ -304,6 +304,34 @@ When using Kubernetes [encryption at rest](https://kubernetes.io/docs/tasks/admi
- contents.fleet.cattle.io
```
## Backing up and restoring
When backing up and restoring Fleet with existing workloads, be they GitRepos or HelmOps, a few points must be taken
into account.
### Kubernetes API server availability
A Fleet agent, living in a downstream cluster, monitors a cluster-specific namespace on the upstream cluster.
This means that, when a restore operation is in progress, changes made in the upstream cluster may affect deployments
running in downstream clusters, which would then be updated or deleted based on incomplete state coming from the
upstream cluster.
To prevent this, we recommend making the Kubernetes API server inaccessible to downstream clusters while a restore
operation is running on the upstream cluster. Agents should not have access to the upstream cluster until all resources
have been re-created.
### Pausing
A [paused](./ref-gitrepo) GitRepo will lead to paused bundles and bundle deployments. This means that:
* when deleting a bundle deployment coming from a paused GitRepo, Fleet will not re-create that bundle deployment until
the GitRepo is unpaused
* when deleting a bundle coming from a paused GitRepo, Fleet will delete the bundle deployments coming from that bundle,
and will not re-create the bundle (nor the bundle-deployments) until the GitRepo is unpaused.
Besides, pausing a GitRepo only prevents bundles and bundle deployments from being created or updated for that GitRepo.
In other words, it only affects _controller_ operations, not Fleet _agent_ operations. To prevent user resources,
contained in a bundle, from being deleted when deleting a bundle deployment,
[keepResources](./ref-bundle) should be used instead.
# Troubleshooting

28
versioned_docs/version-0.10/gitrepo-add.md
View File

@ -217,7 +217,35 @@ In the previous example credentials for username `user` will be used for the pat
:::note
If you are using ["rancher-backups"](https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher) and want this secret to be included the backup, please add the label `resources.cattle.io/backup: true` to the secret. In that case, make sure to encrypt the backup to protect sensitive credentials.
:::
## Backing up and restoring
When backing up and restoring Fleet with existing workloads, a few points must be taken into account.
### Kubernetes API server availability
A Fleet agent, living in a downstream cluster, monitors a cluster-specific namespace on the upstream cluster.
This means that, when a restore operation is in progress, changes made in the upstream cluster may affect deployments
running in downstream clusters, which would then be updated or deleted based on incomplete state coming from the
upstream cluster.
To prevent this, we recommend making the Kubernetes API server inaccessible to downstream clusters while a restore
operation is running on the upstream cluster. Agents should not have access to the upstream cluster until all resources
have been re-created.
### Pausing
A [paused](./ref-gitrepo) GitRepo will lead to paused bundles and bundle deployments. This means that:
* when deleting a bundle deployment coming from a paused GitRepo, Fleet will not re-create that bundle deployment until
the GitRepo is unpaused
* when deleting a bundle coming from a paused GitRepo, Fleet will delete the bundle deployments coming from that bundle,
and will not re-create the bundle (nor the bundle-deployments) until the GitRepo is unpaused.
Besides, pausing a GitRepo only prevents bundles and bundle deployments from being created or updated for that GitRepo.
In other words, it only affects _controller_ operations, not Fleet _agent_ operations. To prevent user resources,
contained in a bundle, from being deleted when deleting a bundle deployment,
[keepResources](./ref-bundle) should be used instead.
# Troubleshooting

27
versioned_docs/version-0.11/gitrepo-add.md
View File

@ -236,6 +236,33 @@ When using Kubernetes [encryption at rest](https://kubernetes.io/docs/tasks/admi
- contents.fleet.cattle.io
```
## Backing up and restoring
When backing up and restoring Fleet with existing workloads, a few points must be taken into account.
### Kubernetes API server availability
A Fleet agent, living in a downstream cluster, monitors a cluster-specific namespace on the upstream cluster.
This means that, when a restore operation is in progress, changes made in the upstream cluster may affect deployments
running in downstream clusters, which would then be updated or deleted based on incomplete state coming from the
upstream cluster.
To prevent this, we recommend making the Kubernetes API server inaccessible to downstream clusters while a restore
operation is running on the upstream cluster. Agents should not have access to the upstream cluster until all resources
have been re-created.
### Pausing
A [paused](./ref-gitrepo) GitRepo will lead to paused bundles and bundle deployments. This means that:
* when deleting a bundle deployment coming from a paused GitRepo, Fleet will not re-create that bundle deployment until
the GitRepo is unpaused
* when deleting a bundle coming from a paused GitRepo, Fleet will delete the bundle deployments coming from that bundle,
and will not re-create the bundle (nor the bundle-deployments) until the GitRepo is unpaused.
Besides, pausing a GitRepo only prevents bundles and bundle deployments from being created or updated for that GitRepo.
In other words, it only affects _controller_ operations, not Fleet _agent_ operations. To prevent user resources,
contained in a bundle, from being deleted when deleting a bundle deployment,
[keepResources](./ref-bundle) should be used instead.
# Troubleshooting

27
versioned_docs/version-0.12/gitrepo-add.md
View File

@ -258,6 +258,33 @@ When using Kubernetes [encryption at rest](https://kubernetes.io/docs/tasks/admi
- contents.fleet.cattle.io
```
## Backing up and restoring
When backing up and restoring Fleet with existing workloads, a few points must be taken into account.
### Kubernetes API server availability
A Fleet agent, living in a downstream cluster, monitors a cluster-specific namespace on the upstream cluster.
This means that, when a restore operation is in progress, changes made in the upstream cluster may affect deployments
running in downstream clusters, which would then be updated or deleted based on incomplete state coming from the
upstream cluster.
To prevent this, we recommend making the Kubernetes API server inaccessible to downstream clusters while a restore
operation is running on the upstream cluster. Agents should not have access to the upstream cluster until all resources
have been re-created.
### Pausing
A [paused](./ref-gitrepo) GitRepo will lead to paused bundles and bundle deployments. This means that:
* when deleting a bundle deployment coming from a paused GitRepo, Fleet will not re-create that bundle deployment until
the GitRepo is unpaused
* when deleting a bundle coming from a paused GitRepo, Fleet will delete the bundle deployments coming from that bundle,
and will not re-create the bundle (nor the bundle-deployments) until the GitRepo is unpaused.
Besides, pausing a GitRepo only prevents bundles and bundle deployments from being created or updated for that GitRepo.
In other words, it only affects _controller_ operations, not Fleet _agent_ operations. To prevent user resources,
contained in a bundle, from being deleted when deleting a bundle deployment,
[keepResources](./ref-bundle) should be used instead.
# Troubleshooting

28
versioned_docs/version-0.13/gitrepo-add.md
View File

@ -304,6 +304,34 @@ When using Kubernetes [encryption at rest](https://kubernetes.io/docs/tasks/admi
- contents.fleet.cattle.io
```
## Backing up and restoring
When backing up and restoring Fleet with existing workloads, be they GitRepos or HelmOps, a few points must be taken
into account.
### Kubernetes API server availability
A Fleet agent, living in a downstream cluster, monitors a cluster-specific namespace on the upstream cluster.
This means that, when a restore operation is in progress, changes made in the upstream cluster may affect deployments
running in downstream clusters, which would then be updated or deleted based on incomplete state coming from the
upstream cluster.
To prevent this, we recommend making the Kubernetes API server inaccessible to downstream clusters while a restore
operation is running on the upstream cluster. Agents should not have access to the upstream cluster until all resources
have been re-created.
### Pausing
A [paused](./ref-gitrepo) GitRepo will lead to paused bundles and bundle deployments. This means that:
* when deleting a bundle deployment coming from a paused GitRepo, Fleet will not re-create that bundle deployment until
the GitRepo is unpaused
* when deleting a bundle coming from a paused GitRepo, Fleet will delete the bundle deployments coming from that bundle,
and will not re-create the bundle (nor the bundle-deployments) until the GitRepo is unpaused.
Besides, pausing a GitRepo only prevents bundles and bundle deployments from being created or updated for that GitRepo.
In other words, it only affects _controller_ operations, not Fleet _agent_ operations. To prevent user resources,
contained in a bundle, from being deleted when deleting a bundle deployment,
[keepResources](./ref-bundle) should be used instead.
# Troubleshooting