Full backup restore versus forward-fix re-run for failed Jira upgrade tasks with undocumented idempotency

Context

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.

Constraint

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.

Uncertainty

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.

Questions

How can an administrator determine whether a specific failed upgrade task class is idempotent without opening a support ticket during an outage?

What observable signals in atlassian-jira-upgrade.log or the checkpoint mechanism indicate that a partially applied task can be safely re-run on PostgreSQL versus MySQL?

Does a successful forward-fix on a staging clone restored from the same pre-upgrade backup reliably predict production safety, given plugin state and index differences?