Backup and Restore
@See Restore Web Service
- 1 Overview
- 2 Creating a Backup
- 3 Included in the Backup
- 4 Restoring from a Backup
- 5 Troubleshooting
From FMR 11.3.0 it is possible to restore the live structures and transaction history from another FMR. The restore can only be run at install time. In order to make use of this feature, a Command Line application (FMR-CL) is used to create a backup from a running FMR instance. On installation of FMR 11.3.0 or later, the installation process will enable the FMR to load the backup to restore the state.
Creating a Backup
The backup process requires the FMRCL Command Line Application, which can be downloaded from https://sdmxio.s3.eu-west-2.amazonaws.com/FMRCL/fmr-cl-1.0.0.zip. Note: clicking this link will download a zip file.
The files should not be placed in the webapps folder of the Tomcat.
The command line application creates the backup by issuing requests to the web services of a running FMR instance. The requests must be run as an admin user (or as the root user) from the directory where the file backup.bat has been installed.
The output of a backup request is a folder named "structures" which contains subfolder(s)/files and azip file obtained from the running FMR instance.
./backup.sh -o Backup -u root -p "password" -url "http://localhost:8080/FMR"
backup.bat -o Backup -u root -p "password" -url "http://localhost:8080/FMR"
|o||The output directory that the backup will be written to||-o Backup/Jan|
|u||Username to authenticate with FMR||-u root|
|p||Password to authenticate with FMR||-p password|
|url||URL of running FMR instance||-url http://localhost:8080/FMR|
|v||Version of the FMR which is only required if you are referring to version 10||-v 10|
Included in the Backup
The backup contains:
- current (live) structural metadata from the FMR.
- a history of the structural metadata edits
- the related audit entries for the structure metadata edits
Restoring from a Backup
A backup is restored during the FMR 11 installation process. The FMR 11 install wizard provides the option to include the path on the local file system to the backup folder (or the path to a zip file).
If the backup is being provided as a zip file, the contents of the backup folder must be zipped from within the backup root folder - the zip file should NOT include the root backup folder itself. For example if the -o argument is Backups/BackupFeb, the zip should be created from within the BackupFeb folder (it should contain only the contents of the BackupFeb folder). The zip should not be of the BackupFeb folder itself and its contents.
The time taken to complete the restore process depends on the number and size of the transactions that were backed up. The install wizard initiates the restore process once the Finish button is clicked. The progress of the restore is frequently updated and reported to the user on the install page. Whilst it is possible to close the web browser during the restore process, it is recommended to keep the web browser page open and not to navigate away from the install page. It will not be possible to view the restore progress from the web browser if the browser navigates off the install page. The install wizard will redirect to the FMR overview page once the restoration and installation is complete.
The restore can only be run once, it will not be possible to re-run a restore if there was an error during the restoring of state. The restore can only run against a clean (empty) database schema and as such can only be run on install.
Database type JNDI
You will need to add the new (empty) database base name to the context.xml file (normally found in the conf sub-folder within the tomcat).
It is strongly recommended to check the FMR tomcat log files after a restore is complete to ensure all transactions were successfully restored. It is possible for the restore to complete even if some transactions or audits could not be fully restored - the tomcat log files will contain details if this is the case.
Can not restore from backup - the 'table name' database table must be empty
The above error is returned (where 'table name' wil be replaced with the specific name of a table e.g. sdmx_transaction ) if attempting to restore against a database that already has transactions (structural metadata) within it. Check that you have specified the correct database (on step 1 of the wizard) and if necessary, terminate the Registry, clear all tables from your database schema, and try again.
Restore is either running, or failed part way. Please check the log files. A restore can not be re-run without first emptying the database tables
If this error is displayed it is highly recommended to check your Registry log to see if you can determine what caused the backup to fail. If in doubt, please contact Metadata Technology, supplying the log file for further analysis. To restart the backup process, terminate the Tomcat and then clear out the tables from the database schema. Then restart Tomcat and go through the install process again.