--- title: docker/dtr restore description: Install and restore DTR from an existing backup keywords: dtr, cli, restore --- Install and restore DTR from an existing backup ## Usage ```bash docker run -i --rm docker/dtr \ restore [command options] < backup.tar ``` ## Description This command performs a fresh installation of DTR, and reconfigures it with configuration data from a `tar` file generated by [`docker/dtr backup`](backup.md). If you are restoring DTR after a failure, please make sure you have destroyed the old DTR fully. See [DTR disastery recovery](/ee/dtr/admin/disaster-recovery/) for Docker's recommended recovery strategies based on your setup. There are three steps you can take to recover an unhealthy DTR cluster: 1. If the majority of replicas are healthy, remove the unhealthy nodes from the cluster, and join new nodes for high availability. 2. If the majority of replicas are unhealthy, use the [`emergency-repair`](./emergency-repair/) command to revert your cluster to a single DTR replica. 3. If you can't repair your cluster to a single replica, you'll have to restore from an existing backup, using the `restore` command. This command does not restore Docker images. You should implement a separate restore procedure for the Docker images stored in your registry, taking in consideration whether your DTR installation is configured to store images on the local filesystem or using a cloud provider. After restoring the cluster, you should use the `join` command to add more DTR replicas for high availability. ## Options | Option | Environment Variable | Description | |:------------------------------|:--------------------------|:-------------------------------------------------------------------------------------| | `--debug` | $DEBUG | Enable debug mode for additional logs. | | `--dtr-ca` | $DTR_CA | Use a PEM-encoded TLS CA certificate for DTR. By default DTR generates a self-signed TLS certificate during deployment. You can use your own TLS CA certificate with `--dtr-ca "$(cat ca.pem)"`. | | `--dtr-cert` | $DTR_CERT | Use a PEM-encoded TLS certificate for DTR. By default DTR generates a self-signed TLS certificate during deployment. You can use your own TLS certificate with `--dtr-cert "$(cat ca.pem)"`. | | `--dtr-external-url` | $DTR_EXTERNAL_URL | URL of the host or load balancer clients use to reach DTR. When you use this flag, users are redirected to UCP for logging in. Once authenticated they are redirected to the URL you specify in this flag. If you don't use this flag, DTR is deployed without single sign-on with UCP. Users and teams are shared but users log in separately into the two applications. You can enable and disable single sign-on within your DTR system settings. Format `https://host[:port]`, where port is the value you used with `--replica-https-port`. | | `--dtr-key` | $DTR_KEY | Use a PEM-encoded TLS private key for DTR. By default DTR generates a self-signed TLS certificate during deployment. You can use your own TLS private key with `--dtr-key "$(cat ca.pem)"`. | | `--dtr-storage-volume` | $DTR_STORAGE_VOLUME | Mandatory flag to allow for DTR to fall back to your configured storage setting at the time of backup. If you have previously configured DTR to use a full path or volume name for storage, specify this flag to use the same setting on restore. See [docker/dtr install](install.md) and [docker/dtr reconfigure](reconfigure.md) for usage details. | | `--dtr-use-default-storage` | $DTR_DEFAULT_STORAGE | Mandatory flag to allow for DTR to fall back to your configured storage backend at the time of backup. If cloud storage was configured, then the default storage on restore is cloud storage. Otherwise, local storage is used. With DTR 2.5 (with experimental online garbage collection) and 2.6.0-2.6.3, this flag must be specified in order to keep your DTR metadata. If you encounter an issue with lost tags, see [Restore to Cloud Storage](https://success.docker.com/article/dtr-26-lost-tags-after-reconfiguring-storage#restoretocloudstorage) for Docker's recommended recovery strategy. [Upgrade to 2.6.4](/reference/dtr/2.6/cli/upgrade/) and follow [Best practice for data migration in 2.6.4](/ee/dtr/admin/configure/external-storage/storage-backend-migration/#best-practice-for-data-migration) when switching storage backends. | | `--nfs-storage-url` | $NFS_STORAGE_URL | Mandatory flag to allow for DTR to fall back to your configured storage setting at the time of backup. When running DTR 2.5 (with experimental online garbage collection) and 2.6.0-2.6.3, there is an issue with [reconfiguring and restoring DTR with `--nfs-storage-url`](/ee/dtr/release-notes#version-26) which leads to erased tags. Make sure to [back up your DTR metadata](/ee/dtr/admin/disaster-recovery/create-a-backup/#back-up-dtr-metadata) before you proceed. If NFS was previously configured, you have to manually create a storage volume on each DTR node and specify `--dtr-storage-volume` with the newly-created volume instead. See [Restore to a Local NFS Volume](https://success.docker.com/article/dtr-26-lost-tags-after-reconfiguring-storage#restoretoalocalnfsvolume) for more details. For additional NFS configuration options to support **NFS v4**, see [docker/dtr install](install.md) and [docker/dtr reconfigure](reconfigure.md). [Upgrade to 2.6.4](/reference/dtr/2.6/cli/upgrade/) and follow [Best practice for data migration in 2.6.4](/ee/dtr/admin/configure/external-storage/storage-backend-migration/#best-practice-for-data-migration) when switching storage backends. | | `--enable-pprof` | $DTR_PPROF | Enables pprof profiling of the server. Use `--enable-pprof=false` to disable it. Once DTR is deployed with this flag, you can access the `pprof` endpoint for the api server at `/debug/pprof`, and the registry endpoint at `/registry_debug_pprof/debug/pprof`. | | `--help-extended` | $DTR_EXTENDED_HELP | Display extended help text for a given command. | | `--http-proxy` | $DTR_HTTP_PROXY | The HTTP proxy used for outgoing requests. | | `--https-proxy` | $DTR_HTTPS_PROXY | The HTTPS proxy used for outgoing requests. | | `--log-host` | $LOG_HOST | The syslog system to send logs to.The endpoint to send logs to. Use this flag if you set --log-protocol to tcp or udp. | | `--log-level` | $LOG_LEVEL | Log level for all container logs when logging to syslog. Default: `INFO`. The supported log levels are `debug`, `info`, `warn`, `error`, or `fatal`. | | `--log-protocol` | $LOG_PROTOCOL | The protocol for sending logs. Default is internal.By default, DTR internal components log information using the logger specified in the Docker daemon in the node where the DTR replica is deployed. Use this option to send DTR logs to an external syslog system. The supported values are tcp, udp, and internal. Internal is the default option, stopping DTR from sending logs to an external system. Use this flag with --log-host. | | `--no-proxy` | $DTR_NO_PROXY | List of domains the proxy should not be used for.When using --http-proxy you can use this flag to specify a list of domains that you don't want to route through the proxy. Format acme.com[, acme.org]. | | `--replica-http-port` | $REPLICA_HTTP_PORT | The public HTTP port for the DTR replica. Default is `80`. This allows you to customize the HTTP port where users can reach DTR. Once users access the HTTP port, they are redirected to use an HTTPS connection, using the port specified with `--replica-https-port`. This port can also be used for unencrypted health checks. | | `--replica-https-port` | $REPLICA_HTTPS_PORT | The public HTTPS port for the DTR replica. Default is `443`. This allows you to customize the HTTPS port where users can reach DTR. Each replica can use a different port. | | `--replica-id` | $DTR_INSTALL_REPLICA_ID | Assign a 12-character hexadecimal ID to the DTR replica. Random by default. | | `--replica-rethinkdb-cache-mb` | $RETHINKDB_CACHE_MB | The maximum amount of space in MB for RethinkDB in-memory cache used by the given replica. Default is auto. Auto is `(available_memory - 1024) / 2`. This config allows changing the RethinkDB cache usage per replica. You need to run it once per replica to change each one. | | `--ucp-ca` | $UCP_CA | Use a PEM-encoded TLS CA certificate for UCP. Download the UCP TLS CA certificate from `https:///ca`, and use `--ucp-ca "$(cat ca.pem)"`. | | `--ucp-insecure-tls` | $UCP_INSECURE_TLS | Disable TLS verification for UCP. The installation uses TLS but always trusts the TLS certificate used by UCP, which can lead to MITM (man-in-the-middle) attacks. For production deployments, use `--ucp-ca "$(cat ca.pem)"` instead. | | `--ucp-node` | $UCP_NODE | The hostname of the UCP node to deploy DTR. Random by default. You can find the hostnames of the nodes in the cluster in the UCP web interface, or by running `docker node ls` on a UCP manager node. | | `--ucp-password` | $UCP_PASSWORD | The UCP administrator password. | | `--ucp-url` | $UCP_URL | The UCP URL including domain and port. | | `--ucp-username` | $UCP_USERNAME | The UCP administrator username. |