Optimized Backup with Repository Splitting

Magnolia allows for multiple repositories. In the properties file you simply configure the location of these repositories.

How the repositories are configured is defined by repositories.xml.

By default Magnolia will set up a single repository called magnolia and place all workspaces there. The down side of this is you often back up workspaces that hardly ever change each time you want to run backup. The repository copier provided by JackRabbit is the mechanism used to generate a backup. It does not offer the option to simply backup a single workspace or group of workspaces. However, it wouldn’t make sense to offer the option since trying to reconstruct the repository in a recovery scenario would be cumbersome.

How to organize depends on individual needs. Simply divide the repository so that each one can be backed up independently. Typically the workspaces in magnolia_system are those workspaces which hardly ever change. This entire system repository could be recreated by simply executing a fresh installation. Where as the magnolia and magnolia_dam repositories contain those workspaces which contents editors are updating frequently. The reason to separate them is to try and keep the larger binaries in a single repo with it’s own datastore.

Each repository will be backed up at a rate which corresponds to user activity.

Proposed daily schedule:

The magnolia repository will be backed up 3 times a day. During lunch time, right after the end of the work day and again at midnight. Capture all changes that were made in each half of the day. The magnolia_system will be backup up at 2:00 and magnolia_dam twice a day when user activity tends to be slow. The reason for the staggered times is to avoid running backup simultaneously. Adjust you schedule according to your needs. Technically users can still be working in the system while a backup runs but it best if activity is kept to a minimum. Publishing and versioning while backing up can interfere with the process.

Ideally we want to send the backup directly to a place where another backup author is waiting. The backup author is typically not running and ideally is never needed but the backup author should be setup ready to be used in a recovery scenario.

The backup author should be thought of as a temporary instance to be used until the team can repair the production instance. The database used by the backup author does not need to match the database used in production. The backup extended module has the ability to backup from any database type to any other database type. This means the backup webapp can also act as the restoration webapp for the production author. Using the same Backup Tasks app you can send the data back to the production author once all the issues have been resolved.

For the example setup the production author will be using MySQL database. The backup webapp will use H2 database. The production author will send its backups directly into the backups folder of the backup webapp. During the backup the data will be transformed from MySQL to H2.

A special magnolia_control script is used with the start_backup parameter.

The main purpose of the control script is to make sure the backup webapp starts with the latest version of backup data. It will scrub any files/folders left by the backup, such as, lock files, the index, workspace.xml. It’s important when starting the backup webapp the index is recreated. If backup is performed with indexing disabled the control script can reenable the index within the workspaces.

The magnoliaBackup properties file be adjusted by the control script to set the proper location of the last backup.