# etcd2-backup-coreos Remote backup and multi-node restore services for etcd2 clusters on CoreOS Linux. **Warning:** This package is only intended for use on CoreOS Linux. ## Terminology **Founding member** : The node which is the first member of the new recovered cluster. It is this node's rclone backup data (only) that will be used to restore the cluster. The rest of the nodes will join the cluster with no data, and simply catch up with the **founding member**. ## Configuration Before installing etcd2-backup, configure `30-etcd2-backup-restore.conf`: ``` [Service] Environment="ETCD_RESTORE_MASTER_ADV_PEER_URLS=" Environment="RCLONE_ENDPOINT=remote-name:path/to/backups" ``` Assuming a deployment to CoreOS with etcd2, only change: * `ETCD_RESTORE_MASTER_ADV_PEER_URLS` This is the new advertised peer url of the new etcd2 node that will be the founding member of the new restored cluster. We will call this node the **founding member**. * `RCLONE_ENDPOINT` The rclone endpoint to which backups will be stored. Feel free to point any number of machines at the same RCLONE_ENDPOINT, path and all. Backups for each machine are stored in a sub-folder named with the machine ID (%m in systemd parlance) * `./rclone.conf` The rclone configuration file which will be installed. Must list a `[section]` which matches `RCLONE_ENDPOINT`'s remote-name component. An easy way to generate this config file is to [install rclone](http://rclone.org/install/) on a local machine. Then follow the [configuration instructions](http://rclone.org/docs/) to generate an `rclone.conf` file. To adjust backup frequency, edit `./etcd2-backup.timer` ## Installation Once those things are configured, run `./build`. The `build` script generates a tarball for copying to CoreOS instances. The tarball contains the `etcd2-backup-install` script. After extracting the contents of the tar file and running the install script, three new systemd services are added. One service, `etcd2-backup`, performs periodic etcd backups, while the other two services, `etcd2-restore` and `etcd2-join`, handle restore procedures. * `etcd2-backup.service` A oneshot service which calls `etcdctl backup` and syncs the backups to the rclone endpoint (using an rclone container, of course). `etcd2-backup.timer` is responsible for periodically running this service. * `etcd2-restore.service` A oneshot service which wipes all etcd2 data and restores a single-node cluster from the rclone backup. This is for restoring the **founding member** only. * `etcd2-join.service` A oneshot service which wipes all etcd2 data and re-joins the new cluster. This is for adding members **after** the **founding member** has succesfully established the new cluster via `etcd2-restore.service` ## Recovery This assumes that the cluster has lost quorum and is not recoverable. Otherwise try to heal the cluster first. ### Backup Freshness Two factors contribute to the relative freshness or staleness of a backup. The `etcd2-backup.timer` takes a backup every 30 seconds by default, and the etcd `snapshot-count` option controls how many transactions are committed between each write of the snapshot to permanent storage. Given those parameters, we can compute the upper bound on the outdatedness of a backup. Assumptions: * transaction rate is a constant `1000 transactions / second` * `etcd2-backup.timer` is configured for a 30 second interval * `etcd2 snapshot-count=10000` ``` max-missed-seconds= (10000 transactions / (1000 transactions / second)) + 30 seconds = 40 seconds ``` ### Recovery Procedure 1. Make sure `etcd2.service` and `etcd2-backup.timer` are stopped on all nodes in the cluster 2. Restore the **founding member** by starting `etcd2-restore.service` and then, if successful, `etcd2.service` 3. Restore the rest of the cluster **one at a time**. Start `etcd2-join.service`, and then, if successful, `etcd2.service`. Please verify with `etcdctl cluster-health` that the expected set of nodes is present and healthy after each node joins. 4. Verify that the data is sane (enough). If so, kick off `etcd2-backup.timer` on all nodes and, hopefully, go back to bed. ## Retroactively change the founding member It is necessary to change the cluster's founding member in order to restore a cluster from any other node's data. Change the value of `ETCD_RESTORE_MASTER_ADV_PEER_URLS` in `30-etcd2-backup-restore.conf` to the advertised peer url of the new founding member. Repeat the install process above on all nodes in the cluster, then proceed with the [recovery procedure](README.md#recovery-procedure). ## Example Let's pretend that we have an initial 3 node CoreOS cluster that we want to back up to S3. | ETCD_NAME | ETCD_ADVERTISED_PEER_URL | | ------------- |:-------------:| | e1 | http://172.17.4.51:2379 | | e2 | http://172.17.4.52:2379 | | e3 | http://172.17.4.53:2379 | In the event that the cluster fails, we want to restore from `e1`'s backup ## Configuration ``` [Service] Environment="ETCD_RESTORE_MASTER_ADV_PEER_URLS=http://172.17.4.51:2379" Environment="RCLONE_ENDPOINT=s3-testing-conf:s3://etcd2-backup-bucket/backups" ``` The `./rclone.conf` file must contain a `[section]` matching `RCLONE_ENDPOINTS`'s remote-name component. ``` [s3-testing-conf] type = s3 access_key_id = xxxxxxxx secret_access_key = xxxxxx region = us-west-1 endpoint = location_constraint = ``` ## Installation ```sh cd etcd2-backup ./build scp etcd2-backup.tgz core@e1:~/ ssh core@e1 e1 $ mkdir -p ~/etcd2-backup e1 $ mv etcd2-backup.tgz etcd2-backup/ e1 $ cd etcd2-backup e1 $ tar zxvf ~/etcd2-backup.tgz e1 $ ./etcd2-backup-install # Only do the following two commands if this node should generate backups e1 $ sudo systemctl enable etcd2-backup.timer e1 $ sudo systemctl start etcd2-backup.timer e1 $ exit ``` Now `e1`'s etcd data will be backed up to `s3://etcd2-backup-bucket/backups//` according to the schedule described in `etcd2-backup.timer`. Repeat the process for `e2` and `e3`. To stop a node from generating backups, omit enabling and starting `etcd2-backup.timer`. ## Restore the cluster Let's assume that a mischievous friend decided it would be a good idea to corrupt the etcd2 data-dir on ALL of the nodes (`e1`,`e2`,`e3`). Simply restore the cluster from `e1`'s backup. Here's how to recover: ```sh # First, ENSURE etcd2 and etcd2-backup are not running on any nodes for node in e{1..3};do ssh core@$node "sudo systemctl stop etcd2.service etcd2-backup.{timer,service}" done ssh core@e1 "sudo systemctl start etcd2-restore.service && sudo systemctl start etcd2.service" for node in e{2..3};do ssh core@$node "sudo systemctl start etcd2-join.service && sudo systemctl start etcd2.service" sleep 10 done ``` After e2 and e3 finish catching up, the cluster should be back to normal. ## Migrate the cluster The same friend who corrupted the etcd2 data-dirs decided that to have more fun. This time, the friend dumps coffee on the machines hosting `e1`, `e2` and `e3`. There is a horrible smell, and the machines are dead. Luckily, there's a new 3-node etcd2 cluster ready to go, along with the S3 backup for `e1` from the old cluster. The new cluster configuration looks like this. Assume that etcd2-backup is not installed. (If it is, make sure it's not running on any nodes) | ETCD_NAME | ETCD_ADVERTISED_PEER_URL | | ------------- |:-------------:| | q1 | http://172.17.8.201:2379 | | q2 | http://172.17.8.202:2379 | | q3 | http://172.17.8.203:2379 | We will assume `q1` is the chosen founding member, though picking any node is fine. ## Migrate the remote backup First, copy the backup from `e1`'s backup folder to `q1`'s backup folder. I will show the S3 example. ```sh # Make sure to remove q1's backup directory, if it exists already aws s3 rm --recursive s3://etcd2-backup-bucket/backups/ aws s3 cp --recursive s3://etcd2-backup-bucket/backups/ s3://etcd2-backup-bucket/backups/ ``` ## Configure the New Cluster ``` [Service] Environment="ETCD_RESTORE_MASTER_ADV_PEER_URLS=http://172.17.8.201:2379" Environment="RCLONE_ENDPOINT=s3-testing-conf:s3://etcd2-backup-bucket/backups" ``` Since this is a new cluster, each new node will have a new `machine-id` and will not clobber the backups from the old cluster, even though `RCLONE_ENDPOINT` is the same for both the old `e` cluster and the new `q` cluster. ## Installation We first want to install the configured etcd2-backup package on all nodes, but not start any services yet. ```sh cd etcd2-backup ./build for node in q{1..3};do scp etcd2-backup.tgz core@$node:~/ ssh core@$node "mkdir -p ~/etcd2-backup" ssh core@$node "mv etcd2-backup.tgz etcd2-backup/" ssh core@$node " cd etcd2-backup" ssh core@$node " tar zxvf ~/etcd2-backup.tgz" ssh core@$node " ./etcd2-backup-install" done ``` ## Migrate the Cluster With `q1` as the founding member. ```sh # First, make SURE etcd2 and etcd2-backup are not running on any nodes for node in q{1..3};do ssh core@$node "sudo systemctl stop etcd2.service" done ssh core@q1 "sudo systemctl start etcd2-restore.service && sudo systemctl start etcd2.service" for node in q{2..3};do ssh core@$node "sudo systemctl start etcd2-join.service && sudo systemctl start etcd2.service" sleep 10 done ``` After confirming the cluster has migrated properly, start and enable `etcd2-backup.timer` on at least one node. ```sh ssh core@q1 "sudo systemctl enable etcd2-backup.service && sudo systemctl start etcd2-backup.service" ``` There should now be periodic backups going to: `s3://etcd2-backup-bucket/backups/` ## Words of caution 1. Notice the `sleep 10` commands that follow starting `etcd2-join.service` and then `etcd2.service`. This sleep is there to allow the member that joined to cluster time to catch up on the cluster state before we attempt to add the next member. This involves sending the entire snapshot over the network. If the dataset is large, the network between nodes is slow, disks are already bogged down, or the system is otherwise overutilized, try increasing the sleep. In the case of large data sets, it is recommended to copy the data directory produced by `etcd2-restore` on the founding member to the other nodes before running `etcd2-join` on them. This will avoid etcd transferring the entire snapshot to every node after it joins the cluster. 2. It is not recommended clients be allowed to access the etcd2 cluster **until** all members have been added and finished catching up.