Create an MSR backup

MSR supports automatic backup scheduling (recommended) as well as performing backups manually (legacy).

Data managed by MSR

The table that follows describes the various data types that MSR manages, and indicates which data types are backed up when you perform either an automatic or a manual backup.

Data

Automatic

Manual

Description

Configurations

Yes

Yes

MSR settings.

Repository metadata

Yes

Yes

Metadata about the repositories, charts, and images deployed, such as architecture and size.

Access control to repos and images

Yes

Yes

Permissions for teams and repositories.

Notary data

Yes

Yes

Signatures and digests for images that are signed.

Scan results

Yes

Yes

Information about security vulnerabilities in your images.

Image and chart content

Yes, when fullBackup is set to true. No, otherwise

No

The images and charts that have been stored in MSR within a repository; must be backed up separately, depending on the MSR configuration.

Users, orgs, teams

Yes

Yes

The data related to users, orgs, and teams that MSR backs up.

Vulnerability database

No

No

Database of vulnerabilities, which you can re-download following a restore operation.

Automatically back up MSR

Available since MSR 3.1.0

To schedule automatic backups, you must use the MSR web UI to enable and configure the SMTP setting.

  1. Log in to the MSR web UI.

  2. In the left-side navigation panel, click System to display the System pane.

  3. In the General tab, scroll down to SMTP Settings.

  4. Toggle the Enable SMTP control to the right.

  5. Enter the appropriate information into the following fields:

    • User

    • Password

    • Server Address

    • Server Port

    • Sender Address

  6. Click Save.

  7. Schedule automatic backups and backup purges using either the MSR web UI or the MSR API:

    1. In the left-side navigation panel, click System to display the System pane.

    2. Navigate to the Backups tab and click Edit.

    3. Toggle the Enable Backups control to the right.

    4. Click the Backup Type dropdown and select either Full or Metadata Only.

    5. Select Daily, Weekly, or Monthly to set the frequency with which backups are performed.

      Alternatively, you can set the schedule in the schedule (cron syntax) field using the Cronjob format.

      Note

      You can schedule a single automatic backup using either relative or absolute scheduling.

      • To schedule the backup for the beginning of the next hour:

        "schedule": "0 0 * * * *"
        
      • To schedule the backup for a specific time:

        "schedule": "0 30 17 6 OCT *"
        

      To perform only one backup, you must disable automatic backup scheduling after the backup completes.

    6. Optional. In the Email Notification List field, include the email addresses to which you want automatic backup notifications to be sent.

    7. Optional. Configure automatic backup purges.

      1. Toggle the Purge past backups control to the right.

      2. In the Keep backups for field, input the desired number of Days, Weeks, or Months to retain backups.

      3. Select the relevant unit of time.

    8. Click Save.

    1. Schedule automatic backups by performing a PUT request to the /api​/v0​/meta​/settings​/backup endpoint.

      The following example configuration performs a backup every minute and purges backups that are an hour old:

      {
        "enabled": true,
        "fullBackup": true,
        "distributionList": "<list-of-emails>",
        "schedule": "* * * * *",
        "purge": {
          "enabled": true,
          "duration": "1h0m0s"
        }
      }
      

      The schedule value must be entered in the Cronjob format.

      Note

      You can schedule a single automatic backup using either relative or absolute scheduling.

      • To schedule the backup for the beginning of the next hour:

        "schedule": "0 0 * * * *"
        
      • To schedule the backup for a specific time:

        "schedule": "0 30 17 6 OCT *"
        

      To perform only one backup, you must disable automatic backup scheduling after the backup completes.

    2. Verify your backup schedule by performing a GET request to the /api​/v0​/meta​/settings​/backup endpoint.

  8. Verify the success of your backup and purge jobs:

    1. In the MSR web UI, navigate to System in the left-side navigation panel.

    2. On the Job Logs tab, select the Action dropdown to filter out everything except backup jobs.

    3. Review the backup job logs to verify that your backups have the done status.

    4. On the Job Logs tab, select the Action dropdown to filter out everything except backup_purge jobs.

    5. Review the backup job logs to verify that your backup purges have the done status.

Manually back up MSR

The creation of a complete MSR backup requires that you back up both the contents of repositories (such as images and charts) and the metadata MSR manages.

Back up image content

Note

As you can configure MSR for several types of storage back ends, the method for backing up images and charts will vary. The example we offer is for persistentVolume. If you are using a different storage back end, such as a cloud provider, you should adhere to the recommended practices for that system.

When MSR is configured with persistentVolume, images and charts are stored on the local file system or on mounted network storage.

One way you can back up the images and charts data is by creating a tar archive of the data volume that MSR uses. To find the path of the volume, describe the PersistentVolume associated with the PersistentVolumeClaim:

kubectl get persistentvolumeclaim msr

NAME   STATUS   VOLUME                                     CAPACITY   ACCESS
MODES   STORAGECLASS   AGE msr    Bound
pvc-36c236cb-d5f2-431d-aeb7-76c0de49b17b   10Gi       RWX
standard       17h
k get persistentvolume pvc-36c236cb-d5f2-431d-aeb7-76c0de49b17b -o
jsonpath='{.spec.hostPath.path}'

/tmp/hostpath-provisioner/myns0/msr
sudo tar -cvf /tmp/hostpath-provisioner/myns0/msr

Back up MSR metadata

Use the msr backup command to create a backup of the MSR metadata. The command is present in any API Pod and can be run using the kubectl exec command.

An example follows of how to create a backup for an MSR installation named mymsr. The backup contents are streamed to standard output, which is redirected locally to the file backup.tar.

kubectl exec -i deployment/mymsr-api -- msr backup - > backup.tar

Optionally, you can exclude scanned images and layers from the backup by adding the --ignore-scan-data flag to the command:

kubectl exec -i deployment/msr-api -- msr backup --ignore-scan-data - > backup.tar

Note

If your backup file contains sensitive information, you may want to encrypt it.

Back up Swarm

Run the following command to back up Swarm:

docker container exec $(docker ps -q --filter "name=msr-api") msr backup - > msr_backup.tar

Optionally, you can exclude scanned images and layers from the backup by adding the --ignore-scan-data flag to the command:

docker container exec $(docker ps -q --filter "name=msr-api") msr backup --ignore-scan-data - > msr_backup.tar

Test your backup

To validate your backup, print and review the contents of the created tar file:

tar -tf backup.tar

You can also test your backup by restoring it to a new MSR instance Restore from backup.