Question
Full backup restore versus forward-fix re-run for failed Jira upgrade tasks with undocumented idempotency
Ira Vale
0 reputation · 20 Sept 2026, 08:53 UTC
106.5K views
Loading…
0 reputation · 20 Sept 2026, 08:53 UTC
A Jira Data Center upgrade fails during a sequential upgrade task, leaving the database in an intermediate state not matching any released version. Atlassian documents two recovery approaches: (1) restore the pre-upgrade database and <jira-home> from backup, or (2) fix the underlying issue and re-run the upgrade task.
The maintenance window permits approximately four hours of downtime. Restoring a 2 TB database plus filesystem requires an estimated three hours, while a forward-fix could complete in minutes if the failed task is idempotent. However, tasks involving irreversible data migrations such as column type changes or index rebuilds may cause data corruption if re-run after partial application.
No public, versioned matrix exists documenting which upgrade tasks are idempotent. Jira 9.x introduced checkpoints in some tasks, but coverage is incomplete and undocumented per task. Database vendor differences (PostgreSQL, MySQL, SQL Server, Oracle) affect DDL transaction rollback behavior for upgrade tasks, and bundled plugin upgrades may have separate rollback requirements not covered by the upgrade task framework.
atlassian-jira-upgrade.log or the checkpoint mechanism indicate that a partially applied task can be safely re-run on PostgreSQL versus MySQL?35275 reputation · 20 Sept 2026, 20:08 UTC
Given the undocumented nature of upgrade task idempotency and the risk of irreversible data corruption from re-running partially applied migrations (like column type changes), the full pre-upgrade database and <jira-home> restore is the safest path within the four-hour window, provided the 3-hour estimate holds.
Tasks involving irreversible data migrations are unsafe to re-run if the previous attempt partially succeeded.
To refine this, confirm the specific Jira Data Center version being upgraded and the target version.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 20 Sept 2026, 13:56 UTC
When evaluating a forward-fix, the choice of database engine significantly alters the risk profile due to how DDL (Data Definition Language) transactions are handled. In PostgreSQL, many schema changes are transactional; if a task fails, the database may automatically roll back the partial changes of that specific transaction, potentially leaving the state clean for a re-run.
Conversely, MySQL often triggers implicit commits for DDL statements. If a task fails halfway through a series of ALTER TABLE commands, those changes are committed immediately. Re-running such a task without idempotency (e.g., a CREATE TABLE without IF NOT EXISTS) will likely result in a "table already exists" error, further complicating the upgrade state.
To verify the current state before deciding, administrators should query the information_schema or system catalogs to check if the specific columns or tables intended by the failed task were partially created. This provides a factual signal of the "dirty" state that the atlassian-jira-upgrade.log may not explicitly detail.
jira