-
Suggestion
-
Resolution: Unresolved
-
86
-
Currently the backup managers (both for JIRA and Confluence) allow backups to be taken as follows:
- once per 48 hours without attachments, and
- once per 48 hours with attachments.
Presumably this dual timer is to allow customers to generate a backup for migration testing, then still perform a full backup once they're ready for the final cut-over.
We are seeing the following pain-points with this current arrangement:
- From the customer's perspective, the time limit seems arbitrary and they are quite frustrated when they hit it.
- We don't say anywhere on the page that
- backups can only be generated once per 48 hours (until they try it); or
- backups with and without attachments are on different timers.
- The 48 hour timeout generally seems OK for the purpose of routine peace-of-mind backups, but not when migrating (which can be stressful enough as it is).
- Supporters have to run SQL and sometimes restart the application to clear the backup timer.
I propose that we make the following changes:
- Only limit the backup with attachments to once every 48 hours. The backup without attachments should not be restricted (new backups still overwrite old ones).
- Mention on the backup page that backups with attachments are limited to once every 48 hours, which they can see before they choose which type of backup to generate.
- Provide a button only available to system administrators that resets the backup timer, so that Support doesn't need to mess around with SQL.
- is duplicated by
-
- Closed
-
- Closed
-
- Gathering Interest
- is related to
-
- In Progress
-
- Closed
-
- Closed
-
- Closed
-
- Gathering Interest
- supersedes
-
- Closed
-
- Closed
-
- Closed
-
- Closed
- mentioned in
-
Page Loading...
-
-
-
-
-
-
[CLOUD-6617] Improve supportability of JIRA/Conf backup managers
it's not even assigned to anyone, and a similar issue for Jira seems to be orphaned...JRACLOUD-67496
I agree backups without attachments should have much lower limits, let's say even 10mins would be reasonable.
I'd like to have the ability to have a daily backup with attachments. Avatars and logos, I am fine backing them up once a week. Why is there a limitation at all?
Kind regards,
Michael
And dear Atlassian, remember about yours values:
"Don’t #@!% the customer
Customers are our lifeblood. Without happy customers, we’re doomed. So considering the customer perspective - collectively, not just a handful - comes first."
If I blow my backup window and need another backup, you cannot deliver another one in a reasonable time frame
That it requires an escalation via support ticket is bordering on customer-hostile
Just to reiterate, the capabilities being requested here in the description of the ticket are not enough. We need to be able to back up as many times as we want, which is a fundamental capability of modern-day IT teams/systems (see my last comment). I feel like I'm trying to build a car without an assembly line. I had to burdon your team tonight to reset my timers and I'm sure I'm going to have to do it again tomorrow.
Here are some famous books that highlight this capability as fundamental to IT Change Management.
- The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win
- A Seat at the Table: IT Leadership in the Age of Agility
- Leading the Transformation: Applying Agile and DevOps Principles at Scale
- Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations
This should have been a built-in capability from day one to allow for proper CICD. PLEASE DON'T LIMIT HOW OFTEN I CAN CREATE A BACKUP as it is paralyzing me. Again, let me know if I'm missing something here or if there is a better way for me to
- save the state of my system so I can roll back to a previous state when making changes.
- and migrated configurations seamlessly from dev to prod and vice versa.
Thanks for listening.
Mark
Jira is a very complex tool, requiring many many man-hours to setup and configure. Entire Enterprises rely on that configuration once it has been implemented. Downtime is often not an option.
Given the complexity of the application and the frequent need for changes to meet business needs, Atlassian must provide a capability to handle change management. That is really what this is all about. This tool doesn't accommodate change management on a more frequent basis than 48 hours. Users / Admins need a way to make multiple changes throughout the day and roll those changes back if things do not go well. Again downtime is not an option in a very large organization as it can cost a great deal of money to the organization. Note: The development environment is a great option you have provided, however, mistakes will still happen in production and we need a way to roll them back.
By the way, Confluence doesn't even appear to have a backup / restore option.
Have you considered implementing something to the effect of a snapshot of my cloud configuration that I can restore? That might be simpler and put less of a load on the system when backing up / restoring the data and configuration. Just a thought.
If I'm missing anything or if there are any resources available I should know about for solving these issues, please let me know.
Any progress here?