Oh - this will be very painfull…
It is not supported to jump over major releases - you can only go from one to another.
In your case, this means:
Nextcloud 13 -> 14 -> 15 -> 16-> 17 -> 18
Including backups to every DB step.
Backups won’t be needed, really. I could always start again!
To be honest, I’m wondering whether to not bother.
Mostly the instance is a files repository. Perhaps a simple synch to a client, then build the new instance and synch back up would do.
Or synch from one nextcloud server and another, despite being different versions?
Is there a way to move accounts between servers?
Ok it was a joke from me.
Perhaps you can install Debian Buster and Nextcloud 18.
Then create all users new.
Then restore only the data (files with cp, …) and not the shares, calendar, …
Then rescan all.
Users must renew shares, …
If you are alone (no other users) it would be the easiest way to stop sync at client side, set up the server and start syncing from client to server with a new connection - that’s right.
There are only a few users, very few using shares. Perhaps that’s the easiest way to do it.
I’ll have to get my head round how to copy the data directory and then get it to match the data to user accounts.
Is there any documentation about this?
Just an advice: Don’t let your Nextcloud rot for that long, especially if it is connected to the Internet having a lot of security vulnerabilities on unsupported versions.
Aside from that, if you update, that is surely possible (still), but you have to check your PHP versions (Jessie had 5.6 by default) so that they are compatible with the releases of Nextcloud. If you can set it up new, that might be easier depending on the amount of users and shares.
First you need a backup of your data. I you use the same server you do not need to restore the backup. But if something fails you need a backup.
If you use a a second partition for your data you can install Debian Buster on / and leave /data (??) unchanged. After install Nextcloud you can change the data-dir in config/config.php to the second partition and make a rescan.
If you do not have a second partition you install Debian Buster with deleting all files and you must restore your nextcloud-data-files to the right directory.
Leave the data directory and do not reuse it!
In this directory there are only the files without the real names, connections (dirctory and User and permissions), but a kind of UUID. The rest is in the database. If you just copy the dirctory without the DB content (and that info is spread over several tables) - there is only unusable garbage remaining.
So in fact, without the DB information, you can delete the data dir completely!
Just an advice: if you offer advice, get your facts straight.
Nextcloud is as up-to-date as it is possible to be on that server. All
versions after 13 need a newer version of php. That server is hosting
business-critical software that was not able to move to later versions
of php.
It is offensive to suggest that it was left to rot by anyone than the
people who developed versions of Nextcloud that won’t install on old
platforms.
Now I’m in a position to fix the problem, it has been made much too
difficult.
If this server is hosting business critical software as well, then running a Nextcloud version that got its last update almost 1,5 years ago on the same server is definitely not a good idea. PHP requirements were bumped several times now, the Nextcloud developers do this according to the PHP support schedule
Yes, you’re right: we should have dumped Nextcloud altogether when they
decided not to support the current LTS version of Debian a whole year
and a half early.