public/rancher-docs
1
0
Fork 0
mirror of https://github.com/rancher/rancher-docs.git synced 2026-09-25 20:48:11 +00:00
Code Issues Packages Projects Releases Wiki Activity

zzxcleaned up language

Browse Source
This commit is contained in:
Mark Bishop
2018-07-29 21:09:09 -07:00
parent 5b50221f73
commit 8c073124d9
3 changed files with 25 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/rancher/v2.x/en/backups/rollbacks/_index.md
+2 -2
View File
@@ -4,7 +4,7 @@ shortTitle: Rollbacks
weight: 1010
---
If you upgrade your Rancher Server and the upgrade is unsuccessful, you can use the backup you created during the upgrade process to restore the previous version of Rancher, along with its data.
If you encounter a disaster scenario where you lose Rancher or its data, you can recover by restoring to your most recent backup. This process will return your cluster to a healthy state, with minimal data loss.
- [Rolling Back—Single Node Installs](./single-node-rollbacks/)
- [Rolling Back—High Availablity Installs](./ha-server-rollbacks/)
- [Rolling Back—High Availability Installs](./ha-server-rollbacks/)
content/rancher/v2.x/en/backups/rollbacks/ha-server-rollbacks/_index.md
+13 -12
View File
@@ -6,7 +6,7 @@ aliases:
- /rancher/v2.x/en/backups/restorations/ha-restoration
---
There are two scenarios where you'll need to rollback to prior image of Rancher. The instructions change slightly for each scenario.
There are two scenarios where rolling back to a Rancher backup may be required.
<!-- TOC -->
@@ -19,19 +19,19 @@ There are two scenarios where you'll need to rollback to prior image of Rancher.
If you upgrade Rancher, but the upgrade does not complete successfully, you may need to roll back your Rancher Server to its last healthy state before upgrade. To restore Rancher:
- Restore the `etcd` snapshot taken before upgrade.
- Restore the etcd snapshot taken before upgrade.
- Run the command to revert to your prior version of Rancher.
>**Warning!**
>
> Rolling back to a previous version of Rancher destroys any changes made to Rancher following the upgrade. Unrecoverable data loss may occur.
>
>
>**Prerequisites:** {{< requirements_rollback >}}
1. Open **Terminal** and change directory to the location of the RKE binary that you used during upgrade.
1. Run one of the following commands to restore the `etcd` snapshot [that you took]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrade-scenarios/ha-server-upgrade/#snapshot) before your unsuccessful upgrade. Replace the `<SNAPSHOT.db>` placeholder with your snapshot.
1. Run one of the following commands to restore the etcd snapshot [that you took]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrade-scenarios/ha-server-upgrade/#snapshot) before your unsuccessful upgrade. Replace the `<SNAPSHOT.db>` placeholder with your snapshot.
```
# MacOS
@@ -49,7 +49,7 @@ If you upgrade Rancher, but the upgrade does not complete successfully, you may
./rke_linux-amd64 up --config rancher-cluster.yml
```
1. Lastly, restart the Kubernetes components on all cluster nodes to prevent potential `etcd` conflicts. Run this command on each of your nodes.
1. Restart the Kubernetes components on all cluster nodes to prevent potential etcd conflicts. Run this command on each of your nodes.
```
docker restart kube-apiserver kubelet kube-controller-manager kube-scheduler kube-proxy
@@ -72,11 +72,11 @@ kubectl --kubeconfig=kube_config-rancher-cluster.yml set image deployment/cattle
If you experience a disaster scenario where one of your cluster nodes fails, you'll need to replace the node and rollback to backup data.
- Create a new node and image it with a backup snapshot.
- Restore the `etcd` snapshot last taken before failure
- Restore the etcd snapshot last taken before failure.
### 1. Create New Node and Pull Snapshot
If one of your `etcd` nodes go down, you need to replace it with a new node, and then pull the most recent working `etcd` snapshot to that node.
If one of your etcd nodes go down, you need to replace it with a new node, and then pull the most recent working etcd snapshot to that node.
**To Create a New Node and Pull the Latest Snapshot:**
@@ -100,7 +100,8 @@ If one of your `etcd` nodes go down, you need to replace it with a new node, and
>**Remember:** Our use of Amazon S3 is an example used for this documentation. The command for pulling your snapshot may vary.
After restoring the cluster you have to restart the kubernetes components on all nodes, otherwise there will be some conflicts with resource versions of objects stored in `etcd`, this will include restart to kubernetes components and the network components, for more information please refer to [kubernetes documentation](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#etcd-upgrade-requirements), to do that you can run the following on each node:
After restoring the cluster, you have to restart the kubernetes components on all nodes. Otherwise there may be conflicts with resource versions of objects stored in etcd. This command restarts the kubernetes components and the network components. For more information please refer to the [Kubernetes documentation](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#etcd-upgrade-requirements). To restart the components, run the following command on each node.
```
docker restart kube-apiserver kubelet kube-controller-manager kube-scheduler kube-proxy
docker ps | grep flannel | cut -f 1 -d " " | xargs docker restart
@@ -109,9 +110,9 @@ docker ps | grep calico | cut -f 1 -d " " | xargs docker restart
### 2. Restore `etcd` Database
To restore the most recent `etcd` snapshot on your new node, run RKE the command `rke etcd snapshot-restore`. This command reverts to any snapshot stored in `/opt/rke/etcd-snapshots` that you explicitly define. When you run `rke etcd snapshot-restore`, RKE removes the old `etcd` container if it still exists. To restore operations, RKE creates a new `etcd` cluster using the snapshot you choose.
To restore the most recent etcd snapshot on your new node, run the RKE command `rke etcd snapshot-restore`. This command reverts to any snapshot stored in `/opt/rke/etcd-snapshots` that you explicitly define. When you run `rke etcd snapshot-restore`, RKE removes the old etcd container if it still exists. To restore operations, RKE creates a new etcd cluster using the snapshot you choose.
>**Warning:** Restoring an `etcd` snapshot deletes your current `etcd` cluster and replaces it with a new one. Before you run the `rke etcd snapshot-restore` command, backup any important data in your current cluster.
>**Warning:** Restoring an etcd snapshot deletes your current etcd cluster and replaces it with a new one. Before you run the `rke etcd snapshot-restore` command, backup any important data in your current cluster.
>
>**Prerequisites:** {{< requirements_rollback >}}
@@ -142,7 +143,7 @@ To restore the most recent `etcd` snapshot on your new node, run RKE the command
4. Open **Terminal** and change directory to the location of the RKE binary. Your `rancher-cluster.yml` file must reside in the same directory.
5. Run one of the following commands to restore the `etcd` database:
5. Run one of the following commands to restore the etcd database:
```
# MacOS
@@ -161,7 +162,7 @@ To restore the most recent `etcd` snapshot on your new node, run RKE the command
./rke_linux-amd64 up --config rancher-cluster.yml
```
7. Lastly, restart the Kubernetes components on all cluster nodes to prevent potential `etcd` conflicts. Run this command on each of your nodes.
7. Restart the Kubernetes components on all cluster nodes to prevent potential etcd conflicts. Run this command on each of your nodes.
```
docker restart kube-apiserver kubelet kube-controller-manager kube-scheduler kube-proxy
content/rancher/v2.x/en/backups/rollbacks/single-node-rollbacks/_index.md
+10 -9
View File
@@ -6,21 +6,20 @@ aliases:
- /rancher/v2.x/en/backups/restorations/single-node-restoration/
---
There are two scenarios where you'll need to rollback to prior image of Rancher. The instructions change slightly for each scenario.
There are two scenarios where rolling back to a recent backup may be required.
<!-- TOC -->
- [Recovering from an Unsuccessful Upgrade](#recovering-from-an-unsuccessful-upgrade): In this scenario, you need to restore both the prior version of Rancher and your state data.
- [Recovering from a Disaster Scenario](#recovering-from-a-disaster-scenario): In this scenario, you'll only need to restore you state data.
- [Recovering from an Unsuccessful Upgrade](#recovering-from-an-unsuccessful-upgrade): In this scenario, you restore the Rancher application and data to backups taken before upgrade.
- [Recovering from a Disaster Scenario](#recovering-from-a-disaster-scenario): In this scenario, you'll only need to restore your data.
<!-- /TOC -->
## Recovering from an Unsuccessful Upgrade
Rolling back an unsuccessful Rancher upgrade requires you to
restore the backup you created while completing [Single Node Upgrade]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrade-scenarios/single-node-upgrade/).
If you experience an unsuccessful upgrade, you can restore to backups you created during the [upgrade process]({{< baseurl >}}/rancher/v2.x/en/upgrades/upgrade-scenarios/single-node-upgrade/).
>**Warning!** Rolling back to a previous version of Rancher destroys any changes made to Rancher following the upgrade. Unrecoverable data loss may occur.
>**Warning!** Rolling back to a previous version destroys any changes made to Rancher following the upgrade. Unrecoverable data loss may occur.
1. Pull the version of Rancher that you were running prior to upgrade.
@@ -34,7 +33,7 @@ docker pull rancher/rancher:<PRIOR_VERSION>
docker stop <RANCHER_CONTAINER_ID>
```
3. Go to the location where you saved your [backup tar balls]({{< baseurl>}}/rancher/v2.x/en/upgrades/single-node-upgrade/#backup). Run the following command to create a data container from the backup tar ball.
3. Go to the location where you saved your [backup tarballs]({{< baseurl>}}/rancher/v2.x/en/upgrades/single-node-upgrade/#backup). Run the following command to create a data container from the backup tarball.
```
docker run --volumes-from rancher-data-<PRIOR_VERSION> \
@@ -51,13 +50,15 @@ docker run -d --volumes-from rancher-data-<PRIOR_VERSION> \
## Recovering from a Disaster Scenario
If you experience a disaster scenario, you can restore to your most recent backup with minimal data loss.
1. Stop the container currently running Rancher Server. Replace `<RANCHER_CONTAINER_ID>` with the ID of your Rancher container.
```
docker stop <RANCHER_CONTAINER_ID>
```
2. Go to the location where you saved your [backup tar balls]({{< baseurl >}}/rancher/v2.x/en/backups/backups/single-node-backups/#backup). Run the following command to delete your current state data and start your backup data:
2. Go to the location where you saved your [backup tarballs]({{< baseurl >}}/rancher/v2.x/en/backups/backups/single-node-backups/#backup). Run the following command to delete your current state data and start your backup data:
```
docker run --volumes-from <RANCHER_CONTAINER_ID> -v $PWD:/backup \
@@ -67,7 +68,7 @@ tar zxvf /backup/<BACKUP_FILENAME>.tar.gz"
>**Warning!** Running this command will delete ALL current state data from your Rancher Server container. Any changes that happened after the backup point you are restoring will be lost.
3. Start you rancher server container back. The container will start with the data from the restored backup.
3. Start your Rancher Server container. The container will start with the data from the restored backup.
```
docker start <RANCHER_CONTAINER_ID>