OK, so there we go, I now have a ‘refreshed’ Nextcloud installation. Everything runs in (hopefully) well maintained Docker containers. No longer do I have to deal with web server configuration, php variables, certificate renewals and sudden incompatibilities when upgrading the underlying operation system. Next step: Let’s get the backup / restore process working for this setup. In this post, I’ll have a look at how to create a local backup to get started with, and a remote backup, which is what I need for safety and redundancy reasons. Turns out that the difference between the two types of backups is small.
Local Backup
Configuring a local backup is pretty much straight forward. All that is required is to give Nextcloud AIO (All-In-One) a local path in which backups can be stored. Nextcloud AIO uses Borg Backup, which can perform incremental backups and is thus very fast. Also, one can configure an automatic daily backup at a certain time with an email notification about the outcome. For a local backup, no knowledge of Borg Backup is required, Nextcloud AIO handles everything automatically.
Sounds good, and I had no problems restoring the instance to a previous state and to recreate a new instance with such a backup after copying it to another server to simulate a hardware issue that would force me to run my Nextcloud somewhere else in a hurry. More about the ‘restore’ process in the following posts.
Remote Backup
Let’s come back to the ‘backup’ part of the backup/restore story. While a local backup is nice for rollbacks, it’s not ideal for redundancy. What I need is a remote backup, and Nextcloud AIO supports this as well. If you already have a remote Borg Backup server, the only thing that needs to be done is to specify the ssh://…. URL to the backup server instead of the local directory name.
When running the backup for the first time, it will ‘of course’ fail, because the backup server requires the ssh key of the Nextcloud container that runs the backup to allow access. This is intentional and Nextcloud AIO will give you the the key in a format that can be inserted into the .ssh/authorized_keys file on the Borg Backup server. I used this in addition to some extra Borg commands on the server to only allow appending to an archive and to restrict the Nextcloud to its own backup path. All of this is specified on the Borg Backup server in the single configuration line for the Nextcloud server in the .ssh/authorized_keys file.
Running the Backup – Incremental is your Friend
Once the ssh key of the Nextcloud backup container is provisioned on the Borg Backup server, one can run the backup again and watch the data being backed up. Depending on the network speed and the amount of data already stored on Nextcloud, this could take a while. Subsequent backups will run a lot faster, as Borg creates incremental backups, i.e. only new data has to be transferred. Like for the local backup, I then ran a number of exercises to restore a previous backup to the server to go back to a previous state and to use the backup to re-create the Nextcloud instance on a different server to simulate the recovery from a hardware failure. These options are all included in the Nextcloud AIO web interface and hence, the process is pretty much painless. Also, I checked that I can manually access data in the backup on the Borg backup server, which would allow me to restore earlier copies of individual files rather than to restore the full instance. Works like a charm!
And that’s pretty much all there is to say about backups. Next stop: I’ll have a look at local and remote restoration of a Nextcloud instance in more detail.