First, this is how I run NextCloud, I am running it with docker and mariaDB on UnRAID 6.11.5:
- Repository “linuxserver/nextcloud”
- Container Path “/data” mapped to Host Path “/mnt/user/share_nextcloud_data/data/”
- Container Path “/config” mapped to Host Path “/mnt/user/appdata/nextcloud”
- Repository “linuxserver/mariadb”
- Container Path “/config” map mapped to Host Path “/mnt/user/appdata/mariadb-nextcloud”
- Container Variable: MYSQL_ROOT_PASSWORD assigned " password "
I have runned this for some years and it is working, but I feel like when I am updating it is just so unpredictable, somtimes I end up with a new version without problem, other times I end up using hours to recover mye installation.
Last time I got some problems with “Can’t start Nextcloud because the version of the data (188.8.131.52) is more than one major version behind the docker image version (184.108.40.206) and upgrading more than one major version is not supported. Please run an image tagged for the major version 25 first.” but if I installed any earlier version I got some errors with unacceptable cron job. After a lot of testing I got it working by updating to newest, and deleting my www folder and after that change my config to ‘installed’ => true, and added the other relevant settings.
So. I have a working instance of Nextcloud 27.0.0, but from now and forwoard I want a little more pain free maintenance.
How should I do updates?
As I see there is three methods:
- Update the container
- Update in Nextclud UI (not always working?)
- Update with CLI inside the container
I also am wondering, how can prepare for rollback in case something goes wrong?
You should follow whatever approach is recommended by the maintainer of the Docker image you’re using. In this case you’re using LinuxServer’s so follow their approach. In general, for Docker-based images, the image should be updated and when it restarts it’ll upgrade itself. Doing web-based or CLI-based updates manually within containers is nearly always a Bad Idea™.
Before doing any update/upgrade double-check that the process hasn’t changed or that they don’t have any special breaking changes that may be required. For example, LinuxServer changed their approach recently. Monitor their pages relevant to their Nextcloud image.
Don’t upgrade on the day one of a new image release. Personally I’d weight a couple weeks.
Take advantage of Docker’s wonderful ability to easily bring up a total copy of your entire Nextcloud stack. You can take your live Docker Compose and swap in a new IP address and datadirectory/etc and then bring up a “staging” (or test) iteration of your NC stack which you can then run the update/upgrade against. If it works, you can feel confident about doing it on your real (production) NC stack. If it doesn’t work on the staging stack, hold until you can figure out what’s going on.
Pin the image version in your Docker Compose by using image tags (you can find the appropriate tag on the DockerHub page for the image or in the maintainer’s documentation). This prevents “accidental” upgrades and, in particular, things like having the image upgrade skip major NC versions (which is a no-no and will always fail or super break things).
Backups (which you should already be doing hopefully). Make sure backups include dumps of the database and files: Backup — Nextcloud latest Administration Manual latest documentation