Back up Polarion data
This topic discusses the system location of data that administrators should be sure to include in regular backup operations.
Variables and equivalent paths
For the purposes of discussing the location of various folders that administrators may wish to include in backups, let's define some variables and their meaning on different operating systems The installation file system structure differs somewhat on Windows vs. Linux.
The following table documents system variables and their locations on different operating systems.
Variable | Description | Windows path | Linux path |
|---|---|---|---|
POLARION_HOME | Location of Polarion binaries. | C:\Polarion | /opt/polarion |
POLARION_DATA | Root for Polarion data files. | %POLARION_HOME%\data | /opt/polarion/data |
The above paths are the defaults. You can configure the actual locations during installation.
Subversion repository
An essential component to back up is the Subversion repository, located in %POLARION_DATA%/svn. The default storage method is file-based and so does not modify existing files, only adds new ones. This is very convenient for incremental back-up methods.
Project builds
Project builds are located in %POLARION_DATA%/bir/projects .
The contents can be very large. Developers and project managers should know what is most critical to back up. It is usually not necessary to back up all the nightly builds for example. It also makes sense not to back up the demo project builds, if these have been installed.
Reports
Reports are generally not critical to back up because they can be recreated any time, with one important exception: the trends.
To back up the trends you need to collect all *trend*.xml files —.such as workitems-trend-data.xml — in the structure beneath the folder %POLARION_DATA%/RR. Backing up the entire folder will most likely be a significant waste of backup space (up to 99%).
If you use the SCRUM calculation, you should back up scrum-data.xml because it holds the historic values for all past sprints.
User-modified data
The following data may or may not need to be backed up depending on whether it was modified after Polarion was installed.
It may make sense to back up the root system configuration file polarion.properties (follow link for location). This file can be recreated by reinstalling Polarion and filling in all the original arguments. However, if the file was modified after the installation to customize the system configuration, it is a good idea to back it up.
If the original folder structure of the installation was modified — to add more Maven plugins or Apache modules, or if some graphics or templates were modified — it is a good idea to back up such modifications in case it is ever necessary to reinstall Polarion — on new hardware, for example.
Connectors data
If any Connectors are configured for any projects (in 
Administration
Connectors), include the folder %POLARION_DATA%/synchronizer in your backups. The folder contains a database that stores the relation between Work Items and the items in the connected third-party systems, and also Baseline data that is used to detect which fields were changed. Losing that data would mean losing the relation between Work Items and the items in the other systems, and when the items are synchronized they will be recreated instead of updated, thereby corrupting the data integrity of both systems.
Backup tips for the Polarion server
From best to worst scenario:
Do a snapshot of suspended virtual machine in which Polarion server runs (in cases where virtual machines like VMWare are used).
Stop Polarion server, do the backup, run server again.
On Windows, do not use backup software that opens files in write mode, because that may cause corruption of index-related files, which would then require a reindex operation afterward.
If running on Windows, and backup software does open files in write mode, configure the job Live Plan Refresh not to run during the backup. That job is most likely to work with the index, and stands the greatest chance of index corruption resulting.
When doing recovery from a backup of the running system (not a snapshot of the virtual machine, or the server was not stopped during the backup), it will most probably be necessary to reindex the system afterward.