mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-11-06 17:05:26 +00:00
Apply Divio and update links
This commit is contained in:
Billy Tat committed
1 parent
94dcf8aa71
commit
331b43a83c
432 files changed
+1995
-1961
No files matched your search
@@ -13,10 +13,10 @@ aliases:
|
||||
This section contains information about how to create backups of your Rancher data and how to restore them in a disaster scenario.
|
||||
|
||||
- Rancher server backups:
|
||||
- [Rancher installed on a K3s Kubernetes cluster](./k3s-backups)
|
||||
- [Rancher installed on an RKE Kubernetes cluster](./rke-backups)
|
||||
- [Rancher installed with Docker](./docker-backups)
|
||||
- [Rancher installed on a K3s Kubernetes cluster](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-k3s-installed-rancher.md)
|
||||
- [Rancher installed on an RKE Kubernetes cluster](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher-launched-kubernetes-clusters.md)
|
||||
- [Rancher installed with Docker](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-docker-installed-rancher.md)
|
||||
|
||||
For information on backing up Rancher launched Kubernetes clusters, refer to [this section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/backing-up-etcd/)
|
||||
For information on backing up Rancher launched Kubernetes clusters, refer to [this section.](../../how-to-guides/advanced-user-guides/manage-clusters/backing-up-etcd.md)
|
||||
|
||||
If you are looking to back up your [Rancher launched Kubernetes cluster]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/), please refer [here]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/backing-up-etcd/).
|
||||
If you are looking to back up your [Rancher launched Kubernetes cluster](../../pages-for-subheaders/launch-kubernetes-with-rancher.md), please refer [here](../../how-to-guides/advanced-user-guides/manage-clusters/backing-up-etcd.md).
|
||||
@@ -1,90 +0,0 @@
|
||||
---
|
||||
title: Backing up Rancher Installed with Docker
|
||||
shortTitle: Docker Installs
|
||||
weight: 3
|
||||
aliases:
|
||||
- /rancher/v2.0-v2.4/en/installation/after-installation/single-node-backup-and-restoration/
|
||||
- /rancher/v2.0-v2.4/en/installation/after-installation/single-node-backup-and-restoration/
|
||||
- /rancher/v2.0-v2.4/en/backups/backups/single-node-backups/
|
||||
- /rancher/v2.0-v2.4/en/backups/legacy/backup/single-node-backups/
|
||||
- /rancher/v2.0-v2.4/en/backups/v2.0.x-v2.4.x/backup/docker-backups
|
||||
- /rancher/v2.0-v2.4/en/installation/backups-and-restoration/single-node-backup-and-restoration/
|
||||
- /rancher/v2.x/en/backups/v2.0.x-v2.4.x/backup/docker-backups/
|
||||
---
|
||||
|
||||
|
||||
After completing your Docker installation of Rancher, we recommend creating backups of it on a regular basis. Having a recent backup will let you recover quickly from an unexpected disaster.
|
||||
|
||||
### How to Read Placeholders
|
||||
|
||||
During the creation of your backup, you'll enter a series of commands, replacing placeholders with data from your environment. These placeholders are denoted with angled brackets and all capital letters (`<EXAMPLE>`). Here's an example of a command with a placeholder:
|
||||
|
||||
```
|
||||
docker run \
|
||||
--volumes-from rancher-data-<DATE> \
|
||||
-v $PWD:/backup busybox tar pzcvf /backup/rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz /var/lib/rancher
|
||||
```
|
||||
|
||||
In this command, `<DATE>` is a placeholder for the date that the data container and backup were created. `9-27-18` for example.
|
||||
|
||||
### Obtaining Placeholder Data
|
||||
|
||||
Get the placeholder data by running:
|
||||
|
||||
```
|
||||
docker ps
|
||||
```
|
||||
|
||||
Write down or copy this information before starting the [procedure below](#creating-a-backup).
|
||||
|
||||
<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code><RANCHER_CONTAINER_TAG></code> and <code><RANCHER_CONTAINER_NAME></code></sup>
|
||||
|
||||
|
||||
|
||||
| Placeholder | Example | Description |
|
||||
| -------------------------- | -------------------------- | --------------------------------------------------------- |
|
||||
| `<RANCHER_CONTAINER_TAG>` | `v2.0.5` | The rancher/rancher image you pulled for initial install. |
|
||||
| `<RANCHER_CONTAINER_NAME>` | `festive_mestorf` | The name of your Rancher container. |
|
||||
| `<RANCHER_VERSION>` | `v2.0.5` | The version of Rancher that you're creating a backup for. |
|
||||
| `<DATE>` | `9-27-18` | The date that the data container or backup was created. |
|
||||
<br/>
|
||||
|
||||
You can obtain `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>` by logging into your Rancher Server by remote connection and entering the command to view the containers that are running: `docker ps`. You can also view containers that are stopped with `docker ps -a`. Use these commands for help anytime while creating backups.
|
||||
|
||||
### Creating a Backup
|
||||
|
||||
This procedure creates a backup that you can restore if Rancher encounters a disaster scenario.
|
||||
|
||||
|
||||
1. Using a remote Terminal connection, log into the node running your Rancher Server.
|
||||
|
||||
1. Stop the container currently running Rancher Server. Replace `<RANCHER_CONTAINER_NAME>` with the [name of your Rancher container](#how-to-read-placeholders).
|
||||
|
||||
```
|
||||
docker stop <RANCHER_CONTAINER_NAME>
|
||||
```
|
||||
1. <a id="backup"></a>Use the command below, replacing each placeholder, to create a data container from the Rancher container that you just stopped.
|
||||
|
||||
```
|
||||
docker create --volumes-from <RANCHER_CONTAINER_NAME> --name rancher-data-<DATE> rancher/rancher:<RANCHER_CONTAINER_TAG>
|
||||
```
|
||||
|
||||
1. <a id="tarball"></a>From the data container that you just created (<code>rancher-data-<DATE></code>), create a backup tarball (<code>rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz</code>). Use the following command, replacing each placeholder.
|
||||
|
||||
```
|
||||
docker run --volumes-from rancher-data-<DATE> -v $PWD:/backup:z busybox tar pzcvf /backup/rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz /var/lib/rancher
|
||||
```
|
||||
|
||||
**Step Result:** A stream of commands runs on the screen.
|
||||
|
||||
1. Enter the `ls` command to confirm that the backup tarball was created. It will have a name similar to `rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz`.
|
||||
|
||||
1. Move your backup tarball to a safe location external to your Rancher Server. Then delete the `rancher-data-<DATE>` container from your Rancher Server.
|
||||
|
||||
1. Restart Rancher Server. Replace `<RANCHER_CONTAINER_NAME>` with the name of your Rancher container.
|
||||
|
||||
```
|
||||
docker start <RANCHER_CONTAINER_NAME>
|
||||
```
|
||||
|
||||
**Result:** A backup tarball of your Rancher Server data is created. See [Restoring Backups: Docker Installs]({{<baseurl>}}/rancher/v2.0-v2.4/en/backups/restorations/single-node-restoration) if you need to restore backup data.
|
||||
@@ -1,34 +0,0 @@
|
||||
---
|
||||
title: Backing up Rancher Installed on a K3s Kubernetes Cluster
|
||||
shortTitle: K3s Installs
|
||||
weight: 1
|
||||
aliases:
|
||||
- /rancher/v2.0-v2.4/en/backups/backups/k3s-backups
|
||||
- /rancher/v2.0-v2.4/en/backups/backups/k8s-backups/k3s-backups
|
||||
- /rancher/v2.0-v2.4/en/backups/legacy/backup/k8s-backups/k3s-backups/
|
||||
- /rancher/v2.0-v2.4/en/backups/legacy/backups/k3s-backups
|
||||
- /rancher/v2.0-v2.4/en/backups/legacy/backup/k3s-backups
|
||||
- /rancher/v2.0-v2.4/en/backups/v2.0.x-v2.4.x/backup/k3s-backups
|
||||
- /rancher/v2.x/en/backups/v2.0.x-v2.4.x/backup/k3s-backups/
|
||||
---
|
||||
|
||||
When Rancher is installed on a high-availability Kubernetes cluster, we recommend using an external database to store the cluster data.
|
||||
|
||||
The database administrator will need to back up the external database, or restore it from a snapshot or dump.
|
||||
|
||||
We recommend configuring the database to take recurring snapshots.
|
||||
|
||||
### K3s Kubernetes Cluster Data
|
||||
|
||||
One main advantage of this K3s architecture is that it allows an external datastore to hold the cluster data, allowing the K3s server nodes to be treated as ephemeral.
|
||||
|
||||
<figcaption>Architecture of a K3s Kubernetes Cluster Running the Rancher Management Server</figcaption>
|
||||
|
||||
|
||||
### Creating Snapshots and Restoring Databases from Snapshots
|
||||
|
||||
For details on taking database snapshots and restoring your database from them, refer to the official database documentation:
|
||||
|
||||
- [Official MySQL documentation](https://dev.mysql.com/doc/refman/8.0/en/replication-snapshot-method.html)
|
||||
- [Official PostgreSQL documentation](https://www.postgresql.org/docs/8.3/backup-dump.html)
|
||||
- [Official etcd documentation](https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/recovery.md)
|
||||
@@ -1,188 +0,0 @@
|
||||
---
|
||||
title: Backing up Rancher Installed on an RKE Kubernetes Cluster
|
||||
shortTitle: RKE Installs
|
||||
weight: 2
|
||||
aliases:
|
||||
- /rancher/v2.0-v2.4/en/installation/after-installation/k8s-install-backup-and-restoration/
|
||||
- /rancher/v2.0-v2.4/en/installation/backups-and-restoration/ha-backup-and-restoration/
|
||||
- /rancher/v2.0-v2.4/en/backups/backups/ha-backups
|
||||
- /rancher/v2.0-v2.4/en/backups/backups/k8s-backups/ha-backups
|
||||
- /rancher/v2.0-v2.4/en/backups/legacy/backup/k8s-backups/ha-backups/
|
||||
- /rancher/v2.0-v2.4/en/backups/legacy/backups/ha-backups
|
||||
- /rancher/v2.0-v2.4/en/backups/legacy/backup/ha-backups
|
||||
- /rancher/v2.0-v2.4/en/backups/v2.0.x-v2.4.x/backup/rke-backups
|
||||
- /rancher/v2.x/en/backups/v2.0.x-v2.4.x/backup/rke-backups/
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
This section describes how to create backups of your high-availability Rancher install.
|
||||
|
||||
In an RKE installation, the cluster data is replicated on each of three etcd nodes in the cluster, providing redundancy and data duplication in case one of the nodes fails.
|
||||
|
||||
<figcaption>Cluster Data within an RKE Kubernetes Cluster Running the Rancher Management Server</figcaption>
|
||||
|
||||
|
||||
# Requirements
|
||||
|
||||
### RKE Version
|
||||
|
||||
The commands for taking `etcd` snapshots are only available in RKE v0.1.7 and later.
|
||||
|
||||
### RKE Config File
|
||||
|
||||
You'll need the RKE config file that you used for Rancher install, `rancher-cluster.yml`. You created this file during your initial install. Place this file in same directory as the RKE binary.
|
||||
|
||||
|
||||
# Backup Outline
|
||||
|
||||
|
||||
Backing up your high-availability Rancher cluster is process that involves completing multiple tasks.
|
||||
|
||||
1. [Take Snapshots of the `etcd` Database](#1-take-snapshots-of-the-etcd-database)
|
||||
|
||||
Take snapshots of your current `etcd` database using Rancher Kubernetes Engine (RKE).
|
||||
|
||||
1. [Store Snapshot(s) Externally](#2-back-up-local-snapshots-to-a-safe-location)
|
||||
|
||||
After taking your snapshots, export them to a safe location that won't be affected if your cluster encounters issues.
|
||||
|
||||
|
||||
# 1. Take Snapshots of the `etcd` Database
|
||||
|
||||
Take snapshots of your `etcd` database. You can use these snapshots later to recover from a disaster scenario. There are two ways to take snapshots: recurringly, or as a one-off. Each option is better suited to a specific use case. Read the short description below each link to know when to use each option.
|
||||
|
||||
- [Option A: Recurring Snapshots](#option-a-recurring-snapshots)
|
||||
|
||||
After you stand up a high-availability Rancher install, we recommend configuring RKE to automatically take recurring snapshots so that you always have a safe restore point available.
|
||||
|
||||
- [Option B: One-Time Snapshots](#option-b-one-time-snapshots)
|
||||
|
||||
We advise taking one-time snapshots before events like upgrades or restore of another snapshot.
|
||||
|
||||
### Option A: Recurring Snapshots
|
||||
|
||||
For all high-availability Rancher installs, we recommend taking recurring snapshots so that you always have a safe restore point available.
|
||||
|
||||
To take recurring snapshots, enable the `etcd-snapshot` service, which is a service that's included with RKE. This service runs in a service container alongside the `etcd` container. You can enable this service by adding some code to `rancher-cluster.yml`.
|
||||
|
||||
**To Enable Recurring Snapshots:**
|
||||
|
||||
The steps to enable recurring snapshots differ based on the version of RKE.
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="RKE v0.2.0+">
|
||||
|
||||
1. Open `rancher-cluster.yml` with your favorite text editor.
|
||||
2. Edit the code for the `etcd` service to enable recurring snapshots. Snapshots can be saved in a S3 compatible backend.
|
||||
|
||||
```
|
||||
services:
|
||||
etcd:
|
||||
backup_config:
|
||||
enabled: true # enables recurring etcd snapshots
|
||||
interval_hours: 6 # time increment between snapshots
|
||||
retention: 60 # time in days before snapshot purge
|
||||
# Optional S3
|
||||
s3backupconfig:
|
||||
access_key: "myaccesskey"
|
||||
secret_key: "myaccesssecret"
|
||||
bucket_name: "my-backup-bucket"
|
||||
folder: "folder-name" # Available as of v2.3.0
|
||||
endpoint: "s3.eu-west-1.amazonaws.com"
|
||||
region: "eu-west-1"
|
||||
custom_ca: |-
|
||||
-----BEGIN CERTIFICATE-----
|
||||
$CERTIFICATE
|
||||
-----END CERTIFICATE-----
|
||||
```
|
||||
4. Save and close `rancher-cluster.yml`.
|
||||
5. Open **Terminal** and change directory to the location of the RKE binary. Your `rancher-cluster.yml` file must reside in the same directory.
|
||||
6. Run the following command:
|
||||
```
|
||||
rke up --config rancher-cluster.yml
|
||||
```
|
||||
|
||||
**Result:** RKE is configured to take recurring snapshots of `etcd` on all nodes running the `etcd` role. Snapshots are saved locally to the following directory: `/opt/rke/etcd-snapshots/`. If configured, the snapshots are also uploaded to your S3 compatible backend.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE v0.1.x">
|
||||
|
||||
1. Open `rancher-cluster.yml` with your favorite text editor.
|
||||
2. Edit the code for the `etcd` service to enable recurring snapshots.
|
||||
|
||||
```
|
||||
services:
|
||||
etcd:
|
||||
snapshot: true # enables recurring etcd snapshots
|
||||
creation: 6h0s # time increment between snapshots
|
||||
retention: 24h # time increment before snapshot purge
|
||||
```
|
||||
4. Save and close `rancher-cluster.yml`.
|
||||
5. Open **Terminal** and change directory to the location of the RKE binary. Your `rancher-cluster.yml` file must reside in the same directory.
|
||||
6. Run the following command:
|
||||
```
|
||||
rke up --config rancher-cluster.yml
|
||||
```
|
||||
|
||||
**Result:** RKE is configured to take recurring snapshots of `etcd` on all nodes running the `etcd` role. Snapshots are saved locally to the following directory: `/opt/rke/etcd-snapshots/`.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
### Option B: One-Time Snapshots
|
||||
|
||||
When you're about to upgrade Rancher or restore it to a previous snapshot, you should snapshot your live image so that you have a backup of `etcd` in its last known state.
|
||||
|
||||
**To Take a One-Time Local Snapshot:**
|
||||
|
||||
1. Open **Terminal** and change directory to the location of the RKE binary. Your `rancher-cluster.yml` file must reside in the same directory.
|
||||
|
||||
2. Enter the following command. Replace `<SNAPSHOT.db>` with any name that you want to use for the snapshot (e.g. `upgrade.db`).
|
||||
|
||||
```
|
||||
rke etcd snapshot-save \
|
||||
--name <SNAPSHOT.db> \
|
||||
--config rancher-cluster.yml
|
||||
```
|
||||
|
||||
**Result:** RKE takes a snapshot of `etcd` running on each `etcd` node. The file is saved to `/opt/rke/etcd-snapshots`.
|
||||
|
||||
**To Take a One-Time S3 Snapshot:**
|
||||
|
||||
_Available as of RKE v0.2.0_
|
||||
|
||||
1. Open **Terminal** and change directory to the location of the RKE binary. Your `rancher-cluster.yml` file must reside in the same directory.
|
||||
|
||||
2. Enter the following command. Replace `<SNAPSHOT.db>` with any name that you want to use for the snapshot (e.g. `upgrade.db`).
|
||||
|
||||
```shell
|
||||
rke etcd snapshot-save \
|
||||
--config rancher-cluster.yml \
|
||||
--name snapshot-name \
|
||||
--s3 \
|
||||
--access-key S3_ACCESS_KEY \
|
||||
--secret-key S3_SECRET_KEY \
|
||||
--bucket-name s3-bucket-name \
|
||||
--s3-endpoint s3.amazonaws.com \
|
||||
--folder folder-name # Available as of v2.3.0
|
||||
```
|
||||
|
||||
**Result:** RKE takes a snapshot of `etcd` running on each `etcd` node. The file is saved to `/opt/rke/etcd-snapshots`. It is also uploaded to the S3 compatible backend.
|
||||
|
||||
# 2. Back up Local Snapshots to a Safe Location
|
||||
|
||||
> **Note:** If you are using RKE v0.2.0, you can enable saving the backups to a S3 compatible backend directly and skip this step.
|
||||
|
||||
After taking the `etcd` snapshots, save them to a safe location so that they're unaffected if your cluster experiences a disaster scenario. This location should be persistent.
|
||||
|
||||
In this documentation, as an example, we're using Amazon S3 as our safe location, and [S3cmd](http://s3tools.org/s3cmd) as our tool to create the backups. The backup location and tool that you use are ultimately your decision.
|
||||
|
||||
**Example:**
|
||||
|
||||
```
|
||||
root@node:~# s3cmd mb s3://rke-etcd-snapshots
|
||||
root@node:~# s3cmd put /opt/rke/etcd-snapshots/snapshot.db s3://rke-etcd-snapshots/
|
||||
```
|
||||
@@ -1,12 +0,0 @@
|
||||
---
|
||||
title: Backups and Disaster Recovery
|
||||
weight: 5
|
||||
---
|
||||
|
||||
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.
|
||||
|
||||
- [Backup](./backup)
|
||||
- [Restore](./restore)
|
||||
|
||||
@@ -1,75 +0,0 @@
|
||||
---
|
||||
title: Restoring Backups—Docker Installs
|
||||
shortTitle: Docker Installs
|
||||
weight: 3
|
||||
aliases:
|
||||
- /rancher/v2.0-v2.4/en/installation/after-installation/single-node-backup-and-restoration/
|
||||
- /rancher/v2.0-v2.4/en/backups/restorations/single-node-restoration
|
||||
- /rancher/v2.0-v2.4/en/backups/v2.0.x-v2.4.x/restore/docker-restores
|
||||
- /rancher/v2.x/en/backups/v2.0.x-v2.4.x/restore/docker-restores/
|
||||
---
|
||||
|
||||
If you encounter a disaster scenario, you can restore your Rancher Server to your most recent backup.
|
||||
|
||||
## Before You Start
|
||||
|
||||
During restore of your backup, you'll enter a series of commands, filling placeholders with data from your environment. These placeholders are denoted with angled brackets and all capital letters (`<EXAMPLE>`). Here's an example of a command with a placeholder:
|
||||
|
||||
```
|
||||
docker run --volumes-from <RANCHER_CONTAINER_NAME> -v $PWD:/backup \
|
||||
busybox sh -c "rm /var/lib/rancher/* -rf && \
|
||||
tar pzxvf /backup/rancher-data-backup-<RANCHER_VERSION>-<DATE>"
|
||||
```
|
||||
|
||||
In this command, `<RANCHER_CONTAINER_NAME>` and `<RANCHER_VERSION>-<DATE>` are environment variables for your Rancher deployment.
|
||||
|
||||
Cross reference the image and reference table below to learn how to obtain this placeholder data. Write down or copy this information before starting the procedure below.
|
||||
|
||||
<sup>Terminal <code>docker ps</code> Command, Displaying Where to Find <code><RANCHER_CONTAINER_TAG></code> and <code><RANCHER_CONTAINER_NAME></code></sup>
|
||||
|
||||
|
||||
|
||||
| Placeholder | Example | Description |
|
||||
| -------------------------- | -------------------------- | --------------------------------------------------------- |
|
||||
| `<RANCHER_CONTAINER_TAG>` | `v2.0.5` | The rancher/rancher image you pulled for initial install. |
|
||||
| `<RANCHER_CONTAINER_NAME>` | `festive_mestorf` | The name of your Rancher container. |
|
||||
| `<RANCHER_VERSION>` | `v2.0.5` | The version number for your Rancher backup. |
|
||||
| `<DATE>` | `9-27-18` | The date that the data container or backup was created. |
|
||||
<br/>
|
||||
|
||||
You can obtain `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>` by logging into your Rancher Server by remote connection and entering the command to view the containers that are running: `docker ps`. You can also view containers that are stopped using a different command: `docker ps -a`. Use these commands for help anytime during while creating backups.
|
||||
|
||||
## Restoring Backups
|
||||
|
||||
Using a [backup]({{<baseurl>}}/rancher/v2.0-v2.4/en/backups/backups/single-node-backups/) that you created earlier, restore Rancher to its last known healthy state.
|
||||
|
||||
1. Using a remote Terminal connection, log into the node running your Rancher Server.
|
||||
|
||||
1. Stop the container currently running Rancher Server. Replace `<RANCHER_CONTAINER_NAME>` with the name of your Rancher container.
|
||||
|
||||
```
|
||||
docker stop <RANCHER_CONTAINER_NAME>
|
||||
```
|
||||
1. Move the backup tarball that you created during completion of [Creating Backups—Docker Installs]({{<baseurl>}}/rancher/v2.0-v2.4/en/backups/backups/single-node-backups/) onto your Rancher Server. Change to the directory that you moved it to. Enter `dir` to confirm that it's there.
|
||||
|
||||
If you followed the naming convention we suggested in [Creating Backups—Docker Installs]({{<baseurl>}}/rancher/v2.0-v2.4/en/backups/backups/single-node-backups/), it will have a name similar to `rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz`.
|
||||
|
||||
1. Enter the following command to delete your current state data and replace it with your backup data, replacing the placeholders. Don't forget to close the quotes.
|
||||
|
||||
>**Warning!** This command deletes all current state data from your Rancher Server container. Any changes saved after your backup tarball was created will be lost.
|
||||
|
||||
```
|
||||
docker run --volumes-from <RANCHER_CONTAINER_NAME> -v $PWD:/backup \
|
||||
busybox sh -c "rm /var/lib/rancher/* -rf && \
|
||||
tar pzxvf /backup/rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz"
|
||||
```
|
||||
|
||||
**Step Result:** A series of commands should run.
|
||||
|
||||
1. Restart your Rancher Server container, replacing the placeholder. It will restart using your backup data.
|
||||
|
||||
```
|
||||
docker start <RANCHER_CONTAINER_NAME>
|
||||
```
|
||||
|
||||
1. Wait a few moments and then open Rancher in a web browser. Confirm that the restore succeeded and that your data is restored.
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
title: Restoring Rancher Installed on a K3s Kubernetes Cluster
|
||||
shortTitle: K3s Installs
|
||||
weight: 1
|
||||
aliases:
|
||||
- /rancher/v2.0-v2.4/en/backups/restorations/k3s-restoration
|
||||
- /rancher/v2.0-v2.4/en/backups/restorations/k8s-restore/k3s-restore
|
||||
- /rancher/v2.0-v2.4/en/backups/legacy/restore/k8s-restore/k3s-restore/
|
||||
- /rancher/v2.0-v2.4/en/backups/legacy/restore/k3s-restore
|
||||
- /rancher/v2.0-v2.4/en/backups/v2.0.x-v2.4.x/restore/k3s-restore
|
||||
- /rancher/v2.x/en/backups/v2.0.x-v2.4.x/restore/k3s-restore/
|
||||
---
|
||||
|
||||
When Rancher is installed on a high-availability Kubernetes cluster, we recommend using an external database to store the cluster data.
|
||||
|
||||
The database administrator will need to back up the external database, or restore it from a snapshot or dump.
|
||||
|
||||
We recommend configuring the database to take recurring snapshots.
|
||||
|
||||
### Creating Snapshots and Restoring Databases from Snapshots
|
||||
|
||||
For details on taking database snapshots and restoring your database from them, refer to the official database documentation:
|
||||
|
||||
- [Official MySQL documentation](https://dev.mysql.com/doc/refman/8.0/en/replication-snapshot-method.html)
|
||||
- [Official PostgreSQL documentation](https://www.postgresql.org/docs/8.3/backup-dump.html)
|
||||
- [Official etcd documentation](https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/recovery.md)
|
||||
@@ -9,8 +9,8 @@ aliases:
|
||||
---
|
||||
If you lose the data on your Rancher Server, you can restore it if you have backups stored in a safe location.
|
||||
|
||||
- [Restoring backups for Rancher installed with Docker](./docker-restores)
|
||||
- [Restoring backups for Rancher installed on an RKE Kubernetes cluster](./rke-restore)
|
||||
- [Restoring backups for Rancher installed on a K3s Kubernetes cluster](./k3s-restore)
|
||||
- [Restoring backups for Rancher installed with Docker](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-docker-installed-rancher.md)
|
||||
- [Restoring backups for Rancher installed on an RKE Kubernetes cluster](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md)
|
||||
- [Restoring backups for Rancher installed on a K3s Kubernetes cluster](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-k3s-installed-rancher.md)
|
||||
|
||||
If you are looking to restore your [Rancher launched Kubernetes cluster]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/), please refer to [this section]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/restoring-etcd/).
|
||||
If you are looking to restore your [Rancher launched Kubernetes cluster](../../pages-for-subheaders/launch-kubernetes-with-rancher.md), please refer to [this section](../../how-to-guides/advanced-user-guides/manage-clusters/restoring-etcd.md).
|
||||
@@ -1,141 +0,0 @@
|
||||
---
|
||||
title: Restoring Backups—Kubernetes installs
|
||||
shortTitle: RKE Installs
|
||||
weight: 2
|
||||
aliases:
|
||||
- /rancher/v2.0-v2.4/en/installation/after-installation/ha-backup-and-restoration/
|
||||
- /rancher/v2.0-v2.4/en/backups/restorations/ha-restoration
|
||||
- /rancher/v2.0-v2.4/en/backups/restorations/k8s-restore/rke-restore
|
||||
- /rancher/v2.0-v2.4/en/backups/legacy/restore/k8s-restore/rke-restore/
|
||||
- /rancher/v2.0-v2.4/en/backups/legacy/restore/rke-restore
|
||||
- /rancher/v2.0-v2.4/en/backups/v2.0.x-v2.4.x/restore/rke-restore
|
||||
- /rancher/v2.x/en/backups/v2.0.x-v2.4.x/restore/rke-restore/
|
||||
---
|
||||
|
||||
This procedure describes how to use RKE to restore a snapshot of the Rancher Kubernetes cluster.
|
||||
This will restore the Kubernetes configuration and the Rancher database and state.
|
||||
|
||||
> **Note:** This document covers clusters set up with RKE >= v0.2.x, for older RKE versions refer to the [RKE Documentation]({{<baseurl>}}/rke/latest/en/etcd-snapshots/restoring-from-backup).
|
||||
|
||||
## Restore Outline
|
||||
|
||||
<!-- TOC -->
|
||||
|
||||
- [1. Preparation](#1-preparation)
|
||||
- [2. Place Snapshot](#2-place-snapshot)
|
||||
- [3. Configure RKE](#3-configure-rke)
|
||||
- [4. Restore the Database and bring up the Cluster](#4-restore-the-database-and-bring-up-the-cluster)
|
||||
|
||||
<!-- /TOC -->
|
||||
|
||||
### 1. Preparation
|
||||
|
||||
It is advised that you run the restore from your local host or a jump box/bastion where your cluster yaml, rke statefile, and kubeconfig are stored. You will need [RKE]({{<baseurl>}}/rke/latest/en/installation/) and [kubectl]({{<baseurl>}}/rancher/v2.0-v2.4/en/faq/kubectl/) CLI utilities installed locally.
|
||||
|
||||
Prepare by creating 3 new nodes to be the target for the restored Rancher instance. We recommend that you start with fresh nodes and a clean state. For clarification on the requirements, review the [Installation Requirements](https://rancher.com/docs/rancher/v2.0-v2.4/en/installation/requirements/).
|
||||
|
||||
Alternatively you can re-use the existing nodes after clearing Kubernetes and Rancher configurations. This will destroy the data on these nodes. See [Node Cleanup]({{<baseurl>}}/rancher/v2.0-v2.4/en/faq/cleaning-cluster-nodes/) for the procedure.
|
||||
|
||||
You must restore each of your etcd nodes to the same snapshot. Copy the snapshot you're using from one of your nodes to the others before running the `etcd snapshot-restore` command.
|
||||
|
||||
> **IMPORTANT:** Before starting the restore make sure all the Kubernetes services on the old cluster nodes are stopped. We recommend powering off the nodes to be sure.
|
||||
|
||||
### 2. Place Snapshot
|
||||
|
||||
As of RKE v0.2.0, snapshots could be saved in an S3 compatible backend. To restore your cluster from the snapshot stored in S3 compatible backend, you can skip this step and retrieve the snapshot in [4. Restore the Database and bring up the Cluster](#4-restore-the-database-and-bring-up-the-cluster). Otherwise, you will need to place the snapshot directly on one of the etcd nodes.
|
||||
|
||||
Pick one of the clean nodes that will have the etcd role assigned and place the zip-compressed snapshot file in `/opt/rke/etcd-snapshots` on that node.
|
||||
|
||||
> **Note:** Because of a current limitation in RKE, the restore process does not work correctly if `/opt/rke/etcd-snapshots` is a NFS share that is mounted on all nodes with the etcd role. The easiest options are to either keep `/opt/rke/etcd-snapshots` as a local folder during the restore process and only mount the NFS share there after it has been completed, or to only mount the NFS share to one node with an etcd role in the beginning.
|
||||
|
||||
### 3. Configure RKE
|
||||
|
||||
Use your original `rancher-cluster.yml` and `rancher-cluster.rkestate` files. If they are not stored in a version control system, it is a good idea to back them up before making any changes.
|
||||
|
||||
```
|
||||
cp rancher-cluster.yml rancher-cluster.yml.bak
|
||||
cp rancher-cluster.rkestate rancher-cluster.rkestate.bak
|
||||
```
|
||||
|
||||
If the replaced or cleaned nodes have been configured with new IP addresses, modify the `rancher-cluster.yml` file to ensure the address and optional internal_address fields reflect the new addresses.
|
||||
|
||||
> **IMPORTANT:** You should not rename the `rancher-cluster.yml` or `rancher-cluster.rkestate` files. It is important that the filenames match each other.
|
||||
|
||||
### 4. Restore the Database and bring up the Cluster
|
||||
|
||||
You will now use the RKE command-line tool with the `rancher-cluster.yml` and the `rancher-cluster.rkestate` configuration files to restore the etcd database and bring up the cluster on the new nodes.
|
||||
|
||||
> **Note:** Ensure your `rancher-cluster.rkestate` is present in the same directory as the `rancher-cluster.yml` file before starting the restore, as this file contains the certificate data for the cluster.
|
||||
|
||||
#### Restoring from a Local Snapshot
|
||||
|
||||
When restoring etcd from a local snapshot, the snapshot is assumed to be located on the target node in the directory `/opt/rke/etcd-snapshots`.
|
||||
|
||||
```
|
||||
rke etcd snapshot-restore --name snapshot-name --config ./rancher-cluster.yml
|
||||
```
|
||||
|
||||
> **Note:** The --name parameter expects the filename of the snapshot without the extension.
|
||||
|
||||
#### Restoring from a Snapshot in S3
|
||||
|
||||
_Available as of RKE v0.2.0_
|
||||
|
||||
When restoring etcd from a snapshot located in an S3 compatible backend, the command needs the S3 information in order to connect to the S3 backend and retrieve the snapshot.
|
||||
|
||||
```
|
||||
$ rke etcd snapshot-restore --config ./rancher-cluster.yml --name snapshot-name \
|
||||
--s3 --access-key S3_ACCESS_KEY --secret-key S3_SECRET_KEY \
|
||||
--bucket-name s3-bucket-name --s3-endpoint s3.amazonaws.com \
|
||||
--folder folder-name # Available as of v2.3.0
|
||||
```
|
||||
|
||||
#### Options for `rke etcd snapshot-restore`
|
||||
|
||||
S3 specific options are only available for RKE v0.2.0+.
|
||||
|
||||
| Option | Description | S3 Specific |
|
||||
| --- | --- | ---|
|
||||
| `--name` value | Specify snapshot name | |
|
||||
| `--config` value | Specify an alternate cluster YAML file (default: "cluster.yml") [$RKE_CONFIG] | |
|
||||
| `--s3` | Enabled backup to s3 |* |
|
||||
| `--s3-endpoint` value | Specify s3 endpoint url (default: "s3.amazonaws.com") | * |
|
||||
| `--access-key` value | Specify s3 accessKey | *|
|
||||
| `--secret-key` value | Specify s3 secretKey | *|
|
||||
| `--bucket-name` value | Specify s3 bucket name | *|
|
||||
| `--folder` value | Specify s3 folder in the bucket name _Available as of v2.3.0_ | *|
|
||||
| `--region` value | Specify the s3 bucket location (optional) | *|
|
||||
| `--ssh-agent-auth` | [Use SSH Agent Auth defined by SSH_AUTH_SOCK]({{<baseurl>}}/rke/latest/en/config-options/#ssh-agent) | |
|
||||
| `--ignore-docker-version` | [Disable Docker version check]({{<baseurl>}}/rke/latest/en/config-options/#supported-docker-versions) |
|
||||
|
||||
#### Testing the Cluster
|
||||
|
||||
Once RKE completes it will have created a credentials file in the local directory. Configure `kubectl` to use the `kube_config_rancher-cluster.yml` credentials file and check on the state of the cluster. See [Installing and Configuring kubectl]({{<baseurl>}}/rancher/v2.0-v2.4/en/faq/kubectl/#configuration) for details.
|
||||
|
||||
#### Check Kubernetes Pods
|
||||
|
||||
Wait for the pods running in `kube-system`, `ingress-nginx` and the `rancher` pod in `cattle-system` to return to the `Running` state.
|
||||
|
||||
> **Note:** `cattle-cluster-agent` and `cattle-node-agent` pods will be in an `Error` or `CrashLoopBackOff` state until Rancher server is up and the DNS/Load Balancer have been pointed at the new cluster.
|
||||
|
||||
```
|
||||
kubectl get pods --all-namespaces
|
||||
|
||||
NAMESPACE NAME READY STATUS RESTARTS AGE
|
||||
cattle-system cattle-cluster-agent-766585f6b-kj88m 0/1 Error 6 4m
|
||||
cattle-system cattle-node-agent-wvhqm 0/1 Error 8 8m
|
||||
cattle-system rancher-78947c8548-jzlsr 0/1 Running 1 4m
|
||||
ingress-nginx default-http-backend-797c5bc547-f5ztd 1/1 Running 1 4m
|
||||
ingress-nginx nginx-ingress-controller-ljvkf 1/1 Running 1 8m
|
||||
kube-system canal-4pf9v 3/3 Running 3 8m
|
||||
kube-system cert-manager-6b47fc5fc-jnrl5 1/1 Running 1 4m
|
||||
kube-system kube-dns-7588d5b5f5-kgskt 3/3 Running 3 4m
|
||||
kube-system kube-dns-autoscaler-5db9bbb766-s698d 1/1 Running 1 4m
|
||||
kube-system metrics-server-97bc649d5-6w7zc 1/1 Running 1 4m
|
||||
kube-system tiller-deploy-56c4cf647b-j4whh 1/1 Running 1 4m
|
||||
```
|
||||
|
||||
#### Finishing Up
|
||||
|
||||
Rancher should now be running and available to manage your Kubernetes clusters.
|
||||
> **IMPORTANT:** Remember to save your updated RKE config (`rancher-cluster.yml`) state file (`rancher-cluster.rkestate`) and `kubectl` credentials (`kube_config_rancher-cluster.yml`) files in a safe place for future maintenance for example in a version control system.
|
||||
@@ -1,77 +0,0 @@
|
||||
---
|
||||
title: "Rolling back to v2.0.0-v2.1.5"
|
||||
weight: 1
|
||||
aliases:
|
||||
- /rancher/v2.x/en/backups/v2.0.x-v2.4.x/restore/rke-restore/v2.0-v2.1/
|
||||
---
|
||||
|
||||
> Rolling back to Rancher v2.0-v2.1 is no longer supported. The instructions for rolling back to these versions are preserved here and are intended to be used only in cases where upgrading to Rancher v2.2+ is not feasible.
|
||||
|
||||
If you are rolling back to versions in either of these scenarios, you must follow some extra instructions in order to get your clusters working.
|
||||
|
||||
- Rolling back from v2.1.6+ to any version between v2.1.0 - v2.1.5 or v2.0.0 - v2.0.10.
|
||||
- Rolling back from v2.0.11+ to any version between v2.0.0 - v2.0.10.
|
||||
|
||||
Because of the changes necessary to address [CVE-2018-20321](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20321), special steps are necessary if the user wants to roll back to a previous version of Rancher where this vulnerability exists. The steps are as follows:
|
||||
|
||||
1. Record the `serviceAccountToken` for each cluster. To do this, save the following script on a machine with `kubectl` access to the Rancher management plane and execute it. You will need to run these commands on the machine where the rancher container is running. Ensure JQ is installed before running the command. The commands will vary depending on how you installed Rancher.
|
||||
|
||||
**Rancher Installed with Docker**
|
||||
```
|
||||
docker exec <NAME OF RANCHER CONTAINER> kubectl get clusters -o json | jq '[.items[] | select(any(.status.conditions[]; .type == "ServiceAccountMigrated")) | {name: .metadata.name, token: .status.serviceAccountToken}]' > tokens.json
|
||||
```
|
||||
|
||||
**Rancher Installed on a Kubernetes Cluster**
|
||||
```
|
||||
kubectl get clusters -o json | jq '[.items[] | select(any(.status.conditions[]; .type == "ServiceAccountMigrated")) | {name: .metadata.name, token: .status.serviceAccountToken}]' > tokens.json
|
||||
```
|
||||
|
||||
2. After executing the command a `tokens.json` file will be created. Important! Back up this file in a safe place.** You will need it to restore functionality to your clusters after rolling back Rancher. **If you lose this file, you may lose access to your clusters.**
|
||||
|
||||
3. Rollback Rancher following the [normal instructions]({{<baseurl>}}/rancher/v2.0-v2.4/en/upgrades/rollbacks/).
|
||||
|
||||
4. Once Rancher comes back up, every cluster managed by Rancher (except for Imported clusters) will be in an `Unavailable` state.
|
||||
|
||||
5. Apply the backed up tokens based on how you installed Rancher.
|
||||
|
||||
**Rancher Installed with Docker**
|
||||
|
||||
Save the following script as `apply_tokens.sh` to the machine where the Rancher docker container is running. Also copy the `tokens.json` file created previously to the same directory as the script.
|
||||
```
|
||||
set -e
|
||||
|
||||
tokens=$(jq .[] -c tokens.json)
|
||||
for token in $tokens; do
|
||||
name=$(echo $token | jq -r .name)
|
||||
value=$(echo $token | jq -r .token)
|
||||
|
||||
docker exec $1 kubectl patch --type=merge clusters $name -p "{\"status\": {\"serviceAccountToken\": \"$value\"}}"
|
||||
done
|
||||
```
|
||||
the script to allow execution (`chmod +x apply_tokens.sh`) and execute the script as follows:
|
||||
```
|
||||
./apply_tokens.sh <DOCKER CONTAINER NAME>
|
||||
```
|
||||
After a few moments the clusters will go from Unavailable back to Available.
|
||||
|
||||
**Rancher Installed on a Kubernetes Cluster**
|
||||
|
||||
Save the following script as `apply_tokens.sh` to a machine with kubectl access to the Rancher management plane. Also copy the `tokens.json` file created previously to the same directory as the script.
|
||||
```
|
||||
set -e
|
||||
|
||||
tokens=$(jq .[] -c tokens.json)
|
||||
for token in $tokens; do
|
||||
name=$(echo $token | jq -r .name)
|
||||
value=$(echo $token | jq -r .token)
|
||||
|
||||
kubectl patch --type=merge clusters $name -p "{\"status\": {\"serviceAccountToken\": \"$value\"}}"
|
||||
done
|
||||
```
|
||||
Set the script to allow execution (`chmod +x apply_tokens.sh`) and execute the script as follows:
|
||||
```
|
||||
./apply_tokens.sh
|
||||
```
|
||||
After a few moments the clusters will go from `Unavailable` back to `Available`.
|
||||
|
||||
6. Continue using Rancher as normal.
|
||||
Reference in new issue
Block a user