Migrate Nextcoud to a different server on shared hosting and change domain

ℹ️ Support
1

Nextcloud version: 22.2.3
PHP version: 7.4
Database: MariaDB 10.5

I’m running my Nextcloud instance on shared hosting and would like to migrate it to another server of the same provider (also on shared hosting) and change the domain name in the process. I have a few dozen users and quite a lot of files in different (group) folders with different shares - all of which I’d like to preserve. A lot of the standard apps like Group folders, Calendar, Deck, Polls etc. are enabled. My data directory is outside of the Nextcloud installation directory, so I have /cloud for all the program files etc. and /cloud/data for the data. My hosting provider allows SSH access but obviously I don’t have sudo privileges but I can run occ commands.

Also, as you can probably tell, my technical knowledge is very basic.

Since the migration guide in the manual assumes root access to the server I will have to adapt the procedure to my circumstances. Here’s what I came up with:

  1. Set Nextcloud in maintenance mode on the old server and wait for 10 minutes
  2. Set up the database on the new server
  3. Create a dump of the database via phpMyAdmin
    • Edit: Turns out my hosting provider allows me to use mysqldump via SSH so I’ll do that instead; still, it might be useful for others who come across this thread in the future to know if doing it via phpMyAdmin works as well
  4. Import the database via phpMyAdmin on the new server
    • Edit: Turns out my hosting provider allows me to use mysql via SSH so I’ll do that instead; still, it might be useful for others who come across this thread in the future to know if doing it via phpMyAdmin works as well
  5. Copy all files from the old instance over to the new instance
  6. Change the following in config.php:
    • trusted_domains
    • datadirectory
    • dbname, dbuser, dbpassword (apparently my hosting provider doesn’t allow my to set this myself when creating a new database)
    • mail_domain
    • tempdirectory
    • overwrite.cli.url
    • mail_smtphost
    • mail_smtpport
    • mail_smtpname
    • mail_smtppassword
  7. Set up the domain on the new server, set it to use PHP 7.4 and point it to the Nextcloud installation path
  8. Open the URL of the new Nextcloud instance in a browser and confirm that it is in maintenance mode
  9. Take the migrated Nextcloud instance out of maintenance mode
  10. Ask users to log in to the new instance and check if everything looks alright
  11. Delete the files and the database on the old server

Here are my questions:

  1. Did I miss anything or get anything wrong?
  2. My hosting provider allows for the transfer of data between servers via FTP from within their customer control panel. Should I use this to copy the files or should I instead create a TAR file of the Nextcloud files on the old server and unpack them on the new server?
  3. This post recommends installing Nextcloud on the new server and only copying over the data directory from the old server but I thought it might be better to also copy the program files so that there’s no mismatch due to different apps being installed etc. Am I missing something?
  4. This four year old post mentioned that the absolute path to the data directory is stored in the oc_storages table of the database and that this needs to be changed manually when moving. But from what I gathered from following posts in the thread, this was only the case with older versions of Nextcloud and is no longer necessary since Nextcloud will cross-check the information in the database with the information in the config.php. The post also gave the impression that the information on where the individual files are located is stored in the oc_filecache table of the database with the absolute path (" the oc_filecache will be full of wrong entries from the old location"). I couldn’t find any evidence of that in the oc_filecache database table of my installation though so I guess this can be disregarded as well. - Are my assumptions correct that this information is outdated?
  5. The migration guide in the manual mentions that you should confirm “that a logfile entry is written by both the Web server and Nextcloud and that no error messages occur”. Where would I have to look for those logfiles and what would I have to look out for specifically since I assume that there will be (irrelevant) error messages anyway?
2

Sorry i can not really help you. But if you do not have the knowledge please do not migrate the nextcloud on your own.

For migration you can read backup and restore.

If you want change the domain name move it on the old nextcloud before migration or move it on the new nextcloud after migration. You can and must use your nextcloud with two names. Parallel operation is necessary for weeks or months so that, for example, public shares continue to function.

3

@devnull: Thank you for your reply! You mentioned that parallel operation (I assume you mean as in with the old and the new domain name in parallel) is necessary for week or months. Is there any reason besides waiting until public shares from the old domain expire why one would have to do that?

4

Regarding step 3 and 4 in my list above (backing up and restoring the database): Turns out my hosting provider allows me to use mysql and mysqldump via SSH so I’ll do that instead; still, it might be useful for others who come across this thread in the future to know if doing it via phpMyAdmin works as well

5

Yes you can only use one domain at one time. But then you get perhaps problems.

For two domains.

  'trusted_domains' => 
  array (
    0 => 'cloud1.server.tld',
    1 => 'cloud2.server.tld',
  ),

Also you need two virtual hosts e.g. on apache2 and two certificates.
You can copy your config and e.g. certbot is easy.
You can use CNAME for move domain names from one server to another.

I use one nextcloud with two names without any need and it works fine for years.

6

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 the config.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 new numeric_id, so if anything is actually using this ID, it would point to an invalid path then. Changing the path of the existing oc_storages entry shouldn’t be a big issue, especially since you have a backup, so simply do it :wink:.
  • The oc_filecache table contains the paths relative to the oc_storages path, for a user’s local storage more precisely relative to /path/to/nextcloud/data/<username>. It also contains a storage field containing the ID of the oc_storages entry it belongs to. For user’s local files however there are dedicated entries like home::<username> which automatically point to the path <username>/ relative to the local::/path/to/nextcloud/data entry in use. I.e. indeed the oc_filecache entries currently stay valid when changing config.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 be rsync (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.

1 Like
7

@MichaIng: Thanks a lot, that’s really helpful!

8

When using rsync to copy the files from the old server to the new server, should I use it with only the -t option (the migration guide in the manual seems to imply that) or with -Aavx as mentioned on the page in the manual about backing up? I understand the reason behind using-t but the ramifications of using -Aavx (especially with everything that -a implies) are a little over my head…