About 4.:
- The
oc_storages
table contains the absolute path to the data directory. While Nextcloud indeed creates and effectively uses a new entry, when none is present that matches theconfig.php
entry, it at least leaves the instance in an inconsistent state, and there is not guarantee that such a duplicate will always be supported. See this post from Joas: HowTo: Change / Move data directory after installation - #16 by nickvergessen
The new entry get’s a newnumeric_id
, so if anything is actually using this ID, it would point to an invalid path then. Changing the path of the existingoc_storages
entry shouldn’t be a big issue, especially since you have a backup, so simply do it.
- The
oc_filecache
table contains the paths relative to theoc_storages
path, for a user’s local storage more precisely relative to/path/to/nextcloud/data/<username>
. It also contains astorage
field containing the ID of theoc_storages
entry it belongs to. For user’s local files however there are dedicated entries likehome::<username>
which automatically point to the path<username>/
relative to thelocal::/path/to/nextcloud/data
entry in use. I.e. indeed theoc_filecache
entries currently stay valid when changingconfig.php
only.
About 2.:
- I would go with a
.tar
archive to assure that all file modes and metadata are preserved, where I’m not sure whether this is guaranteed when copying all files individually via FTP. Not sure how practicable this is with the Nextcloud data (regarding the size of the tarball), another solution would bersync
(if supported by your hosting provider), where you can set a flag to explicitly preserve all metadata (rsync -a
).
Otherwise your steps look fine. Moving a Nextcloud instance is no black magic and you leave the old instance in place until the new one has been verified working, hence go for it. If the domain name changes, then of course shared links and client connections/settings are invalidated, but you are aware of this already.