Problem Definition

Currently file replication for disaster recovery is completely in the hands of the individual customers to implement, resulting in a wide variety of different solutions. While that gives the flexibility to implement something that fits well into the existing infrastructure framework they already have in place, it also has the drawback of not being directly supported by Atlassian while at the same time parts of it, i.e. the native Jira side, is supported. This leads to a lot of "passing the ball" back and forth between Atlassian Support and the customer.

The file replication is also not (natively) confirmed in any way, leading to the possibility of files not yet having been synced to the DR location without an easy to way check.

Suggestion

Native file replication of files needed for disaster recovery.

From customer testimonial:

Utilizing S3 based storage for attachments is our internal first step to providing the ability for our Jira DC instance to failover between physical data centers. It is essential for us to have DR support in the products that we support internally. Currently, in order to achieve some level of DR capability, we run a background process to synchronize files across our physical data centers.

Having Jira support this natively would be our preferred option, and in our opinion, would place Jira Data Center in a different class of application, that approaches the level we expect from a true Enterprise level application. It would also almost completely eliminate the need for NFS to run this application. From our research it appears that aside from attachments, there appears to be only 1 additional file that needs to be shared within the cluster.