JBoss.orgCommunity Documentation
You can start your backup strategy with the concept of a data repository. It is required to store and arrange backup data properly. The backup of one eXo Platform instance produces a set of files which can be located on various storage media (hard disk, tape, optical or solid storages, or even special remote backup services).
The files are organized in catalogs (folders) or used in different media to the concrete Platform implementation. However, it is highly recommended that you apply the Backup rotation scheme to make the backup implementation effective and reliable.
Also, be sure that your available backup solution of Operating System and Database software are always used, allowing you to simplify the backup organization and avoid mistakes and data loss.
In the pre-backup, you need to stop the whole eXo Platform server.
In case of the eXo Platform clustering, every node should be stopped before the backup is performed.
The backup of eXo Platform consists of the following parts:
Backup of the JCR data:
JCR index files, pointed by the configuration property: gatein.jcr.index.data.dir.
JCR value storage files, pointed by the configuration property: gatein.jcr.storage.data.dir.
JCR database backup, database specified in the JDNI configuration of Application server with the exo-jcr_portal name.
Backup of Organization service database specified in the JDNI configuration of Application server with the exo-idm_portal name.
Backup of Transaction service files pointed by the configuration property: com.arjuna.ats.arjuna.objectstore.objectStoreDir.
In the pre-backup, it is recommended that you prepare for tools, such as scripts, to restore data quickly and safely.
eXo Platform indicates to one Portal application in this context, which is set by default. However, if your eXo Platform instance runs several portals, each of which has its own JCR, Organization and Transaction services, you should back up data of each portal separately.
Information provided in this chapter only describes the backup of the single-portal Platform. The backup can be repeated for each portal in your system. Only two types of JCR files are important in the backup: index and value storages.
The gatein.jcr.data.dir folder ($gatein.data.dir/jcr by default) also contains the swap sub-folder. The swap folder is used for temporary files in case BLOBs are stored in the database and has no meaning for backup. For more details, see the eXo JCR configuration section.
To learn more about the basic principles of eXo Platform backup and how to create your backup implementation, see the following Backup Planning example:
Environment
The eXo Platform server runs on the RedHat Linux server. eXo Platform provides the remote database server MySQL 5.1:
JCR database - jcrdb.
Organization service database - idmdb.
The eXo Platform files are on the network mounted storage /mnt/netfs/platform:
JCR value storage files in /mnt/netfs/platform/jcr/values.
JCR index files in /mnt/netfs/platform/jcr/index.
Transaction service stored in /mnt/netfs/platform/jta.
The backup storage is located on the dedicated network mounted storage: /mnt/backupfs/my_plf_backup.
Naming and Rotation
It is a general case when the backup is organized in the two-cycle rotation: backup files are stored everyday and older data are stored weekly, and the data storage history will be planned for three years.
To implement this approach, the daily backup is run (at night when the site is not in use) and stores result files (database and JCR files) on the network storage in the following structure:
/my_plf_backup/2010/... - The archive folder of the previous year.
/my_plf_backup/current/ - The archive folder of the current year.
/my_plf_backup/current/weeks - The weekly archive folder of the current year.
/my_plf_backup/current/weeks/01 - The archive folder of the first week of the current year.
/my_plf_backup/current/weeks/02 - The archive folder of the second week of the current year.
/my_plf_backup/current/weeks/N - The archive folder of the week named N of the current year.
The backup files are named to the ISO 8601 date format:
yyyy-MM-dd_mysql_jcrdb.tar.gz - For the JCR database.
yyyy-MM-dd_mysql_idmdb.tar.gz - For the Organization service database.
yyyy-MM-dd_jcr_values.tar.gz - For the JCR value storage files.
yyyy-MM-dd_jcr_index.tar.gz - For the JCR index files.
yyyy-MM-dd_jta.tar.gz - For the Transaction service files.
For the files backup, eXo Platform provides a shell script running on the eXo Platform server. This script does the following actions:
Stop the eXo Platform server to ensure the full stop by the log sniffering.
Run the database backup tool against jcrdb and store the result file in the archive /mnt/backupfs/my_plf_backup/current/yyyy-MM-dd_mysql_jcrdb.tar.gz.
Run the database backup tool against idmdb and store the result file in the archive /mnt/backupfs/my_plf_backup/current/yyyy-MM-dd_mysql_idmdb.tar.gz.
Copy the JCR value files to the archive /mnt/backupfs/my_plf_backup/current/yyyy-MM-dd_jcr_values.tar.gz.
Copy the JCR index files to the archive /mnt/backupfs/my_plf_backup/current/yyyy-MM-dd_jcr_index.tar.gz.
Copy the Transaction service files to the archive /mnt/backupfs/my_plf_backup/current/yyyy-MM-dd_jta.tar.gz.
Copy all old archive files of 7 days to a week folder, for example /my_plf_backup/current/weeks/02.
Delete older files of 7 days as from /my_plf_backup/current/.
Create a folder for the previous year in /my_plf_backup/ if it is the first week of a new year, such as /my_plf_backup/2010, and then move content of /my_plf_backup/current/weeks there.
Start the eXo Platform server.
Send email to the administrator in case of any errors on any step.
Examples of the script implementation are out of the scope of this guide.