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.

Log in to the MSR web UI.
In the left-side navigation panel, click System to display the System pane.
In the General tab, scroll down to SMTP Settings.
Toggle the Enable SMTP control to the right.
Enter the appropriate information into the following fields:
- User
- Password
- Server Address
- Server Port
- Sender Address
Click Save.
Schedule automatic backups and backup purges using either the MSR web UI or the MSR API:
Web UI
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. In the Backup Deadline field, specify the retention period in minutes or hours. If left empty or set to zero, the deadline defaults to one hour.
8. 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.
9. Click Save.
API
1. Schedule automatic backups by performing a PUT request to the /api/v0/meta/settings/backup endpoint.
  
  In the following configuration example:
  - A backup is performed every minute
  - The backup process is terminated after one hour if the set deadline is reached
  - An hour-old backup is purged
  { "enabled": true, "fullBackup": true, "distributionList": "<list-of-emails>", "schedule": "* * * * *", "deadline": "1h0m0s", "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.
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 backends, the method for backing up images and charts will vary. The example we offer is for persistentVolume. If you are using a different storage backend, 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.