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	$ASYNC_NFS	Use async NFS volume options on the replica specified by --existing-replica-id.
--client-cert-auth-ca	$CLIENT_CA	PEM-encoded TLS root CA certificates for client certificate authentication.
--custom-ca-cert-bundle	$CUSTOM_CA_CERTS_BUNDLE	Provide a file containing additional CA certificates for MSR service containers to use when verifying TLS server certificates.
--debug	$DEBUG	Enable debug mode for additional logs.
--existing-replica-id	$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.
--dtr-ca	$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 --dtr-ca "$(cat ca.pem)".
--dtr-cert	$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 --dtr-cert "$(cat ca.pem)".
--dtr-external-url	$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 https://host[:port], where port is the value you used with --replica-https-port.
--dtr-key	$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 --dtr-key "$(cat ca.pem)".
--dtr-storage-volume	$MSR_STORAGE_VOLUME	Note One of three options you can use for MSR backend storage, the other two being dtr_use-default-storage and nfs_storage_url. The use of one of the three options is mandatory, depending on your setup, to allow for MSR to fall back to the storage setting you configured at the time of backup. If you have previously configured MSR to use a full path or volume name for storage, specify the --dtr-storage-volume option as this will cause MSR to use the same setting on restore. Refer to mirantis/dtr install <msr-cli-install>` and mirantis/dtr reconfigure <msr-cli-reconfigure>` for usage detail.
--dtr-use-default-storage	$MSR_DEFAULT_STORAGE	Note One of three options you can use for MSR backend storage, the other two being dtr_storage-volume and nfs_storage_url. The use of one of the three options is mandatory, depending on your setup, to allow for MSR to fall back to the storage setting you configured at the time of backup. If cloud storage was previously configured, then the default storage on restore is cloud storage. Otherwise, local storage is used.
--nfs-storage-url	$NFS_STORAGE_URL	Note One of three options you can use for MSR backend storage, the other two being dtr_storage-volume and --dtr-use-default-storage. The use of one of the three options is mandatory, depending on your setup, to allow for MSR to fall back to the storage setting you configured at the time of backup. If NFS was previously configured, you must manually create a storage volume on each MSR node and specify --dtr-storage-volume with the newly-created volume instead. For additional NFS configuration options to support NFS v4, refer to mirantis/dtr install and mirantis/dtr reconfigure.
--enable-client-cert-auth	$ENABLE_CLIENT_CERT_AUTH	Enables TLS client certificate authentication; use --enable-client-cert-auth=false to disable it.
--enable-pprof	$MSR_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	$MSR_EXTENDED_HELP	Display extended help text for a given command.
--http-proxy	$MSR_HTTP_PROXY	The HTTP proxy used for outgoing requests.
--https-proxy	$MSR_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.
--max-wait	$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, "10m" represents 10 minutes.
--nfs-options	$NFS_OPTIONS	Pass in NFS volume options verbatim for the replica specified by --existing-replica-id.
--nocolor	$NOCOLOR	Disable output coloring in logs.
--no-proxy	$MSR_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	$MSR_INSTALL_REPLICA_ID	Assign a 12-character hexadecimal ID to the MSR replica. Mandatory.
--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 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 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 an MKE manager node. Note that MKE and MSR must not be installed on the same node, instead install MSR on worker nodes that will be managed by MKE.
--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.