HealthCheck: Secondary Storage
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. 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
Overview
The KB covers all the various health checks for Secondary Storage, which is a reference the storage on the JIRA Data Center node configured for a "cold standby". This is a configurable option described in Disaster Recovery Guide for Jira so will not apply for all JIRA Data Center configurations. This KB covers the following tests to determine if the appropriate data is being successfully backed up to the cold standby node:
Attachments
Avatars
Plugins
Index Snapshots
Understanding the Results
Result | What this means |
|---|---|
Read and Write checks passed for directory - <directory>. | The health check did not discover any serious problems the relevant directory. |
Secondary storage is not configured for <type>. | Secondary storage has not been configured for attachments, avatars, plugins and/or index snapshots (depends on the check). |
Attachments are disabled. | Attachments for this environment are not enabled. |
Index recovery is not enabled, no index snapshots will be taken. | Snapshots will not be taken as index recovery is not configured. |
Replication of attachments to secondary storage is not supported when using a custom attachments directory location. | If a custom attachment path is being used, the replication of attachments to the secondary storage path is not supported. |
Unable to read data from directory - <directory>. | The health check failed to read data from the reported directory. |
Data from a reported directory - <directory> - is corrupt. | The seed data that is expected to be read, returns with a different result. |
Unable to write data to directory - <directory>. | Data can not be written to the specific directory by the given user. |
Unable to create file in directory - <directory>. | A file can not be created in the reported directory. |
Troubleshooting
Problem | Suggestion |
|---|---|
The use of a custom attachments directory is not supported. | Follow the guide in Configuring File Attachments to set the attachments directory to the default location. |
Unable to read data from directory due to a Permissions Error. Unable to write data to directory. Unable to create a file in the directory. | There could be a problem with your file system permissions, or there may be insufficient disk space available. Check that the user that is running the JIRA process has read permissions on the given file system as per our Actions in Jira server fails with FileNotFoundException in the Jira logs KB article. |
Unable to read data due to mis-configuration. | Check that the directory is correctly configured, and mapped to the expected location in the file system. |
Data from a reported directory is corrupt. | Check the integrity of the attached file system and that all JIRA nodes are accessing the shared file system in an identical manner. |
Providing Information to Support
In case you are unable to troubleshoot and fix the problem by yourself, please create a support ticket at support.atlassian.com and attach the following information to the ticket:
Take a Screenshot of the Health Check results.
Collect a Support ZIP from each of the Data Centre nodes.
Any collected information from the suggestions in this document.
Please provide details of the affected file System location [directory] showing ownership. This can be achieved through the following steps:
Linux
1ls -lahR [directory] | gzip -9 > fileListing.gzWindows
Use the AccessEnum SysInternals tool by Microsoft to complete this task, and collect a screenshot showing the permissions of the Shared Directory being used.
Was this helpful?