Create a backup¶

Data managed by MSR¶

Mirantis Secure Registry data persists on the host on which MSR is running, using named volumes.

Run the mirantis/dtr backup command to back up the following MSR node data:

Backed up MSR data¶
Data type	Description
Configurations	The MSR cluster configuration settings.
Repository metadata	Metadata on the deployed repositories and images, such as image architecture and size.
Access control to repos and images	Permissions for teams and repositories, pertaining to who has access to which images.
Notary data	Notary tags and signatures, as applicable to images that are signed.
Scan results	Image security scanning results, pertaining to vulnerabilities in your images.
Certificates and keys	The certificates, public keys, and private keys in use by MSR for mutual TLS communication.
Images content	The images you push to MSR. This data can either be stored on the file system of the node that is running MSR, or depending on the configuration it can be stored on a different storage system.

Note

A number of data types are not backed up as when you run mirantis/dtr backup, including:

Image content, which must be backed up separately, depending on the MSR configuration.
User, organization, and teams information, the backup for which must be made as part of your MKE backup.
Vulnerability database, which can be redownloaded following a restore operation.

Back up MSR data¶

To create a full backup of MSR you must back up both the image content and MSR metadata.

To ensure the smoothest possible restore, Mirantis recommends that you create your MSR backups from the same MSR replica.

Locate your replica ID¶

You need your MSR replica ID to create a backup. You can determine your replica ID through the MKE web UI, using the MKE client bundle, or by accessing an MSR node with SSH and running a command.

To locate your replica ID through the MKE web UI:

Navigate to Shared Resources > Stacks or Swarm > Volumes (when using swarm mode).

To locate your replica ID using the MKE client bundle:

From a terminal that uses an 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

To locate your replica ID using SSH to access an MSR node:

Run the following command:

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

Back up image content¶

The way you back up images depends on which storage backend you use.

To back up images when MSR is configured to store images on a local file system or NFS mount:

Use SSH to log in to an MSR node.
Create a tar archive of the MSR volume.

Note

The following command will result in the creation of an image backup of your MSR, {{ images_backup_file }}.
```
sudo tar -cvf image-backup.tar /var/lib/docker/volumes/dtr-registry-<replica-id>
```

If you are using a different storage backend, follow the best practices recommended for the particular system.

Back up MSR metadata¶

Code variable definitions¶
`<mke-url>`	URL to access MKE, including the domain name and port number Syntax: `myregistry.com:<port_number>`
`<mke-username>`	MKE administrator user name
`<mke-password>`	Password for the indicated MKE administrator

To create an MSR backup {{ images_backup_file }}, load your MKE client bundle, and run the following chained commands on the MSR node.

Note

Chained commands apply only to Linux.

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>: ' UCP_URL; \
read -p '<mke-username>: ' UCP_ADMIN; \
read -sp '<mke password>: ' UCP_PASSWORD; \
docker run --log-driver none -i --rm \
  --env UCP_PASSWORD=$UCP_PASSWORD \
  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

The chained commands detailed above perform the following tasks:

Set your MSR version and replica ID.

To back up a specific replica, modify the --existing-replica-id flag in the backup command to manually set the replica ID.
Prompt for the <mke-url> and <mke-username>.
Prompt for your <mke password> without saving it to your disk or printing it to the terminal.
Retrieve the CA certificate for the specified <mke-url>.

To skip TLS verification, replace the --ucp-ca flag with --ucp-insecure-tls. Mirantis does not recommend this flag for production environments.
Include the MSR version and timestamp in your tar backup file.

Important

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, such as private keys, you may opt to encrypt it. To do so, run:

gpg --symmetric {{ metadata_backup_file }}

This command 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 backup¶

Publish the contents of the new tar file to validate that your MSR backup was correctly performed:

tar -tf {{ images_backup_file }}

dtr-backup-v2.9.21/
dtr-backup-v2.9.21/rethink/
dtr-backup-v2.9.21/rethink/layers/

The backup of the MSR metadata should present as follows:

tar -tf {{ metadata_backup_file }}

# The archive should look like this
dtr-backup-v2.9.21/
dtr-backup-v2.9.21/rethink/
dtr-backup-v2.9.21/rethink/properties/
dtr-backup-v2.9.21/rethink/properties/0

Use the following command if you have encrypted the metadata backup:

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

Alternatively, you can create a backup of an MKE cluster and restore it to a new cluster, and then restore MSR on the new cluster to confirm your MSR backup.