With what could have happened 2 weeks ago if I wouldn’t have had a good backup plan, I realized that I had to do something about those Raspberry Pi’s that have started invading our house and how I’m backing up the code running on those small Linux computers.
Cause what happens in practice is that you open a telnet/ssh session on the RPi, start coding, debugging & testing until it works. And by the time you’re finished with that and made sure that everything starts automatically after a reboot etcetera, you close the session and you’re done – on to the next adventure; right? Wrong.
This leaves all the code on the RPi, on a 4GB SD card with no backup at all… sounds dangerous! I just had to do something about that, before I would lose something.
The first thing that popped up in my mind was rsync, a tool to sync files and directories to another machine. And since I have 2 Synology NAS devices, I thought it would be smart to backup my RPi’s to one of those instead of making images of the SD cards. Cause the latter option would result in downtime each time I want to do a backup; yuck. So rsync it will be.
All the examples I found that worked with rsync made use of ssh, so that was the first hurdle I had to take – I’ve never done that much with public & private keys, key generators and so on. But with some help I managed to get things going. First you have to generate a key with ‘ssh-keygen -t rsa‘ on the NAS. The resulting file with the public key (default file name id_rsa.pub) has to be added to the authorized_keys file on the RPi. Normally you should be able to use ssh-copy-id command for that, but for some reason that didn’t work on my NAS, so I had to manually copy the file to the RPi and do a ‘cat id_rsa.pub >> authorized_keys’ to make that happen.
After that I could ssh from my NAS to the RPi without the need of entering a password (which is needed for the script to run unattended!).
Ok, next item on the list was making a rsync script.
After some tries I came up with this:
/usr/syno/bin/rsync -avz --delete --exclude-from=/volume1/backup/_scripts/rsync-exclude.txt -e "ssh -p 22" email@example.com:/ /volume1/backup/raspdev/ >> /volume1/backup/raspdev_backup.log 2>&1
And it worked! In about 10 minutes the rsync script completed its work:
Last but not least, scheduling the backup job. It seems that since DSM 4.2 the Synology Task Scheduler has an option to run user-defined scripts. Just what I need:
Cool.. so now my ‘master’ Synology NAS (a DS209) takes care of backing up the RPi and 1 hour later a Network Backup job makes a copy to my other NAS (DS109) ; so now I have 3 versions – the original and 2 copies. Try to beat that, Mr. Murphy! 😉
It’s roughly the same way how I backup my Windows servers – robocopy copies the important directories to the first NAS and Network Backup does the rest.
Now some statistics on how rsync is performing. Here’s a part of the initial rsync backup log:
sent 972675 bytes received 1363869597 bytes 2347106.23 bytes/sec total size is 1360002151 speedup is 1.00
It does take some processing power to perform the back up though:
70% CPU for process-id’s 3914 and 3921 (3rd and 4th line), that’s quite a lot. Removing the ‘z’ option (=compression during transfer) from the rsync command resulted in lower CPU usage and I might try to make the backup somewhat ‘nicer’ to reduce the CPU usage even more – backup is not that time critical but other processes running on the RPi might be… I’ll have to do some tests to see what’s best practice.