Install and restore MSR from an existing backup
docker run -i --rm mirantis/dtr \
restore [command options] < backup.tar
This command performs a fresh installation of MSR, and reconfigures it
with configuration data from a tar
file generated by
`mirantis/dtr backup
<backup.md>`__. If you are restoring MSR after a
failure, please make sure you have destroyed the old MSR fully.
There are three steps you can take to recover an unhealthy MSR cluster:
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 MSR 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 MSR replicas for high availability.
Option | Environment variable | Description |
---|---|---|
--debug |
$DEBUG | Enable debug mode for additional logs. |
--dtr-ca |
$DTR_CA | Use a PEM-encoded TLS CA certificate for MSR. By default MSR 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 MSR. By default MSR 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 MSR. When you use
this flag, users are redirected to MKE for logging in. Once
authenticated they are redirected to the URL you specify in this flag.
If you don’t use this flag, MSR is deployed without single sign-on with
MKE. Users and teams are shared but users log in separately into the two
applications. You can enable and disable single sign-on within your MSR
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 MSR. By default MSR 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 MSR to fall back to your configured storage setting at the time of backup. If you have previously configured MSR to use a full path or volume name for storage, specify this flag to use the same setting on restore. See mirantis/dtr install and mirantis/dtr reconfigure for usage details. |
--dtr-use-default-storage |
$DTR_DEFAULT_STORAGE | Mandatory flag to allow for MSR 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 MSR 2.6.0-2.6.3, this flag must be specified in order to keep your MSR metadata. If you encounter an issue with lost tags, see Restore to Cloud Storage for Docker’s recommended recovery strategy. Upgrade to MSR 2.6.4 and follow Best practice for data migration in MSR 2.6.4 when switching storage backends. |
--nfs-storage-url |
$NFS_STORAGE_URL | Mandatory flag to allow for MSR to fall back to your configured storage
setting at the time of backup. When running DTR 2.5 (with experimental
online garbage collection) and MSR 2.6.0-2.6.3, there is an issue with
reconfiguring and restoring DTR with --nfs-storage-url which leads
to erased tags. Make sure to back up your 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
for more details. For additional NFS configuration options to support
NFS v4, see mirantis/dtr install and mirantis/dtr reconfigure.
Upgrade to MSR 2.6.4 and follow Best practice for data migration in MSR
2.6.4 when switching storage backends. |
--enable-pprof |
$DTR_PPROF | Enables pprof profiling of the server. Use --enable-pprof=false to
disable it. Once MSR 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, MSR
internal components log information using the logger specified in the
Docker daemon in the node where the MSR replica is deployed. Use this
option to send MSR logs to an external syslog system. The supported
values are tcp, udp, and internal. Internal is the default option,
stopping MSR 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 MSR replica. Default is 80 . This allows
you to customize the HTTP port where users can reach MSR. 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 MSR replica. Default is 443 . This
allows you to customize the HTTPS port where users can reach MSR. Each
replica can use a different port. |
--replica-id |
$DTR_INSTALL_REPLICA_ID | Assign a 12-character hexadecimal ID to the MSR 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 MKE. Download the MKE TLS CA
certificate from https://<mke-url>/ca , and use --ucp-ca "$(cat
ca.pem)" . |
--ucp-insecure-tls |
$UCP_INSECURE_TLS | Disable TLS verification for MKE. The installation uses TLS but always
trusts the TLS certificate used by MKE, 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 MKE node to deploy MSR. Random by default. You can
find the hostnames of the nodes in the cluster in the MKE web interface,
or by running docker node ls on a MKE manager node. |
--ucp-password |
$UCP_PASSWORD | The MKE administrator password. |
--ucp-url |
$UCP_URL | The MKE URL including domain and port. |
--ucp-username |
$UCP_USERNAME | The MKE administrator username. |