mirror of https://github.com/docker/docs.git
Port DTR disaster topics to template (#399)
This commit is contained in:
parent
638cded45c
commit
4b50fa25b2
|
@ -2,7 +2,11 @@
|
|||
title: Create a backup
|
||||
description: Learn how to create a backup of Docker Trusted Registry, for disaster recovery.
|
||||
keywords: dtr, disaster recovery
|
||||
ui_tabs:
|
||||
- version: dtr-2.5
|
||||
orlower: true
|
||||
---
|
||||
{% if include.version=="dtr-2.5" %}
|
||||
|
||||
{% assign metadata_backup_file = "dtr-metadata-backup.tar" %}
|
||||
{% assign image_backup_file = "dtr-image-backup.tar" %}
|
||||
|
@ -20,7 +24,7 @@ Docker Trusted Registry maintains data about:
|
|||
| Notary data | Notary tags and signatures |
|
||||
| Scan results | Security scanning results for images |
|
||||
| Certificates and keys | The certificates, public keys, and private keys that are used for mutual TLS communication |
|
||||
| Images content | The images you push to DTR. This can be stored on the filesystem of the node running DTR, or other storage system, depending on the configuration |
|
||||
| Images content | The images you push to DTR. This can be stored on the file system of the node running DTR, or other storage system, depending on the configuration |
|
||||
|
||||
This data is persisted on the host running DTR, using named volumes.
|
||||
[Learn more about DTR named volumes](../architecture.md).
|
||||
|
@ -56,7 +60,7 @@ restore.
|
|||
Since you can configure the storage backend that DTR uses to store images,
|
||||
the way you backup images depends on the storage backend you're using.
|
||||
|
||||
If you've configured DTR to store images on the local filesystem or NFS mount,
|
||||
If you've configured DTR to store images on the local file system or NFS mount,
|
||||
you can backup the images by using ssh to log into a node where DTR is running,
|
||||
and creating a tar archive of the [dtr-registry volume](../architecture.md):
|
||||
|
||||
|
@ -149,3 +153,5 @@ gpg -d {{ metadata_backup_file }} | tar -t
|
|||
You can also create a backup of a UCP cluster and restore it into a new
|
||||
cluster. Then restore DTR on that new cluster to confirm that everything is
|
||||
working as expected.
|
||||
|
||||
{% endif %}
|
|
@ -3,10 +3,15 @@ title: DTR disaster recovery overview
|
|||
description: Learn the multiple disaster recovery strategies you can use with
|
||||
Docker Trusted Registry.
|
||||
keywords: dtr, disaster recovery
|
||||
ui_tabs:
|
||||
- version: dtr-2.5
|
||||
orlower: true
|
||||
---
|
||||
{% if include.version=="dtr-2.5" %}
|
||||
|
||||
Docker Trusted Registry is a clustered application. You can join multiple
|
||||
replicas for high availability.
|
||||
|
||||
For a DTR cluster to be healthy, a majority of its replicas (n/2 + 1) need to
|
||||
be healthy and be able to communicate with the other replicas. This is also
|
||||
known as maintaining quorum.
|
||||
|
@ -22,6 +27,7 @@ healthy and able to communicate with one another.
|
|||
|
||||
In this example the DTR cluster has five replicas but one of the nodes stopped
|
||||
working, and the other has problems with the DTR overlay network.
|
||||
|
||||
Even though these two replicas are unhealthy the DTR cluster has a majority
|
||||
of replicas still working, which means that the cluster is healthy.
|
||||
|
||||
|
@ -56,3 +62,5 @@ backup. Restoring from a backup should be only used as a last resort, since
|
|||
doing an emergency repair might prevent some data loss.
|
||||
|
||||
[Learn how to restore from a backup](restore-from-backup.md).
|
||||
|
||||
{% endif %}
|
|
@ -2,8 +2,18 @@
|
|||
title: Repair a cluster
|
||||
description: Learn how to repair DTR when the majority of replicas are unhealthy.
|
||||
keywords: dtr, disaster recovery
|
||||
ui_tabs:
|
||||
- version: dtr-2.5
|
||||
orlower: true
|
||||
next_steps:
|
||||
- path: create-a-backup/
|
||||
title: Create a backup
|
||||
- path: restore-from-backup/
|
||||
title: Restore from an existing backup
|
||||
---
|
||||
|
||||
{% if include.version=="dtr-2.5" %}
|
||||
|
||||
For a DTR cluster to be healthy, a majority of its replicas (n/2 + 1) need to
|
||||
be healthy and be able to communicate with the other replicas. This is known
|
||||
as maintaining quorum.
|
||||
|
@ -46,7 +56,7 @@ Start by finding the ID of the DTR replica that you want to repair from.
|
|||
You can find the list of replicas by navigating to the UCP web UI, or by using
|
||||
a UCP client bundle to run:
|
||||
|
||||
```
|
||||
```bash
|
||||
{% raw %}
|
||||
docker ps --format "{{.Names}}" | grep dtr
|
||||
|
||||
|
@ -57,7 +67,7 @@ docker ps --format "{{.Names}}" | grep dtr
|
|||
|
||||
Then, use your UCP client bundle to run the emergency repair command:
|
||||
|
||||
```
|
||||
```bash
|
||||
{% raw %}
|
||||
docker run -it --rm {{ page.dtr_org }}/{{ page.dtr_repo }}:{{ page.dtr_version }} emergency-repair \
|
||||
--ucp-insecure-tls \
|
||||
|
@ -75,7 +85,4 @@ If the emergency repair command fails, try running it again using a different
|
|||
replica ID. As a last resort, you can restore your cluster from an existing
|
||||
backup.
|
||||
|
||||
## Where to go next
|
||||
|
||||
* [Create a backup](create-a-backup.md)
|
||||
* [Restore from an existing backup](restore-from-backup.md)
|
||||
{% endif %}
|
|
@ -2,8 +2,16 @@
|
|||
title: Repair a single replica
|
||||
description: Learn how to repair a single DTR replica when it is unhealthy.
|
||||
keywords: dtr, disaster recovery
|
||||
ui_tabs:
|
||||
- version: dtr-2.5
|
||||
orlower: true
|
||||
next_steps:
|
||||
- path: ../disaster-recovery/
|
||||
title: Disaster recovery overview
|
||||
---
|
||||
|
||||
{% if include.version=="dtr-2.5" %}
|
||||
|
||||
When one or more DTR replicas are unhealthy but the overall majority
|
||||
(n/2 + 1) is healthy and able to communicate with one another, your DTR
|
||||
cluster is still functional and healthy.
|
||||
|
@ -57,7 +65,7 @@ replicas you want to remove.
|
|||
You can find this in the **Stacks** page of the UCP web UI, or by using the UCP
|
||||
client bundle to run:
|
||||
|
||||
```
|
||||
```bash
|
||||
{% raw %}
|
||||
docker ps --format "{{.Names}}" | grep dtr
|
||||
|
||||
|
@ -100,6 +108,4 @@ docker run -it --rm \
|
|||
|
||||
[Learn more about high availability](../configure/set-up-high-availability.md).
|
||||
|
||||
## Where to go next
|
||||
|
||||
* [Disaster recovery overview](index.md)
|
||||
{% endif %}
|
|
@ -2,7 +2,11 @@
|
|||
title: Restore from a backup
|
||||
description: Learn how to restore a DTR cluster from an existing backup
|
||||
keywords: dtr, disaster recovery
|
||||
ui_tabs:
|
||||
- version: dtr-2.5
|
||||
orlower: true
|
||||
---
|
||||
{% if include.version=="dtr-2.5" %}
|
||||
|
||||
{% assign metadata_backup_file = "dtr-metadata-backup.tar" %}
|
||||
{% assign image_backup_file = "dtr-image-backup.tar" %}
|
||||
|
@ -85,4 +89,6 @@ Where:
|
|||
If you're scanning images, you now need to download the vulnerability database.
|
||||
|
||||
After you successfully restore DTR, you can join new replicas the same way you
|
||||
would after a fresh installation. [Learn more](configure/set-up-vulnerability-scans.md).
|
||||
would after a fresh installation. [Learn more](../configure/set-up-vulnerability-scans.md).
|
||||
|
||||
{% endif %}
|
Loading…
Reference in New Issue