Restore from an MSR backup¶
If a majority of the RethinkDB table replicas in use by MSR are unhealthy and you are unable to run a successful emergency repair, you will have to restore the cluster from a backup.
To restore MSR:
Confirm installation of the version of MSR that corresponds to the one in use when the backup was made.
Restore the images and charts content.
Restore MSR metadata from a backup created using the msr backup command.
Register MSR with eNZi.
Download the vulnerability database.
Install corresponding MSR version¶
A running instance of MSR must be set up before you can restore from a backup, to serve as the restore target, and that MSR instance must be the same version as the one from which the backup was created.
Restore images and charts¶
If you had MSR configured to store images on the local filesystem, you can extract your backup:
sudo tar -xf image-backup.tar -C /var/lib/docker/volumes
If you are using a different storage backend, adhere to the best practices recommended for that system.
Restore MSR metadata from a backup¶
Use the msr restore command to restore MSR metadata from a previously created backup. The command is present in any API Pod and can be run using the kubectl exec command.
The following is an example of restoring onto an MSR installation named
mymsr. The backup contents are streamed from standard input, which receives
its data from the local file
Register MSR with eNZi (auth service)¶
When you restore MSR from a backup it must then be re-registered with eNZi, which you can do using the msr auth register admin command.
Re-fetch the vulnerability database¶
If you enable image scanning, you must re-download the vulnerability database following any successful restore operation.