Restructure the Ubuntu Getting Started Section.
- This supercedes PR #1770 - This breaks up the section from one huge installation page into: - A new index page. - New support grid with commercial and community support options. - Move to lifecycle-based pages based on operational tasks. - Add support for local deployments via LXD. - Added screenshots to images/docs/ubuntu - Add backup page. - Add decommissioning page. - Add a glossary of terms page. - Rewritten installation page. - Add logging page. - Add monitoring page. - Add networking page, flannel only for now, calico in progress. - Add a scaling page. - Add a security page. - Add a storage page. - Add a troubleshooting page. - Add an upgrade page. - Add a cluster validation page. - Add new ubuntu content to the index page. - Add Ubuntu to _data TOC. - Add warning about choosing ipv6 with LXD, thanks Ed Baluf. - Template-ize all the pages per jaredb's review.
This commit is contained in:
@@ -0,0 +1,142 @@
|
||||
---
|
||||
title: Backups
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
This pages shows you how to backup and restore data from the different deployed services in a given cluster.
|
||||
{% endcapture %}
|
||||
|
||||
{% capture prerequisites %}
|
||||
This page assumes you have a working Juju deployed cluster.
|
||||
{% endcapture %}
|
||||
|
||||
## Exporting cluster data
|
||||
|
||||
Exporting of cluster data is not supported at this time.
|
||||
|
||||
## Restoring cluster data
|
||||
|
||||
Importing of cluster data is not supported at this time.
|
||||
|
||||
{% capture steps %}
|
||||
## Exporting etcd data
|
||||
|
||||
Migrating etcd is a fairly easy task.
|
||||
|
||||
Step 1: Snapshot your existing cluster. This is encapsulated in the `snapshot`
|
||||
action.
|
||||
|
||||
```
|
||||
juju run-action etcd/0 snapshot
|
||||
```
|
||||
|
||||
Results:
|
||||
|
||||
```
|
||||
Action queued with id: b46d5d6f-5625-4320-8cda-b611c6ae580c
|
||||
```
|
||||
|
||||
Step 2: Check the status of the action so you can grab the snapshot and verify
|
||||
the sum. The copy.cmd result output is a copy/paste command for you to download
|
||||
the exact snapshot that you just created.
|
||||
|
||||
Download the snapshot archive from the unit that created the snapshot and verify
|
||||
the sha256 sum
|
||||
|
||||
```
|
||||
juju show-action-output b46d5d6f-5625-4320-8cda-b611c6ae580c
|
||||
```
|
||||
|
||||
Results:
|
||||
|
||||
```
|
||||
results:
|
||||
copy:
|
||||
cmd: juju scp etcd/0:/home/ubuntu/etcd-snapshots/etcd-snapshot-2016-11-09-02.41.47.tar.gz
|
||||
.
|
||||
snapshot:
|
||||
path: /home/ubuntu/etcd-snapshots/etcd-snapshot-2016-11-09-02.41.47.tar.gz
|
||||
sha256: 1dea04627812397c51ee87e313433f3102f617a9cab1d1b79698323f6459953d
|
||||
size: 68K
|
||||
status: completed
|
||||
```
|
||||
|
||||
Copy the snapshot to the local disk and then check the sha256sum.
|
||||
|
||||
```
|
||||
juju scp etcd/0:/home/ubuntu/etcd-snapshots/etcd-snapshot-2016-11-09-02.41.47.tar.gz .
|
||||
sha256sum etcd-snapshot-2016-11-09-02.41.47.tar.gz
|
||||
```
|
||||
|
||||
Step 3: Deploy the new cluster leader, and attach the snapshot:
|
||||
|
||||
```
|
||||
juju deploy etcd new-etcd --resource snapshot=./etcd-snapshot-2016-11-09-02.41.47.tar.gz
|
||||
```
|
||||
|
||||
Step 4: Re-Initialize the master with the data from the resource we just attached
|
||||
in step 3.
|
||||
|
||||
```
|
||||
juju run-action new-etcd/0 restore
|
||||
```
|
||||
|
||||
## Restoring etcd data
|
||||
|
||||
Allows the operator to restore the data from a cluster-data snapshot. This
|
||||
comes with caveats and a very specific path to restore a cluster:
|
||||
|
||||
The cluster must be in a state of only having a single member. So it's best to
|
||||
deploy a new cluster using the etcd charm, without adding any additional units.
|
||||
|
||||
```
|
||||
juju deploy etcd new-etcd
|
||||
```
|
||||
|
||||
> The above code snippet will deploy a single unit of etcd, as 'new-etcd'
|
||||
|
||||
```
|
||||
juju run-action etcd/0 restore target=/mnt/etcd-backups
|
||||
```
|
||||
|
||||
Once the restore action has completed, evaluate the cluster health. If the unit
|
||||
is healthy, you may resume scaling the application to meet your needs.
|
||||
|
||||
- **param** target: destination directory to save the existing data.
|
||||
|
||||
- **param** skip-backup: Don't backup any existing data.
|
||||
|
||||
## Snapshot etcd data
|
||||
|
||||
Allows the operator to snapshot a running clusters data for use in cloning,
|
||||
backing up, or migrating Etcd clusters.
|
||||
|
||||
juju run-action etcd/0 snapshot target=/mnt/etcd-backups
|
||||
|
||||
- **param** target: destination directory to save the resulting snapshot archive.
|
||||
{% endcapture %}
|
||||
|
||||
{% capture discussion %}
|
||||
# Known Limitations
|
||||
|
||||
#### Loss of PKI warning
|
||||
|
||||
If you destroy the leader - identified with the `*` text next to the unit number in status:
|
||||
all TLS pki will be lost. No PKI migration occurs outside
|
||||
of the units requesting and registering the certificates.
|
||||
|
||||
> Important: Mismanaging this configuration will result in locking yourself
|
||||
> out of the cluster, and can potentially break existing deployments in very
|
||||
> strange ways relating to x509 validation of certificates, which affects both
|
||||
> servers and clients.
|
||||
|
||||
#### Restoring from snapshot on a scaled cluster
|
||||
|
||||
Restoring from a snapshot on a scaled cluster will result in a broken cluster.
|
||||
Etcd performs clustering during unit turn-up, and state is stored in Etcd itself.
|
||||
During the snapshot restore phase, a new cluster ID is initialized, and peers
|
||||
are dropped from the snapshot state to enable snapshot restoration. Please
|
||||
follow the migration instructions above in the restore action description.
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/task.md %}
|
||||
Reference in New Issue
Block a user