When I saw that my version of Ubuntu could not be upgraded any more (due to Digital Ocean’s system), I had to migrate my Nextcloud installation (version 11.0.2) to a newer version of Ubuntu (16.04). In the documentation for Nextcloud, it details how to exactly migrate your Nextcloud installation to another Linux server, so I tried using that. Sadly, though, they left a couple of things out. So here’s my version of how I migrated my Nextcloud installation to another server.
First of all, they say to back up your data, which is what I did (to some extent). Next, I spun up a droplet which had similar specifications to my previous installation (it uses 512MB and has 20GB of storage, for instance). I made sure to put in my usual ssh key for this new droplet, as well as securing it in other ways. At first, I thought I knew how to easily do this: copy over the /var/www/nextcloud directory to the new server (which was also set up for Nextcloud), change some directory names, and it would be done. However, this was not what I found.
When I tried this method, I couldn’t access the web interface. What was worse was that I had forgotten to change the firewall configuration on the new droplet and accidently “locked” myself out. So, through some more research, I tried it again with another droplet.
This time, I copied the files using rsync, and made sure that I used the proper switches (I used the “-a” and “-t” switches, in order to archive the files, as well as save the timestamps). I saved the files to a new directory on the server, and made sure to back up the old files. I thought that this time I had fixed the issue. But Fate can be cruel.
Even though I had copied over the files in the “correct” fashion, the server still wasn’t accessible from the web. Looking at the /var/log/apache2/error.log file, I found that the webserver couldn’t start due to Nextcloud not be able to read the database. After researching the problem more, I learned that the data can’t be just “copied” over; rather the data has to be copied, and the database has to be imported. So, after scrapping that droplet (I had changed it too much already), I spun up a new droplet, and tried this whole thing all over again.
First, I put the server into “maintenance mode” and stopped the Apache server. Then I extracted the data from the database (via the command mysql -u ownCloud -p password ownCloud > /tmp/dump.sql), copied that over to the new server, and imported it into the new database. For importing the new database, I “dropped” the old database, created a new one, and finally imported the data with the command mysql -u nextcloud -p password nextcloud < /tmp/dump/sql. Then I copied the old Nextcloud as I did before (using the official documentation’s recommendation of the command rsync -Aax) and carefully moved the files into the new /var/www/Nextcloud directory. Even through all of this, it still wasn’t enough.
Looking again at the /var/log/apache2/error.log file, I found that the new Nextcloud install couldn’t read the database due to the new server using the old Nextcloud config.php file (are you still with me?). So, I changed a few values in the config.php file so as to use the new database. What I did was change the dbname to the name of the new database, as well as input the new database login information. Also, I added the new IP address to the “trusted hosts” array in the config.php file. This seems to have fixed most of my problems.
Just in case, I also ran a script that I found in the official Nextcloud documentation for fixing the permissions on the new server. Then I changed some of the security configurations for the Apache server. I copied over previous configurations for SSL into the /etc/apache2/sites-available directory, and enabled them through the a2enmode command. With all that finished, I started up the Apache server again, and took the Nextcloud installation out of “maintenance mode”. Finally, I was able to use the server. Except, it wasn’t exactly to my liking.
You see, I had copied over the “data”, “config”, and “themes” directories. I did not copy over all of my previous apps. When I saw that I had only half of my previous apps, I thought, “I need to fix this,” and copied the contents of my previous Nextcloud’s “apps” directory to the new server. With those out of the way, I saw to using some of Nextcloud’s recommendations, and bumped up the memory (as well as putting in a timeout feature). These were harder to fix, partially because I had these problems with my previous Nextcloud installation. Nevertheless, I sought to fix them.
One of my problems was with the /var/www/nextcloud/.htaccess file, specifically that it wasn’t working. To fix this, I edited the /etc/apache2/apache.conf file and changed the AllowOverride directive for the /var/www section to “All”. This allowed the /var/www/nextcloud/.htaccess to work (at least, it would work since I’m accessing the site over a secure connection). Next, I added a memcache so as to speed up performance. I added in php-apcu and edited the /var/www/nextcloud/config/config.php file to reflect this by assigning memcache.local the value \\OC\Memcache\\APCu. My server was made much faster with this tweak. For added polish, I followed the directions on this tutorial and added Redis support.
This was a tough migration that I thought would have been easy. I figured that it would have taken a couple hours. However, it was stretched out to a numbers of hours (not to mention one night). While it’s great that I have migrated to a more manageable configuration, I should have done more research.