Update downstream cluster backup section

This commit is contained in:
Catherine Luse
2020-03-25 03:43:31 -07:00
parent 302b3ee918
commit dd42046c80
3 changed files with 47 additions and 19 deletions
+1 -3
View File
@@ -5,7 +5,6 @@ weight: 1000
This section is devoted to protecting your data in a disaster scenario.
To protect yourself from a disaster scenario, you should create backups on a regular basis.
- Rancher server backups:
@@ -14,8 +13,7 @@ To protect yourself from a disaster scenario, you should create backups on a reg
- Rancher installed with Docker
- [Backing up Rancher Launched Kubernetes Clusters]({{<baseurl>}}/rancher/v2.x/en/cluster-admin/backing-up-etcd/)
In a disaster scenario, you can restore your `etcd` database by restoring a backup.
- [Rancher Server Restorations]({{<baseurl>}}/rancher/v2.x/en/backups/restorations)
- [Restoring Rancher Launched Kubernetes Clusters]({{<baseurl>}}/rancher/v2.x/en/cluster-admin/restoring-etcd/)
- [Restoring Rancher Launched Kubernetes Clusters]({{<baseurl>}}/rancher/v2.x/en/cluster-admin/restoring-etcd/)
@@ -1,15 +1,40 @@
---
title: Backing up etcd
title: Backing up Cluster Data
weight: 2045
---
_Available as of v2.2.0_
In the Rancher UI, etcd backup and recovery for [Rancher launched Kubernetes clusters]({{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) can be easily performed. Snapshots of the etcd database are taken and saved either [locally onto the etcd nodes](#local-backup-target) or to a [S3 compatible target](#s3-backup-target). The advantages of configuring S3 is that if all etcd nodes are lost, your snapshot is saved remotely and can be used to restore the cluster.
In the Rancher UI, etcd backup and recovery for [Rancher launched Kubernetes clusters]({{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) can be easily performed.
Rancher recommends configuring recurrent `etcd` snapshots for all production clusters. Additionally, one-time snapshots can easily be taken as well.
>**Note:** If you have any Rancher launched Kubernetes clusters that were created prior to v2.2.0, after upgrading Rancher, you must [edit the cluster]({{<baseurl>}}/rancher/v2.x/en/cluster-admin/editing-clusters/) and _save_ it, in order to enable the updated snapshot features. Even if you were already creating snapshots prior to v2.2.0, you must do this step as the older snapshots will not be available to use to [back up and restore etcd through the UI]({{<baseurl>}}/rancher/v2.x/en/cluster-admin/restoring-etcd/).
Snapshots of the etcd database are taken and saved either [locally onto the etcd nodes](#local-backup-target) or to a [S3 compatible target](#s3-backup-target). The advantages of configuring S3 is that if all etcd nodes are lost, your snapshot is saved remotely and can be used to restore the cluster.
This section covers the following topics:
- [How snapshots work](#how-snapshots-work)
- [Snapshot creation period and retention count](#snapshot-creation-period-and-retention-count)
- [Configuring recurring snapshots for the cluster](#configuring-recurring-snapshots-for-the-cluster)
- [One-time snapshots](#one-time-snapshots)
- [Snapshot backup targets](#snapshot-backup-targets)
- [Local backup target](#local-backup-target)
- [S3 backup target](#s3-backup-target)
- [Using a custom CA certificate for S3](#using-a-custom-ca-certificate-for-s3)
- [IAM Support for storing snapshots in S3](#iam-support-for-storing-snapshots-in-s3)
- [Safe timestamps](#safe-timestamps)
- [Enabling snapshot features for clusters created before Rancher v2.2.0](#enabling-snapshot-features-for-clusters-created-before-Rancher-v2-2-0)
# How Snapshots Work
{{% tabs %}}
{{% tab "Rancher v2.4.0+" %}}
{{% /tab %}}
{{% tab "Rancher prior to v2.4.0" %}}
When Rancher creates a snapshot, only the etcd data is included in the snapshot.
{{% /tab %}}
{{% /tabs %}}
# Snapshot Creation Period and Retention Count
@@ -30,7 +55,7 @@ In the **Advanced Cluster Options** section, there are several options available
|[Recurring etcd Snapshot Creation Period](#snapshot-creation-period-and-retention-count) | Time in hours between recurring snapshots| 12 hours |
|[Recurring etcd Snapshot Retention Count](#snapshot-creation-period-and-retention-count)| Number of snapshots to retain| 6 |
### One-Time Snapshots
# One-Time Snapshots
In addition to recurring snapshots, you may want to take a "one-time" snapshot. For example, before upgrading the Kubernetes version of a cluster it's best to backup the state of the cluster to protect against upgrade failure.
@@ -51,14 +76,6 @@ Rancher supports two different backup targets:
By default, the `local` backup target is selected. The benefits of this option is that there is no external configuration. Snapshots are automatically saved locally to the etcd nodes in the [Rancher launched Kubernetes clusters]({{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) in `/opt/rke/etcd-snapshots`. All recurring snapshots are taken at configured intervals. The downside of using the `local` backup target is that if there is a total disaster and _all_ etcd nodes are lost, there is no ability to restore the cluster.
#### Safe Timestamps
_Available as of v2.3.0_
As of v2.2.6, snapshot files are timestamped to simplify processing the files using external tools and scripts, but in some S3 compatible backends, these timestamps were unusable. As of Rancher v2.3.0, the option `safe_timestamp` is added to support compatible file names. When this flag is set to `true`, all special characters in the snapshot filename timestamp are replaced.
>>**Note:** This option is not available directly in the UI, and is only available through the `Edit as Yaml` interface.
### 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.
@@ -72,13 +89,14 @@ The `S3` backup target allows users to configure a S3 compatible backend to stor
|S3 Secret Key|S3 secret key with permission to access the backup bucket|*|
| Custom CA Certificate | A custom certificate used to access private S3 backends _Available as of v2.2.5_ ||
#### Using a custom CA certificate for S3
### Using a custom CA certificate for S3
_Available as of v2.2.5_
The backup snapshot can be stored on a custom `S3` backup like [minio](https://min.io/). If the S3 back end uses a self-signed or custom certificate, provide a custom certificate using the `Custom CA Certificate` option to connect to the S3 backend.
# IAM Support for Storing Snapshots in S3
### IAM Support for Storing Snapshots in S3
The `S3` backup target supports using IAM authentication to AWS API in addition to using API credentials. An IAM role gives temporary permissions that an application can use when making API calls to S3 storage. To use IAM authentication, the following requirements must be met:
- The cluster etcd nodes must have an instance role that has read/write access to the designated backup bucket.
@@ -90,8 +108,20 @@ The `S3` backup target supports using IAM authentication to AWS API in addition
# Viewing Available Snapshots
The list of all available snapshots for the cluster is available.
The list of all available snapshots for the cluster is available in the Rancher UI.
1. In the **Global** view, navigate to the cluster that you want to view snapshots.
2. Click **Tools > Snapshots** from the navigation bar to view the list of saved snapshots. These snapshots include a timestamp of when they were created.
# Safe Timestamps
_Available as of v2.3.0_
As of v2.2.6, snapshot files are timestamped to simplify processing the files using external tools and scripts, but in some S3 compatible backends, these timestamps were unusable. As of Rancher v2.3.0, the option `safe_timestamp` is added to support compatible file names. When this flag is set to `true`, all special characters in the snapshot filename timestamp are replaced.
>>**Note:** This option is not available directly in the UI, and is only available through the `Edit as Yaml` interface.
# Enabling Snapshot Features for Clusters Created Before Rancher v2.2.0
If you have any Rancher launched Kubernetes clusters that were created prior to v2.2.0, after upgrading Rancher, you must [edit the cluster]({{<baseurl>}}/rancher/v2.x/en/cluster-admin/editing-clusters/) and _save_ it, in order to enable the updated snapshot features. Even if you were already creating snapshots prior to v2.2.0, you must do this step as the older snapshots will not be available to use to [back up and restore etcd through the UI]({{<baseurl>}}/rancher/v2.x/en/cluster-admin/restoring-etcd/).
@@ -1,5 +1,5 @@
---
title: Restoring etcd
title: Restoring a Cluster from Backup
weight: 2050
---