mirantis/dtr restore¶
Install and restore MSR from an existing backup
Usage¶
docker run -i --rm mirantis/dtr \
restore
--replica-id <replica-id>
[command options] < backup.tar
Description¶
The restore command performs a fresh installation of MSR, and
reconfigures it with configuration data from a tar
file generated by
mirantis/dtr backup
. If you are restoring MSR after a failure, please make
sure you have destroyed the old MSR fully.
There are three actions you can take to recover an unhealthy MSR cluster:
If the majority of replicas are healthy, remove the unhealthy nodes from the cluster, and join new nodes for high availability.
If the majority of replicas are unhealthy, use the emergency-repair command to revert your cluster to a single MSR replica.
If you cannot repair your cluster to a single replica, you must 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 MSR installation is configured to store images on the local filesystem or using a cloud provider.
After restoring the cluster, you should use the :command`join` command to add more MSR replicas for high availability.
Options¶
Option |
Environment variable |
Description |
---|---|---|
|
$ASYNC_NFS |
Use async NFS volume options on the replica specified by
|
|
$CLIENT_CA |
PEM-encoded TLS root CA certificates for client certificate authentication. |
|
$CUSTOM_CA_CERTS_BUNDLE |
Provide a file containing additional CA certificates for MSR service containers to use when verifying TLS server certificates. |
|
$DEBUG |
Enable debug mode for additional logs. |
|
$MSR_REPLICA_ID |
The ID of an existing MSR replica. To add, remove or modify MSR, you must connect to an existing healthy replica’s database. |
|
$MSR_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 |
|
$MSR_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 |
|
$MSR_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 |
|
$MSR_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 |
|
$MSR_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. |
|
$MSR_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. When running 2.6.0 to 2.6.3 (with experimental online garbage collection), 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 2.6.4 and follow Best practice for data migration in 2.6.4 when switching storage backends. |
|
$ENABLE_CLIENT_CERT_AUTH |
Enables TLS client certificate authentication; use
|
|
$MSR_PPROF |
Enables pprof profiling of the server. Use |
|
$MSR_EXTENDED_HELP |
Display extended help text for a given command. |
|
$MSR_HTTP_PROXY |
The HTTP proxy used for outgoing requests. |
|
$MSR_HTTPS_PROXY |
The HTTPS proxy used for outgoing requests. |
|
$LOG_HOST |
The syslog system to send logs to.The endpoint to send logs to. Use this
flag if you set |
|
$LOG_LEVEL |
Log level for all container logs when logging to syslog. Default:
|
|
$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
|
|
$MAX_WAIT |
The maximum amount of time MSR allows an operation to complete within.
This is frequently used to allocate more startup time to very large MSR
databases. The value is a Golang duration string. For example, |
|
$NFS_OPTIONS |
Pass in NFS volume options verbatim for the replica specified by
|
|
$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.6.0-2.6.3 (with
experimental online garbage collection), there is an issue with
reconfiguring and restoring MSR with |
|
$MSR_NO_PROXY |
List of domains the proxy should not be used for.When using
|
|
$REPLICA_HTTP_PORT |
The public HTTP port for the MSR replica. Default is |
|
$REPLICA_HTTPS_PORT |
The public HTTPS port for the MSR replica. Default is |
|
$MSR_INSTALL_REPLICA_ID |
Assign a 12-character hexadecimal ID to the MSR replica. Mandatory. |
|
$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 |
|
$UCP_CA |
Use a PEM-encoded TLS CA certificate for MKE. Download the MKE TLS CA
certificate from |
|
$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_NODE |
The hostname of the MKE node to use 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. Note that MKE and MSR must not be installed on the same node, and thus you should instead install MSR on worker nodes that will be managed by MKE. |
|
$UCP_PASSWORD |
The MKE administrator password. |
|
$UCP_URL |
The MKE URL including domain and port. |
|
$UCP_USERNAME |
The MKE administrator username. |