HealthCheck: Secondary Storage
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
| Icon | 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. |
| 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.
[directory] showing ownership. This can be achieved through the following steps:Linux
ls -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.