Jira Disaster Recovery file replication process
Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.
Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Purpose
This article provides additional information on how the replication process functions when Jira Data Center is configured to use a secondary folder for file replication as per the Disaster Recovery Guide for Jira.
Details
When file replication is enabled, files are not simultaneously written to both the primary and secondary locations. Instead, Jira monitors the primary home for changes to the selected file types (attachments, avatars, index snapshots, and/or user-installed add-ons) and then queues these changes for asynchronous replay to the secondary location. New files are copied from the primary home to the secondary location, and move/delete operations are mirrored to the secondary location.
For attachments, avatars, and index snapshots these operations are instantaneous. For add-ons, however, the copy/move/delete operation is performed once the replication queue has been idle for 60 seconds.
Configuration files on Jira Installation Directory are not synchronized automatically. The system administrator needs to ensure the application configuration customizations are properly applied on the Disaster Recovery instance.
If a jira.secondary.home path is not defined in the jira-config.properties file after enabling File Replication on Administration (⚙ icon) > System > Replication, a secondary home folder will be created under $JIRA_HOME by default.