Backup

Magnolia Backup is a module that ensures proper backup of data from inside of Magnolia. This module is an alternative to File System and/or Database Backup solutions. Magnolia backup module is available in Magnolia EE 3.6 and higher.

Features

  • Immediate interactive backup of JackRabbit backed repositories
  • Scheduled recurring backup support with cron like configuration options

Installing Backup

See the general module installation instructions. Additionally, backup and restore scripts are found in the bin directory.

Uninstalling Backup

Remove the /modules/backup node and its subnodes. Shutdown Magnolia, remove the module' jar from WEB-INF/lib and start up Magnolia again.

Usage

Go to Tools/Backup menu, enter the target path for backup and hit the Backup button. The target path will be created if it doesn't exist.

To configure scheduled backup go to /modules/backup/config/ and create a new entry. See preconfigured weekly backup task as a reference. Setting backup time and recurrence is done using cron-like date/time selection pattern for the scheduler.

Restore

The restore is meant to recreate the instance, not to patch existing one. For it to work correctly you have to clean your database schema before running it. To restore the previously backed up data, use the restore script from the backup module bundle:

./bin/restore -backup /path/to/backup/backup_0812305_1234 -webapp /path/to/magnolia/webapp
You can omit the -webapp parameter if you are running restore from the webapp directory. To make sure the webapp directory is properly setup before running the restore we recommend you take the war file or webapp from the bundle, add all your custom modules, startup the server once and perform the installation. After that, shutdown the server, delete the repositories directory and run the restore as specified above.

Tip

Backup data do not contain search indexes those are created on the fly while running restore. Indexer runs asynchronously and it might happen the indexer is not finished when restore is done. This leads to situation where not all indexes are yet generated after restore. It is therefore recommended to remove all the indexes before starting up restored instance to make sure those are freshly generated on startup (might take couple of minutes). To remove indexes just delete all index folders from the workspaces. On unix systems you can do so by executing rm -rf repositories/magnolia/workspaces/*/index.

Another thing to notice is the fact that during restore all entries are reinserted into database sequentially. This ensures restored database is not fragmented and usually slighter smaller then equivalent database before backup.

Warning

The backup files contain not only the data, but also information on how to connect to the database, you should therefore keep your backup files at secure location.

Tip

You can use the backup/restore to migrate your data to another PersistenceManager (and therefore also to another database should you see the need to do so). To change the PersistenceManager configuration into which restore script will try to restore the database, unzip all the entries from the repoConf.zip file (you can find this file inside of each backup folder) and change PM configuration in each file as appropriate. Then zip all the files back and run the restore.

If you are interested in what the backup consists of, here is some description of various backup files:

  • repoConf.zip - all configuration files necessary to restore the repositories.
  • history.gz - versions of all versionable content from all repositories
  • <workspace_name>.gz - one file per workspace. Holds all the content of given workspace
  • blobs - folder with binary data from all the workspaces.
Warning

For safety reasons we recommend you try to run the restore from time to time on test system to verify validity of the backup files. Depending on the amount of data changed over the time you might want to do so every month or every quarter of year.