This article describes how can be configured an automatic USB hyper backup, which is triggered by USB-connect.
The Synology Diskstation (DS) out of the box isn’t able to start an backup job automatically as reaction of USB hard drive connection.
My DS-216 has a copy button.
Using the app foreseen for this button you can do some simple tasks like “copy all files from USB-Drive to a predefined destination folder” or “copy all files in predefined folder to USB drive”.
Talking about backups, this isn't a solution. Desired would be a trigger for a hyper backup job. Reason: hyper backup does maintain a history of files. (like time capsule) and does compression.
In addition, the Copy button action can only handle the front USB port of the Synology DS.
My solution is derived from Bernd Distler's [1] solution. Bernd Distler is using autorun, a 3th party package. I wanted to find a solution without third party software.
The following article describes preconditions, the general workflow as well as the details how it is possible to trigger a hyper backup job start on USB connect event.
Originally the USB-Copy app from Synology is intended to do simple jobs like “copy file from USB drive to NAS” or “copy files from NAS to USB drive” when the copy button is pressed or a specific backup medium is detected. (UUID) It has to be installed by Synology package center.
Actions caused by copy button are affecting only the front USB port while USB detecting actions are working for the back site USB ports as well.
For my objective – triggering a Hyper backup job – I simply copy a flag file from predefined location on USB drive to a predefined location on NAS. So after connecting the USB drive a file named autobackup is copied to
/volume1/Shared/USB_AUTO_BACKUP/TRIGGERS/DATEN/autobackup
The following screenshot is depicting it.
The same has to be done for the other USB drive:
/volume1/Shared/USB_AUTO_BACKUP/TRIGGERS/MEDIA/autobackup
The USB-Copy program lets beep the NAS after connecting twice.
After finishing the trigger file it beeps again twice.
The trigger checker script /opt/bin/checkTrigger.sh is called by cron every minute.
First, the script is checking if it is running already. (avoid duplicate run)
In order to do so it checks if the activity file exists. (/opt/var/dataBackupRunning
)
If the activity file exists, it terminates immediately. Otherwise it continues.
Then it determines the trigger file counts. (count directory entries in:
/volume1/Shared/USB_AUTO_BACKUP/TRIGGERS/DATEN/ and /volume1/Shared/USB_AUTO_BACKUP/TRIGGERS/MEDIA/
The script allows only one backup type per call. Because of the trigger files are only deleted during backup start the trigger for the other backup isn’t lost. It will be handled on next run triggered by cron.
So it is possible to connect the second backup drive a bit later or even in the same moment. The backups are handled serial.
What happens when a trigger counter is bigger than zero?:
/volume1/Shared/USB_AUTO_BACKUP/TRIGGERS/MEDIA
OR/volume1/Shared/USB_AUTO_BACKUP/TRIGGERS/DATEN
/opt/bin/checkTrigger.sh
#!/bin/bash LOGFILE="/volume1/Shared/USB_AUTO_BACKUP/hyperBackupTrigger.log" ACTIVITY_FILE="/opt/var/dataBackupRunning" DATEN_TRIGGER_FOLDER="/volume1/Shared/USB_AUTO_BACKUP/TRIGGERS/DATEN/" MEDIA_TRIGGER_FOLDER="/volume1/Shared/USB_AUTO_BACKUP/TRIGGERS/MEDIA/" ctime=`date -R` if [ -f $ACTIVITY_FILE ] ; then #echo "[W] $ctime - is already running ($ACTIVITY_FILE exist). terminating." >> $LOGFILE exit 1 fi datenTriggerCnt=`ls -1 $DATEN_TRIGGER_FOLDER | wc -l` mediaTriggerCnt=`ls -1 $MEDIA_TRIGGER_FOLDER | wc -l` if [ $datenTriggerCnt -gt 0 ] ; then touch $ACTIVITY_FILE echo "[I] found trigger for daten. waiting 60s ..." sleep 60 echo "[I] $ctime : removing trigger for daten" >> $LOGFILE rm -rf $DATEN_TRIGGER_FOLDER/* ctime=`date -R` echo "[I] $ctime : starting hyperBackup for daten via $0" >> $LOGFILE . /opt/bin/startDatenBackup.sh 2>&1 >> $LOGFILE rm -f $ACTIVITY_FILE ctime=`date -R` echo "[I] $ctime - backup terminated" >> $LOGFILE elif [ $mediaTriggerCnt -gt 0 ] ; then touch $ACTIVITY_FILE echo "[I] found trigger for media. waiting 60s ..." sleep 60 echo "[I] $ctime : removing trigger for media" >> $LOGFILE rm -rf $MEDIA_TRIGGER_FOLDER/* ctime=`date -R` echo "[I] $ctime : starting hyperBackup for media via $0" >> $LOGFILE . /opt/bin/startMediaBackup.sh 2>&1 >> $LOGFILE rm -f $ACTIVITY_FILE ctime=`date -R` echo "[I] $ctime - backup terminated" >> $LOGFILE fi
Hyper backup has a config file in /usr/syno/etc/synobackup.conf
.
There all hyper backup tasks are configured.
We need to identify our task and derive the is from task phrase. (see middle line in the screenshot)
You can determine the id by taking a look tot he number. Just cut of “task_”. So in our screenshot the task is is 4.
/usr/syno/bin/synousbcopy
was a script until DSM5. So it was easier to manipulate it respective to replace it inside file system. Further, this script was containing the whole copy button handling. Since DSM6 the copy button handlich was moved into an app called USB-Copy. Nowadays the script is still there but contains some helper functions probably used by the USB-Copy app.
What can synousbcopy
do for us?
/usr/syno/bin/synousbcopy –h
Shows the help.
I’ll use it in order to manipulate the copy LED state. In addition, it can be used for unmounting USB-drives. (eject)
/usr/syno/bin/synobackup
is a program (served by Synology) which is able to trigger hyper backup tasks. Hyper backup uses the mode „image“. Here an example call:
/usr/syno/bin/synobackup --backup 4 --type image
When hyper backup is done it eject’s the corresponding USB drive. So we don’t need to care about ejecting.
This script or the corresponding counterpart startMediaBackup.sh
is the heart of the trigger process.
It does the following:
startDatenBackup.sh
#!/bin/sh LOGFILE="/volume1/Shared/USB_AUTO_BACKUP/hyperBackupTrigger.log" /usr/syno/bin/synousbcopy -b # blink usb copy led ctime=`date -R` echo "[I] $ctime starting daten backup" >> $LOGFILE /usr/syno/bin/synobackup --backup 4 --type image sleep 60 while [ "$(/bin/pidof img_backup)" -o "$(/bin/pidof dsmbackup)" -o "$(/bin/pidof synoimgbktool)" -o "$(/bin/pidof synolocalbkp)" -o "$(/bin/pidof synonetbkp)" -o "$(/bin/pidof updatebackup)" ] do ctime=`date -R` echo "[D] $ctime still running ..." >> $LOGFILE sleep 60 done #/usr/syno/bin/synousbcopy -e # eject hdd /usr/syno/bin/synousbcopy -f # usb copy led off ctime=`date -R` echo "[D] $ctime daten backup done." >> $LOGFILE return 0
Is the same as startDatenBackup.sh
The only difference ist he task id and some logging output.
startDatenBackup.sh
and startDatenBackup.sh
could be merged or put in a function in order to optimize. I left it here in order to depict.
/opt/var/dataBackupRunning
is the activity file. It is used as a flag. I fit exists no other backup job shall be triggered. It will be created at the beginning and removed at the end of checkTrigger.sh
.
The scripts /opt/bin/checkTrigger.sh
, /opt/bin/startDatenBackup.sh
and /opt/bin/startMediaBackup.sh
are logging to /volume1/Shared/USB_AUTO_BACKUP/hyperBackupTrigger.log
by redirecting stderr
and stdout
using pipe.