Backup and Restore
Each component of the RapidMiner platform has a different need for backing up and restoring user data and platform configuration. On this page we explain what these items are, and how each of them can be backed up and restored, if needed.
Things to back up
The following table summarizes what are artifacts that should be considered in a backup scenario. You can choose which of these to perform a backup for based on your company policies, backup limitations, and mission criticality.
|Component||Items to consider for backup (default locations)|
|Platform definition||.env and docker-compose.yml files|
|KeyCloak database|| Contents of the docker volume
|RapidMiner Server database|| Contents of the folder
|RapidMiner Server home folder|| Contents of the folder
|Python environments and RTS deployment definitions|| Contents of the docker volume
|JupyterHub database|| Contents of the docker volume
|JupyterHub user folders|| Contents of the docker volumes conforming to the pattern
|Dashboard definitions|| Contents of the docker volume
|ModelOps deployment definitions|| Contents of the docker volume
Please read and consider the below caveats when performing backup and restore procedures on the RapidMiner Platform:
- Backing up a consistent state of the RapidMiner Platform can only be done when it's taken offline. You can do this by executing
docker-compose downon the host machine. Once the services have stopped, you can proceed with the backup. To ensure this doesn't affect critical operation, we recommend scheduling this procedure for maintenance windows, when normal operation is unaffected.
- It is important that the backup is done using tools that handle and conserve Linux file system metadata (user and group information, permissions, etc.). Otherwise the produced backup will be unusable.