I like to have a plan B so I regularly backup my Owncloud document folder to an external storage device and, in addition, to another Owncloud installation running on a Raspberry Pi so I can active this instance should my main Owncloud installation ever fail while I'm not at home. So far, I've always copied over the complete document folder to the Raspi which takes quite a while as it contains several gigabytes of data. Recently, however, I decided to have a closer look at the rsync command and noticed that it would be ideal to speed up the process as it can compare source and destination and only copies the parts of files that have been modified. Here's the command I put together after reading a couple of "how to's" that exactly fits my needs:
rsync -avzh –rsync-path="sudo rsync" /media/owncloud-drive/data/ pi@192.168.42.3:/media/owncloud-drive/data/ –progress –delete
Looks a bit complicated but it's pretty much straight forward:
- -avzh are the default options to use rsync in "a" = archive mode which goes through the directory recursively and preserves permissions, time stamps and access rights. 'v' stands for verbose output, 'z' for compressing data before transmission, and 'h' for human readable format.
- –rsync-path is used to run the rsync instansce on the remote RaspberryPi with admin rights which are required to copy the owncloud folder that needs to be accessible from the "www-data" account that is used by the web server.
- /media/owncloud-drive/data/ is the path to the local owncloud data folder that is to be copied to the destination.
- pi@192.168.42.3:… is the account, IP address and path of the remote device to which the data shall be copied.
- –progress, as you might imagine gives more details while the command is running.
- –delete allows rsync to delete all files at the destination which no longer exist on the source.
One shouldn't be adventurous when it comes to backups but since this is still in the test phase I ran the rsync command with Apache being shut down on the target but not on the source server. So in theory Owncloud could write to the log or the sqlite database file just at the moment the modified part of the database file is copied over and thus corrupting the destination database file. I've ran the command many times over several days now, and so far I had no issues from not shutting down Owncloud on the source server during the process. Maybe I was just lucky so far or maybe it's no problem at all, I'm not sure yet. But I'll keep you posted.