After this blog covered the installation of ownCloud with docker-compose, and the use of Traefik as a reverse proxy, you asked for a how-to about backup & restore strategies.
This was tested with Linux only – if you run docker on a Mac or Windows machine, you may have to adjust the volume paths. But in principle it works the same way.
Backup the Necessary Data
To begin, shut down your container. The documentation recommends to enable the maintenance mode and stop the web server – but in this guide it’s not necessary. With docker it makes sense to just shut down the container.
docker-compose stop
Now you can copy the files and database to a secure location. You can do this by copying the docker volumes. In the default case this should be owncloud_files and owncloud_mysql. The other 2 docker volumes can be left out, they only carry temporary data.
This example uses a folder on the docker host itself; in production, you should save the files somewhere else. Otherwise, if the disk gets corrupted, the backup would be affected, too.
sudo rsync -r /var/lib/docker/volumes/owncloud_files ../owncloud_backup/ sudo rsync -r /var/lib/docker/volumes/owncloud_mysql ../owncloud_backup/
You should also copy the docker-compose file and .env to your secure location. They can not only be important for restoring, it is always good to document how you set up the service.
As they don’t change often, you don’t have to backup them every time – it suffices to backup them when you edit them.
sudo rsync .env ../owncloud_backup/ sudo rsync docker-compose.yml ../owncloud_backup/
Finally, you can restart the container:
docker-compose start
Using a Dedicated Backup Tool
Instead of rsync, you can also use your favorite backup tool, like BorgBackup or Duplicati – the principle is the same. You just need to copy the two docker volumes to a secure location.
Dedicated backup tools usually have the option to encrypt the files. This reduces the attack surface drastically. If you have a symmetric passphrase for the backups, an attacker doesn’t get control over your data by gaining access to your backup server. But the passphrase needs to be on the docker host, when you want your machine to make automated backups.
Asymmetric encryption is even more powerful; when you only have the public key on your docker host, your backups are protected even if an attacker gains access to your docker host machine. You can store the private key offline, you only need it for restore operations.
You should run a backup regularly. Most backup tools enable you to save only incremental changes, so you don’t have to copy over terabytes of data every time you want a snapshot. This way you can run the backup cronjob every night, to keep the downtime short and your backups recent.
Even with a recent backup, you will lose the newest files if something goes wrong. The more recent, the less data loss your instance suffers. That’s why backup tools are so useful.
Restore Your ownCloud Instance
These restore steps work both for undoing regretted changes, or for restoring your instance from zero, e.g. when the server was destroyed by a data center fire or disk corruption. In that case you can be lucky if you also backed up your docker-compose and .env files.
If it isn’t this bad and you still have a running container, shut it down:
docker-compose stop
Now you can restore the files and database back from your backup location to your docker volume directory:
sudo rsync -r ../owncloud_backup/owncloud_files /var/lib/docker/volumes/ sudo rsync -r ../owncloud_backup/owncloud_mysql /var/lib/docker/volumes/
Then start the container again, or create it, if you don’t have created it yet:
# restart your container: docker-compose start # OR create it first: docker-compose up -d
Always keep your user’s data safe!
Backups are very important to ensure that your users don’t lose data. How can you guarantee that their data is safe with you if your ownCloud isn’t resilient against common problems?
Emergencies can always happen. But if you have a recent backup, you are better prepared and are more likely able to fix it.
If you make changes to your server, it can also be very useful to have a recent backup. ownCloud is a very complex platform; installing a new ownCloud app or upgrading your server can go wrong. Restoring the latest backup allows you to try things, if you don’t have a mirrored test instance for this.
Consider announcing downtime for backups to your users, and doing it at night. They will be grateful to know in advance when their data is not available. Transparency makes you a more reliable admin.
Wait, I need twice the storage now?
Storage is expensive, and ownCloud needs a lot of storage. Well, to backup an ownCloud you need nearly the same amount of storage again, depending on which compression algorithm your backup tool uses.
It can seem expensive that you have to double the space you are already using. But it’s worth it. Especially when you have the responsibility for the data of others, you should take the necessary steps to protect it.
Do you know good providers for reliable, cheap, convenient, secure storage with good customer support? Discuss your favorite provider in the comments!
Did you like this how-to? Share it on social media or leave a comment below. If you want to learn more about docker, stay tuned! This is the third part of a series about docker. Click here for part one and here for part two!
