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
kubectl exec -i deployment.apps/mymsr-api -- msr restore - < backup.tar
Register MSR with eNZi (auth service)¶
Whenever you restore MSR from a backup, you must register the software with eNZi.
Run the msr auth register admin command:
kubectl exec -i deployment.apps/mymsr-api -- msr auth register --username admin -p password https://mymsr-enzi:4443/enzi
Restart MSR Pods:
kubectl rollout restart deployment mymsr-api mymsr-enzi-api mymsr-garant mymsr-registry
Re-fetch the vulnerability database¶
If you enable image scanning, you must re-download the vulnerability database following any successful restore operation.
Where to go next¶