Leading Zeroes

This week I migrated my Yunohost server to a new host. It took several hours but the experience was smooth overall.

Here are the services/apps I run: – GoToSocial, my preferred fediverse server – Gitea, git hosting – Nextcloud, file storage and document editing – Trilium Notes, a note taking app – FreshRSS, an RSS feed reader/aggregator – This blog!

Plus these three which are just static sites as far as Yunohost is concerned: – Costume Dad, a Hugo-generated blog – IT Tools – Phanpy, a Mastodon-compatible frontend

Yunohost offers built-in backup/restore functionality, which I used. To migrate this way, you make a fresh install of Yunohost on the new server and then restore a complete backup of all system and app settings onto it.

To make sure everything worked as expected I started by moving this blog alone to the new server. This worked by virtue of the fact that you can choose which elements to include when backing up Yunohost, so I could pick the system stuff (domains, users, etc.) and just this blog to move.

It worked well! The domain config doesn't push any DNS records unless you explicitly tell it to, so they just hung out waiting for my other apps. Happy that the basics were in place, I moved on.

Migrating Nextcloud

I knew in advance that Nextcloud would cause problems because the data directory was so large (I have a lot of STLs and photographs on there) that I wouldn't have room for it and its backup on either server at the same time.

To resolve this problem I made local copies of the bulk of the shared files on my PC and then deleted the originals. This change synced to the server, which in turn shrank the data directory significantly. Once caveat is that Nextcloud keeps hold of deleted files for 30 days by default, so I had to manually trigger those to be cleaned up before I saw the benefit.

With the archive size now under control I stopped my running services and created the backup from the terminal. Then I used SCP to transfer it directly to the new server. Once it was there I kicked off the restore from the web UI.

The web admin became unresponsive for a long time. For some reason the restore action runs directly in the API process, and so other requests just hang while it does its thing. Because the archive was much larger this time (20GB, down from the original 60), I suppose it had a lot of work to do. I was expecting the restore to take time but the unresponsive API worried me. I could see that it was doing something via htop though, so I let it run and eventually everything came back up, with one exception.

GoToSocial's Custom Config

A while back I modified the nginx config for my GoToSocial install to fix an issue where media wasn't loading when my posts were bridged to Bluesky. There's more on the issue here. I introduced a custom variable in one file and referenced it in another.

When restoring my backup, I got an error from nginx that I was referencing an undeclared variable. Yunohost checks that the app is working before declaring that the backup has been restored successfully, and if there's an error it rolls the changes back. Which is probably good in most cases, but in this case it was frustrating because I could have fixed the problem with a one-line change.

Instead, I had to go back to the original server, undo my changes to the config there, then create a new backup containing just GTS and redo my previous steps.

Conclusion

My new server is running well, and much cheaper than my previous one while still having the same resources.

The whole process took 6+ hours. I didn't appreciate just how long the restore step would take. The lack of feedback while it started the process worried me greatly, I feel like there's lots of room for improvement there.

Given that I had both servers running concurrently, I think a more efficient solution would have been to use rsync (or something similar) to move the majority of the actual data between the servers and only use the built-in backup functionality to transfer configuration. That said, I don't know enough about Yunohost's internals to be confident moving things around on my own without missing something.

That said, I appreciate that this is possible at all with Yunohost. All of my issues were down to my data and the changes I made, not bugs in Yunohost itself or the apps I host. I still recommend it to anyone interested in self-hosting their own apps.