UPDATING: Is it atomic or can you end up with a broken, non-recoverable state?

Hi, each time I update Gitea (backup, stop, install, start), may it be minor ..z updates or major *.y.0 updates, I a bit worried that it’ll break and I’ll end up in a troubleshoot-recovery purgatory. I’ve been with Gitea since 1.4(?) and this far everything went fine and I’m currently at Gitea 1.7.6.

However, following GitHub issues and Discourse posts, I do notice that some people end up with failed updates, which almost always look like database-update failures. What’s not clear to me how bad these failures end up being. For instance, if an update fails, can you always go back to the last working Gitea version? In other words, are Gitea updates atomic such that the new version installed will only deploy its internal updates if it is successful, otherwise, it will rollback to the previous state (of the database and other content it attempted to updated)?

PS. I’m using sqlite3 as the database backend.

1 Like

I have a similar setup as yours (gitea backed with sqlite3). While I don’t know enough about gitea’s internals to tell you if it can roll back from a partial/failed upgrade, I can tell you that

  • properly stopping gitea
  • backing up all relevant directories (tar, cp -a)
  • restoring said backups on a fresh machine,
  • running the same version of gitea

worked for me without any percevable issues. So perhaps it might be feasible for you to make a copy, update that copy (or the original), then discard the copy/ restore the backup if the upgrade fails?

It’s not atomic between two minor version.If migration failed, you will not start a gitea instance. Most migrations are about database but some are about git files. So let it rollback sometimes difficult. But we will consider your suggestion. Thanks!

1 Like