Maik Wodarz - private web page

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== About ======
This article describes how can be configured an automatic USB //hyper backup//, which is triggered by USB-connect.
====== Introduction ======
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.

====== Preconditions ======
  * SSH access to Synology NAS is enabled and the user is aware how to use it
  * Basic knowledge about usage of BASH and VI editor
  * //Synology Hyper backup// app is installed
  * //Synlogy USB-Copy// app is installed
  * //Hyper backup// tasks using USB are configured

====== Overview - general workflow ======
  * Create a cron job which checks peridically a predefined file system location for existence of a flag file. (I’ll call it trigger file)
  * Create an USB copy job using //USB-Copy// app from Synology, which copies a trigger file from a just connected USB drive to predefined location on NAS.
  * When the cron job finds the trigger file and there is still no active job (activity file), then:
    * Remember that a job is active => create the activity file (using touch)
    * Remove the trigger file
    * Switch copy LED to blinking mode
    * Start hyper backup task
    * Wait until the hyper backup task has finished
    * Wait some seconds
    * Deactivate copy LED
    * Remove activity file

====== USB-Copy ======
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.

{{:publications:2020-01-08_13_15_08-kermitnas.png?600|}}
{{:publications:2020-01-08_13_15_20-kermitnas.png?600|}}
{{:publications:2020-01-08_13_15_31-kermitnas.png?600|}}
{{:publications:2020-01-08_13_15_44-kermitnas.png?600|}}



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.

====== Trigger check ======
The trigger checker script /opt/bin/checkTrigger.sh is called by cron every minute.
{{:publications:2020-01-08_13_34_42-wodarz_burstnas_.png?600|}}
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?:
  * Create activity file (using touch command)
  * Remove all entries in trigger folders:
    * ''/volume1/Shared/USB_AUTO_BACKUP/TRIGGERS/MEDIA'' OR
    * ''/volume1/Shared/USB_AUTO_BACKUP/TRIGGERS/DATEN''
  * trigger the corresponding hyper backup task (by calling the corresponding start script)
  * after finish remove the activity file.

''/opt/bin/checkTrigger.sh''
<code>
#!/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
</code>
====== Backup task id ======
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)

{{:publications:2020-01-08_13_53_25-wodarz_burstnas_.png?600|}}

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.

====== Synousbcopy ======
''/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)

====== Synobackup ======
''/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.

====== Script startDatenBackup.sh ======
This script or the corresponding counterpart ''startMediaBackup.sh'' is the heart of the trigger process.

It does the following:
  * activate copy LED blinking
  * triggers //hyper backup// task
  * waits until the hyper backup task finishes.
  * Deactivates the copy LED

''startDatenBackup.sh''
<code>
#!/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
</code>

====== Script startMediaBackup.sh ======
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. 

====== Activity file (/opt/bin/checkTrigger.sh) ======
''/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''.

====== Logging ======
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.

====== References ======
[1] [[https://bernd.distler.ws/archives/1835-Synology-automatische-Datensicherung-mit-DSM6.html]]