public/rancher-docs
1
0
Fork 0
mirror of https://github.com/rancher/rancher-docs.git synced 2026-09-21 18:51:17 +00:00
Code Issues Packages Projects Releases Wiki Activity

#790 highlight alert about folders for s3 backup config (#821)

Browse Source 
* note added & revised wording on section about s3 backups

* added warning to backup-configuration.md

* Apply suggestions from code review

Co-authored-by: Sunil Singh <sunil.singh@suse.com>

---------

Co-authored-by: Sunil Singh <sunil.singh@suse.com>
This commit is contained in:
Marty Hernandez Avedon
2023-09-07 17:00:00 -04:00
committed by GitHub
co-authored by Sunil Singh
parent 02912f266c
commit f308f802e1
2 changed files with 16 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher-launched-kubernetes-clusters.md
+10 -2
View File
@@ -260,11 +260,19 @@ By default, the `local` backup target is selected. The benefits of this option i
### S3 Backup Target
The `S3` backup target allows users to configure a S3 compatible backend to store the snapshots. The primary benefit of this option is that if the cluster loses all the etcd nodes, the cluster can still be restored as the snapshots are stored externally. Rancher recommends external targets like `S3` backup, however its configuration requirements do require additional effort that should be considered. Additionally, it is recommended to ensure that every cluster has a unique bucket and/or folder, as Rancher will populate snapshot information for any available snapshot that is listed in the S3 bucket/folder that is configured for the cluster.
We recommend that you use the `S3` backup target. It lets you store snapshots externally, on an S3 compatible backend. Since the snapshots aren't stored locally, you can still restore the cluster even if you lose all etcd nodes.
Although the `S3` target offers advantages over local backup, it does require extra configuration.
:::caution
If you use an S3 backup target, make sure that every cluster has its own bucket or folder. Rancher populates snapshot information from any available snapshot listed in the S3 bucket or folder configured for that cluster.
:::
| Option | Description | Required|
|---|---|---|
|S3 Bucket Name| S3 bucket name where backups will be stored| *|
|S3 Bucket Name| Name of S3 bucket to store backups| *|
|S3 Region|S3 region for the backup bucket| |
|S3 Region Endpoint|S3 regions endpoint for the backup bucket|* |
|S3 Access Key|S3 access key with permission to access the backup bucket|*|
docs/reference-guides/backup-restore-configuration/backup-configuration.md
+6
View File
@@ -68,6 +68,12 @@ Selecting the first option stores this backup in the storage location configured
### S3
:::caution
If you use an S3 backup target, make sure that every cluster has its own bucket or folder. Rancher populates snapshot information from any available snapshot listed in the S3 bucket or folder configured for that cluster.
:::
The S3 storage location contains the following configuration fields:
1. **Credential Secret** (optional): If you need to use the AWS Access keys Secret keys to access s3 bucket, create a secret with your credentials with keys and the directives `accessKey` and `secretKey`. It can be in any namespace. An example secret is [here.](#example-credentialsecret) This directive is unnecessary if the nodes running your operator are in EC2 and set up with IAM permissions that allow them to access S3, as described in [this section.](#iam-permissions-for-ec2-nodes-to-access-s3) The Credential Secret dropdown lists the secrets in all namespaces.