You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
For me, this is one of the least defined topics as I have not had experience and frankly, there is no unified go to approach yet.
In recent JIRA Versions, as far as I know there is no such "limit" which cannot be breaked and I know that optimization is much more efficient than total issue number.
Having said that, there will be a near time for me , where the need for archiving would arrive.
Current instance stats:
"Archived" Projects, which generally I have mapped to a permission scheme, accessible only for audit and reporting users, are a good thing, but still all issues are loaded in lucene indexes.
Partial indexing of issues would be a good improvement, but I don't think it would be the only one needed as I'm sure the performance stretches further than just indexes.
I would like to get your feedback on:
Which is your favorite Archiving Policy, assuming you have one ?
Do you have any go to strategies for better "archive" optimizations?
Hi @Sloan N_ B_,
Yeah it's definitely gonna need an offline archive sometime soon.
Unfortunately I too haven't found any solution or best practice for this.
Loading project by export all instance and importing one project only at an offsite backup may be a valid option, but still not optimal.
Have you considered exporting your issues from Jira, then permanently deleting them from Jira? This would ultimately decrease the load on Jira.
For example, using the PDF View Plugin you could export them to PDF files, in which you have full control what fields to include, whether to include comments, attachments (even their binary content!), change history, links, etc.
Here is a couple of samples.
Then you could put these documents to any document management system which can index them for future searches.
The drawback of this approach is that it does not enable easily restoring issues from the archives, although I am not sure if that is a requirement here. (You could still restore issues manually from the PDF if there is an infrequent need for that. Or even write a script that parses the content from the PDF and creates the issue via the Jira REST API.)
This has been discussed also here, maybe there is some interesting information for you.
That sounds a great option, though not applicable for my situation.
I am leaning more towards an "backup" instance where :
1-Either all the issues are stored
2-After successfully testing the solution, only export backups from Production and use this as a restore instance for audit/investigation only.
Thanks I'll check it out
Still though, the Customer Portal is an issue, as ultimately customers and approvers require the full history to be present.