The Backup module ensures the proper backup of data from inside of Magnolia CMS. This module is an alternative to file system and database backup solutions. The module provides immediate interactive backup of JackRabbit backed repositories and scheduled recurring backup support with cron-like configuration options.
- Taking a backup
- Scheduling a backup
- Restoring a backup
- Deleting search indexes
- Database size
- Changing persistence managers
Backup is an enterprise module (3.6 and higher) included in the Enterprise Edition bundle and typically already installed. Go to Magnolia Store > Installed modules in AdminCentral to check. To install the module individually, see the general module installation instructions.
restore scripts are in the
bin directory in the Backup module bundle. Download the bundle from the Magnolia Store and extract the zip file.
See the general module uninstalling instructions and advice.
Taking a backup
- Go to Tools > Backup.
- Enter the target path for backup.
- Click Backup. The target id be created if it doesn't already exist.
repoConfig.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 content of given workspace.
blobs- folder with binary data from all the workspaces.
Backup files contain confidential information on how to connect to the database. For this reason keep your backup files at secure location.
Scheduling a backupTo configure scheduled backup:
- Go to Configuration >
/modules/backup/config/and create a new entry. (See the preconfigured
weekly backuptask as a reference.)
- Set the backup time and recurrence using cron-like date/time selection pattern for the scheduler.
Restoring a backupThe restore script is meant to recreate an instance, not to patch an existing one. For it to work correctly you should clean your database schema before running it. To restore the previously backed up data, use the
restorescript from the backup module bundle.
There is no UI for running the restore script. So that the script can re-create the repository, you need to run the script before starting Magnolia CMS.
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 below.
-backup <dir>. Backup folder.
-lib <dir>. Directory containing Magnolia's jar files. If not specific, the webapp's directory is suffixed with
-propertyfiles <arg>. List of properties files to load. If not specified, the value in
web.xmlis used. If the properties are not specified in
web.xml, the default configuration properties are used.
-saveAfter <num>. Persistence counter. The lower the number, the less memory used and the slower the restore runs. Default value is 100.
-servername <name>. Server name. Used for dynamic property file finding.
-webapp <dir>. Webapp's root folder. If not provided, the current directory is used.
-webappname <name>. Webapp name. Used for dynamic property file finding. If not provided, the directory name of the webapp is used.
./bin/restore -backup /path/to/backup/backup_0812305_1234 -webapp /path/to/magnolia/webapp
For safety reasons, run the restore from time to time on a test system to verify validity of the backup files. Depending on the amount of data changed over the time, perhaps do so every month or every quarter.
Deleting search indexesBackup data does not contain search indexes. Indexes are created on the fly when running restore. As the indexer runs asynchronously, the indexing may still be in progress when restore is done. For this reason, we recommend that you remove all indexes before starting up a restored instance. This ensures that indexes are freshly generated on startup (Note that this process can take a couple of minutes). To remove indexes just delete all
indexfolders from the workspaces. On unix systems you can do so by executing
rm -rf repositories/magnolia/workspaces/*/index.
Database sizeDuring restore all entries are reinserted into the database sequentially. This ensures that the restored database is not fragmented and is slightly smaller than the equivalent database before backup.
Changing persistence managersYou can use backup/restore to migrate data to another persistence manager, and so to another database. To change the persistence manager configuration into which the
restorescript will try to restore the database:
- Unzip all entries from
repoConfig.zip(you can find this file inside each backup folder).
- Change the persistence manager configuration in each file as appropriate.
- Zip the files.
- Run the restore.