Now I wanted to update to 22. I tried the web updater but it doesn’t work (I click on update and it just reloads the page). So I tried the cli and that “seemed” to work but the update process got stuck in maintenance mode. And turning maintenance mode prooved impossible.
if you end up with fresh install it looks like you didn’t keep your data. you are expected to store your DB, files and apps on persistent docker volumes, which you keep when you change the docker-compose file. then new docker image finds existing data and performs an upgrade…
The disk on which the docker volumes reside went missing from the VM (inside which docker lives). Now that I have attached the disk again, I don’t see a new install issue anymore.
But I do have another problem now:
When I first tried to update via docker-compose, it pulled version 23 (note that I was still on 21). Nextcloud does not support updating skipping one number. So in my next try I changed the docker-compose file to pull “22-apache”.
But when I now recreate the nextcloud container with 22, I get an error message that the data is already on version 23 and that this does not work with nextcloud 22.
So while the first update did not go through, it did change the version number of my data. And now I am stuck.
How can I change back the version number of my data?
the easiest way would be to restore your working NC21 and perform update one per step. If this is not an option there are multiple thread in this forum describing how people recovered from such situation.
My nextcloud installation is backed up independently from the data (and the database).
So, in addition to the nextcloud installation, what else do I need to restore? I.e. is it enough to restore the database (maybe the version number is only stored in there) or do I need to restore the data itself as well?
Assuming (hoping), it is only the database - which files specifically?
If there are already a lot of threads about recovering from a failed update where the update did not go through but the version number of the data was still changed, maybe it should be considered to change the update process (i.e. only change the version number at the end, if the update actually worked)?
you should never separate the backup in different part (database and data) as they belong together. Please take a look at the official backup instructions.
version number is part of the docker container and it exists within the container from the beginning… I assume it is added to config files even before the application has started. Feel free to check out the Dockerfile and improve the upgrade process
So I was able to work it out (with the help of another thread on the forum):
It is not necessary to restore all the data and it is not even necessary to restore the database.
It was sufficient to restore /html/version.php. In my case it contained 22.214.171.124 and the backup version.php I restored contained 126.96.36.199. After I restored it and restarted Nextcloud, it complained that a large number of apps had the wrong version (which is not surprising, because originally - prior to the failed update - I was on 21).
So I pulled the latest 22 image, recreated the containers and after a while my Nextcloud was up and running again.
Probably, it would have been more straight forward to use an even older backup version of version.php that contained my true 21 version number but I had that one right there and did not want to spend any more time.
I will monitor everything for a while to be sure that everything is fine and then I will update to 23.