Skip to main content

Esta versão do GitHub Enterprise Server foi descontinuada em 2024-09-25. Nenhum lançamento de patch será feito, mesmo para questões críticas de segurança. Para obter melhor desempenho, segurança aprimorada e novos recursos, atualize para a última versão do GitHub Enterprise Server. Para obter ajuda com a atualização, entre em contato com o suporte do GitHub Enterprise.

Restaurar após uma atualização com falha

Saiba como reverter de uma atualização com falha.

If an upgrade fails or is interrupted, you should revert your instance back to its previous state. The process for completing this depends on the type of upgrade.

If your instance is configured for high availability and your primary node upgrade fails, you can promote the (not upgraded) replica to be the primary. You will also need to update your DNS to point to the new primary node. Once you have a working primary node, you can then consider creating a new replica node. See "About high availability configuration" and "Recovering a high availability configuration."

Rolling back a patch release

To roll back a patch release, use the ghe-upgrade command with the --allow-patch-rollback switch. Before rolling back, replication must be temporarily stopped by running ghe-repl-stop on all replica nodes. When rolling back an upgrade, you must use an upgrade package file with the .pkg extension. Hotpatch package files with the .hpkg extension are not supported.

ghe-upgrade --allow-patch-rollback EARLIER-RELEASE-UPGRADE-PACKAGE.pkg

A reboot is required after running the command. Rolling back does not affect the data partition, as migrations are not run on patch releases.

After the rollback is complete, restart replication by running ghe-repl-start on all nodes. See "Command-line utilities."

Rolling back a feature release

To roll back from a feature release, restore from a virtual machine snapshot to ensure that root and data partitions are in a consistent state. See "Taking a snapshot."