Create a backup

Data managed by MSR

Mirantis Secure Registry maintains data about:




The MSR cluster configurations.

Repository metadata

The metadata about the repositories and images deployed.

Access control to repos and images

Permissions for teams and repositories.

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 MSR. This can be stored on the file system of the node running MSR, or other storage system, depending on the configuration.

This data is persisted on the host running MSR, using named volumes.

To perform a backup of a MSR node, run the mirantis/dtr backup <msr-cli-backup> command. This command backs up the following data:


Backed up




MSR settings

Repository metadata


Metadata such as image architecture and size

Access control to repos and images


Data about who has access to which images

Notary data


Signatures and digests for images that are signed

Scan results


Information about vulnerabilities in your images

Certificates and keys


TLS certificates and keys used by MSR

Image content


Needs to be backed up separately, depends on MSR configuration

Users, orgs, teams


Create a MKE backup to back up this data

Vulnerability database


Can be redownloaded after a restore

Back up MSR data

To create a backup of MSR, you need to:

  1. Back up image content

  2. Back up MSR metadata

You should always create backups from the same MSR replica, to ensure a smoother restore. If you have not previously performed a backup, the web interface displays a warning for you to do so:


Find your replica ID

Since you need your MSR replica ID during a backup, the following covers a few ways for you to determine your replica ID:

MKE web interface

You can find the list of replicas by navigating to Shared Resources > Stacks or Swarm > Volumes (when using swarm mode) on the MKE web interface.

MKE client bundle

From a terminal using a MKE client bundle, run:

docker ps --format "{{.Names}}" | grep dtr

# The list of MSR containers with <node>/<component>-<replicaID>, e.g.
# node-1/dtr-api-a1640e1c15b6

SSH access

Another way to determine the replica ID is to log into a MSR node using SSH and run the following:

REPLICA_ID=$(docker ps --format '{{.Names}}' -f name=dtr-rethink | cut -f 3 -d '-') && echo $REPLICA_ID

Back up image content

Since you can configure the storage backend that MSR uses to store images, the way you back up images depends on the storage backend you’re using.

If you’ve configured MSR to store images on the local file system or NFS mount, you can back up the images by using SSH to log in to an MSR node, and creating a tar archive of the MSR volume.

Example backup command for local images:

sudo tar -cvf image-backup.tar /var/lib/docker/volumes/dtr-registry-<replica-id>

Expected system response:

tar: Removing leading '/' from member names

If you’re using a different storage backend, follow the best practices recommended for that system.

Back up MSR metadata

To create a MSR backup, load your MKE client bundle, and run the following command.

Chained commands (Linux only):

DTR_VERSION=$(docker container inspect $(docker container ps -f name=dtr-registry -q) | \ >   grep -m1 -Po '(?<=DTR_VERSION=)\d+.\d+.\d+'); \
REPLICA_ID=$(docker ps --format '{{.Names}}' -f name=dtr-rethink | cut -f 3 -d '-'); \
read -p 'mke-url (The MKE URL including domain and port): ' UCP_URL; \
read -p 'mke-username (The MKE administrator username): ' UCP_ADMIN; \
read -sp 'mke password: ' UCP_PASSWORD; \
docker run --log-driver none -i --rm \
  mirantis/dtr:$DTR_VERSION backup \
  --ucp-username $UCP_ADMIN \
  --ucp-url $UCP_URL \
  --ucp-ca "$(curl https://${UCP_URL}/ca)" \
  --existing-replica-id $REPLICA_ID > dtr-metadata-${DTR_VERSION}-backup-$(date +%Y%m%d-%H_%M_%S).tar

MKE field prompts

  • <mke-url> is the URL you use to access MKE.

  • <mke-username> is the username of a MKE administrator.

  • <mke-password> is the password for the indicated MKE administrator.

The above chained commands run through the following tasks:

  1. Sets your MSR version and replica ID. To back up a specific replica, set the replica ID manually by modifying the --existing-replica-id flag in the backup command.

  2. Prompts you for your MKE URL (domain and port) and admin username.

  3. Prompts you for your MKE password without saving it to your disk or printing it on the terminal.

  4. Retrieves the CA certificate for your specified MKE URL. To skip TLS verification, replace the --ucp-ca flag with --ucp-insecure-tls. Docker does not recommend this flag for production environments.

  5. Includes MSR version and timestamp to your tar backup file.


To ensure constant user access to MSR, by default the backup command does not pause the MSR replica that is undergoing the backup operation. As such, you can continue to make changes to the replica, however those changes will not be saved into the backup. To circumvent this behavior, use the --offline-backup option and be sure to remove the replica from the load balancing pool to avoid user interruption.

As the backup contains sensitive information (for example, private keys), you can encrypt it by running:

gpg --symmetric {{ metadata_backup_file }}

This prompts you for a password to encrypt the backup, copies the backup file and encrypts it.

Refer to mirantis/dtr backup for more information on supported command options.

Test your backups

To validate that the backup was correctly performed, you can print the contents of the tar file created. The backup of the images should look like:

tar -tf {{ images_backup_file }}


And the backup of the MSR metadata should look like:

tar -tf {{ metadata_backup_file }}

# The archive should look like this

If you’ve encrypted the metadata backup, you can use:

gpg -d {{ metadata_backup_file }} | tar -t

You can also create a backup of a MKE cluster and restore it into a new cluster. Then restore MSR on that new cluster to confirm that everything is working as expected.