Introduction
References
http://www.beatificabytes.be/wordpress/send-custom-email-notifications-from-scripts-running-on-a-synology/
Solution Overview
Backing Up
Step 1 – root SSH access
sudo passwd root
su root
mkdir ~/.ssh
exit
ls ~/.ssh
If you don’t see a file called id_rsa.pub there you need to generate a pair of keys using this command
ssh-keygen -t rsa -C root@<Your Synology server’s name>
– When prompted for the file in which to save the key, accept the default (hit <Enter>)
– When prompted for a passphrase hit <Enter> (no passphrase)
Now push the public key to the Raspberry Pi (this is why we need the Pi to briefly allow password logins on the root account, because until the public key exists on the destination server, you will be prompted for a password when you run this command):
cat ~/.ssh/id_rsa.pub | ssh root@<your Pi’s IP address> ‘cat >> .ssh/authorized_keys’
Enter the password you created in Step 1 when prompted
Confirm that SSH key logins are now accepted by the Raspberry Pi by running this command (still from the Synology session, don’t toggle back to the Pi session yet🙂
ssh root@<Your Pi’s IP Address>
passwd -d root
Step 2 Creating the backup script files
#!/bin/ash
#This script uses rsync to backup a named Raspberry Pi at a given IP address
#Three rotating backups are kept. If rsync fails then the preceding backups are retained.
if [ “$#” -ne 2 ] ; then
echo “Usage: 2 arguments required: $0 SERVERNAME IP” >&2
exit 1
fi
# Set up string variables
SERVER=$1
ADDRESS=$2
NOW=$(date +”%Y-%m-%d”)
RPI_BACKUP=”/volume1/rpi_backup”
LOGFILE=”$RPI_BACKUP/logs/$SERVER-$NOW.log”
SERVERDIR=”$RPI_BACKUP/$SERVER”
BASENAME=”$SERVERDIR/$SERVER”
# Paths to common commands used
MV=/bin/mv;
RM=/bin/rm;
MKDIR=/bin/mkdir;
PING=/bin/ping;
RSYNC=/usr/syno/bin/rsync
#Function to check for command failure and exit if there has been one. This is done
# so that when invoked from cron the error is reported
check_exit_code() {
exit_code=$?
if [ “$exit_code” -ne “0” ] ; then
echo “$1”
echo “exit with exitcode $exit_code”
exit 1
fi
}
#Ping the RPI a few times to ensure the interface is up (I’ve not seen this fail)
$PING $ADDRESS -c 3 >> $LOGFILE
# Ensure we have a top level backup directory for this server
if ! [ -d $SERVERDIR ] ; then
$MKDIR $SERVERDIR ;
fi ;
# Backups are made to BASENAME.0, this is then moved if the backup was successfull.
# So we start by clearing out anything from a failed backup
if [ -d $BASENAME.0 ] ; then
$RM -rf $BASENAME.0 ;
fi;
# RSYNC via SSH from the RPI as an incremental against the previous backup.
$RSYNC -av
–delete
–exclude-from=$RPI_BACKUP/scripts/rsync-exclude.txt
–link-dest $BASENAME.1
-e “ssh -p 22” root@$ADDRESS:/
$BASENAME.0 >> $LOGFILE 2>&1
# If RSYNC failed in any way, don’t trust the backup, exit the script
check_exit_code “RSYNC Failed”
#Rotate the existing backups
if [ -d $BASENAME.3 ] ; then
$RM -rf $BASENAME.3 ;
fi;
if [ -d $BASENAME.2 ] ; then
$MV $BASENAME.2 $BASENAME.3 ;
fi;
if [ -d $BASENAME.1 ] ; then
$MV $BASENAME.1 $BASENAME.2 ;
fi;
if [ -d $BASENAME.0 ] ; then
$MV $BASENAME.0 $BASENAME.1 ;
fi;
/proc/*
/sys/*
/dev/*
/boot/*
/tmp/*
/run/*
/mnt/*
Step 3 Automating the backup
Step 4 Restoring from backup
Step 5 Backing up a second RPI
sudo passwd root
su root
mkdir ~/.ssh
exit
Push the public key to the Raspberry Pi (this is why we need the Pi to briefly allow password logins on the root account, because until the public key exists on the destination server, you will be prompted for a password when you run this command):
cat ~/.ssh/id_rsa.pub | ssh root@<your Pi’s IP address> ‘cat >> .ssh/authorized_keys’
Enter the password you created in Step 1 when prompted
Confirm that SSH key logins are now accepted by the Raspberry Pi by running this command (still from the Synology session, don’t toggle back to the Pi session yet🙂
ssh root@<Your Pi’s IP Address>
passwd -d root
4) Finally repeat step 3 Automating the Backup for the new host.
ToDo
- There is currently no notification sent if the backup fails. For now I inspect the logs, and the backup does at least preserve the last three good backups. It is possible to use the synology notification system, see http://www.beatificabytes.be/wordpress/send-custom-email-notifications-from-scripts-running-on-a-synology/ I may get around to this, I’m hoping that sinology may improve the system though…
- I want to investigate if I can perform a full system restore on to a blank card. For now I rely on taking occasional card images, and then this automated system gives me backup of all files.
- The timestamp on the individual backup top level directory is incorrect, it gets updated for each backup each time a backup occurs (mv is incorrectly setting the date). I did have a brief look at this, there are a number of obstacles to overcome. mv doesn’t preserve the timestamp on move, I cannot use touch with a specified timestamp because the version available on the DiskStation doesn’t support the feature. I could solve the problem with python, but this isn’t installed as standard. I think I could solve the issue using php, but I haven’t put the time in yet – more important to have a working backup.
An update to my diskstation, I’m not sure which version has made a few changes:
1) In the script the path to rsync has changed, this should now read
RSYNC=/usr/syno/bin/rsync
2) When setting up the Task Scheduler it is possible to configure it to send an email when run or on failure.