Autorun für ext. Datenträger

[lanos]

Danke Merthos funktioniert jetzt alles

 

[fireflyer]

Hätte da mal eine Frage: Ich habe jetzt 2-3x autorun getestet und wäre bisher eigentlich auch super zufrieden, da das Programm ja wirklich einwandfrei die Festplatte auswirft. Jedoch hat er jedes mal ein komplett neues Vollbackup gemacht, was bei mir dann allerdings immer sehr viele Stunden dauert. Habe ich vielleicht etwas falsch konfiguriert oder sind über autorun keine inkrementelle Sicherung möglich?

 

[Merthos]

autorun startet nur die Sicherung vom DSM.

 

[lanos]

kurz: kein Haken setzen bei "gesicherte Dateien am Zielort immer beibehalten "

 

[Pubantz]

Autoruns Synlogy Backup HDD voll

Hallo

Das Autoruns Tool ist absolut klasse.
ich nutze es im Zusammenhang mit dem Synology Backup Tool.
leider habe ich ein Kleines Problem mit den Größen (NAS 2 TB) USB Platte (2 TB) geänderte Daten pro Woche CA 1,2 TB
Synology Version 4.2
durch die hohe Änderungsmenge bricht die Synology Datensicherung immer ab weil die HDD angeblich zu klein ist.
gibt es eine Möglichkeit das ich vor beginn der Sicherung einen ordner automatisch von der HDD lösche?
(die ordnerstruckturen ändern sich nicht)
oder die Prüfung des Freien Platzes beim Synology backup abzuschalten ?

 

[Merthos]

Tja, das Syno-Backup verhält sich schon manchmal komisch. Ein Ticket bei Synology schad auch nicht, damit sie sich des Problems bewusst werden.

Du kannst in das existierende Script ein Löschen davor schreiben (also als zweite Zeile).

rm -r $1/VERZEICHNIS

(aber Vorsicht beim Probieren )

Oder Du könntest selber rsync verwenden. Ein minimaler Aufrüf wäre:

/usr/syno/bin/rsync -avh /volumeX/SHARE/ $1/VERZEICHNIS

("$1" ist der Pfad der ext. Platte.)

 

[Pubantz]

Habe diese Zeile mal in mein Autorun Tool eingetragen ( zum test nur die )

#!rm -rf "$1/NAS-MP_1/Daten/down"

damit das verzeichniss gelöscht wird (ohne nachfrage daher f)
auch ohne #! probiert
leider passiert nichts
\\NAS-MP\usbshare1\NAS-MP_1\Daten\down
ist der Windows pfad von dem verzeichniss hoffe das hilft für einen tip wo mein gedankenfehler liegt.
warum das Verzeichnis nicht gelöscht wird.

#!rm -rf "$1/NAS-MP_1/Daten/down"
#!/bin/sh
/var/packages/autorun/target/localbackup "MP-Backup" "/volumeUSB1/usbshare" "$1" 100
exit $?

das währe mein Traum zum schluss wennn es läuft.
Zeile 1 löscht einen teil des letzten Backups um genug platz zu schaffen, und Zeile 2 macht dann das neue Backup
und meldet die platte ab

 

[TodsDeath]

Wie Merthos schon schrieb, muss der Befehl zum löschen in die zweite Zeile, also

#!/bin/sh
rm -rf "$1/NAS-MP_1/Daten/down"
/var/packages/autorun/target/localbackup "MP-Backup" "/volumeUSB1/usbshare" "$1" 100
exit $?

Die erste Zeile darf nicht geändert werden (--> Shebang)

 

[Pubantz]

Es läuft ich danke euch
Problem lag am berüchtigten Notepad von MS
da is das alles in einer zeile

 

[Urban51]

Ist es möglich, dass sich mit neuer DSM 4.3-3810 Update 1 (DS214play) irgendwas mit dem Warten auf return codes im Skript geändert hat?
Folgendes:
-Skript startet
-3s später Skript stoppt
-erstes local backup im Skript wurde in der Zwischenzeit aufgerufen, aber keine Weiteren. Mit TimeBackup (createVersion ...) genauso. Ja, bei TimeBackup wars schon immer so, deswegen die Warteschleifen wie ein paar Seiten vorher beschrieben.

Hintergrund: Bin von DS111 auf DS214play umgezogen. Die Backupplatten (und somit Skripte) blieben dabei unangetastet und jetzt tritt Beschriebenes auf.
Berechtigungen des Skripts kann man bei NTFS Platten ja eh nicht ändern!?

Ich werd heute abend die Skripte mal von Hand anstoßen.

Hier die Skripte, die immer super gingen.

#!/bin/sh
#backup in 2 versionen

LOGFILE=$1/autorun.txt
LOGFILElokal=/volume1/homes/Urban51/NASstuff/autorun.txt
log() {
       echo `date +%c` $1 >> $LOGFILE
	   echo `date +%c` $1 >> $LOGFILElokal
}

#welches backup zuletzt?
zeigerdatei=$1/letztesbackup.txt
letztesbackup=`cat $zeigerdatei`

OK=100
if [ "$letztesbackup" -eq 1 ]; then
	#jetzt backup 2
	/var/packages/autorun/target/localbackup "backup2" "/volumeUSB1/usbshare" "$1" 100
	if [ $? -ne 100 ]; then
	OK=101
	log "Backup 2 fehlgeschlagen"
	exit $OK
	fi
	#markieren fuers naechste mal
	echo 2 > $zeigerdatei
	log "Backup 2 lief"
	
elif [ "$letztesbackup" -eq 2 ]; then
	#jetzt backup 3
	/var/packages/autorun/target/localbackup "backup3" "/volumeUSB1/usbshare" "$1" 100
	if [ $? -ne 100 ]; then
	OK=101
	log "Backup 3 fehlgeschlagen"
	exit $OK
	fi
	echo 3 > $zeigerdatei
	log "Backup 3 lief"
	
elif [ "$letztesbackup" -eq 3 ]; then
	#jetzt backup 1
	/var/packages/autorun/target/localbackup "backup1" "/volumeUSB1/usbshare" "$1" 100
	if [ $? -ne 100 ]; then
	OK=101
	log "Backup 1 fehlgeschlagen"
	exit $OK
	fi
	echo 1 > $zeigerdatei
	log "Backup 1 lief"
    
else
   log "Konnte letztes Backup nicht ermitteln"

fi


#Backup des SynoBackup
/var/packages/autorun/target/localbackup "SynoBackupBackup" "/volumeUSB1/usbshare" "$1" 100
if [ $? -ne 100 ]; then
OK=101
log "SynoBackupBackup fehlgeschlagen"
exit $OK
fi
log "SynoBackupBackup lief"

exit $OK

#!/bin/sh
#creates a new version for time backup task and checks every 10mins if its still running

TASK_NAME=notfallbackup
TASK_NR=1

LOGFILE=$1/autorun.txt
LOGFILElokal=/volume1/homes/Urban51/NASstuff/autorun.txt
log() {
       echo `date +%c` $1 >> $LOGFILE
	   echo `date +%c` $1 >> $LOGFILElokal
}


#geht nicht mehr. fehlermeldung segmentation fault (core dumped)
#/usr/syno/bin/timebkp create_version --task=$TASK_NAME
/usr/syno/bin/timebkp create_version --unique $TASK_NR

log "Creating Version for  $TASK_NAME  started"

#checking if rsync is still processing

sleep 600

while [ "$( /usr/syno/bin/timebkp list_version --task=$TASK_NAME | grep processing )" ]
do
    sleep 600
done

#copy config
cp -Rpf /usr/syno/etc/packages/TimeBackup $1/TimeBackupKonfig

#http://www.epochconverter.com/ <für timestamps im konfig file

log "Creating Version for  $TASK_NAME  finished"

/var/packages/autorun/target/localbackup "SynoBackupBackup500er" "/volumeSATA/satashare" "$1" 100
if [ $? -ne 100 ]; then
log "SynoBackupBackup500er fehlgeschlagen"
exit 101
fi
log "SynoBackupBackup500er lief"

exit 100

 

[Urban51]

Die Skripte würden laufen, wenn ich geduldig genug wäre, den Rechner mit PC warten zu lassen.

Hier das Log von autoruns. Die Start-und Stopzeiten werden auch durch beepen bestätigt. Aber nach dem Stop wird local backup angestoßen?? Wie geht das denn? Edith sag: weil in dem internen autorun Skript noch eine Pause von 10s eingebaut ist.

2013-11-30 00:11:49: device 'sdc' - inserted, trying to find mount point
2013-11-30 00:11:56: device 'sdc' - mount point '/volumeSATA/satashare' found
2013-11-30 00:11:56: device 'sdc' - script '/volumeSATA/satashare/autorun.sh' found, executing
2013-11-30 00:11:59: device 'sdc' - script '/volumeSATA/satashare/autorun.sh' finished (456.7G left on device), no further actions
2013-11-30 00:12:06: device '/volumeSATA/satashare' - local backup 'backup3' started

 

[Urban51]

Wo es dann völlig absurd wird: Im Log taucht das erfolgreiche Backup auf, obwohl das Skript schon längst gelaufen ist.
localbackup meldet also fertig, weswegen das Skript abgeschlossen ist. trotzdem schreibt localbackup noch ins autorun log

2013-11-30 01:30:45: device 'sdc' - inserted, trying to find mount point
2013-11-30 01:30:54: device 'sdc' - mount point '/volumeSATA/satashare' found
2013-11-30 01:30:54: device 'sdc' - script '/volumeSATA/satashare/autorun.sh' found, executing
2013-11-30 01:30:58: device 'sdc' - script '/volumeSATA/satashare/autorun.sh' finished (749.9G left on device), no further actions
2013-11-30 01:31:05: device '/volumeSATA/satashare' - local backup 'backup1' started
2013-11-30 02:14:54: device '/volumeSATA/satashare' - local backup 'backup1' finished

 

[Tengo]

@Merthos: Nochmal ein dickes fettes DANKE. Dein Paket ist echt allererste Sahne.

Einzig was mir nicht so richtig einleuchtet, ist die Tatsache, dass zwar in deinem AutoRun-Logfile der Start des Scripts nachzulesen ist, ich aber nix davon im "Datensicherungs- und Wiederherstellungs"-Menü sehe, also dort, wo ja die eigentliche Aufgabe liegt, die ja auch gestartet wird, wenn ich das richtig verstehe.
Oder wird bei der Erstellung des AutoRun-Scripts auf dem ext. Datenträger nur die eigentliche Sicherungsaufgabe ausgelesen, auf dem Datenträger gespeichert und danach das "Ausgangs-Script" nicht mehr benutzt?

 

[Merthos]

Ist ein Bug (?) vom DSM, dass dort keinen Fortschritt anzeigt wird, wenn die Sicherung nicht über die GUI gestartet wurde.

 

[riggert]

@Urban51 (sorry wenn mein erster Post gleich mal zu lang ist)

Das selbe Problem habe ich auch auf meiner ds214play. Das autorun Skript wird im Grunde genommen nach ca. 3 Sekunden abgebrochen.
Nach etwas Suche habe ich folgendes gefunden:
- das Problem scheint zu sein, dass hotplugd + kernel beim Hotplug eSATA devices mounten, unmounten und wieder mounten, d.h.
- das autorun Skript auf dem device wird gestartet (mit dem korrekten device + mountpath)
- nach 3 Sekunden wird umount ausgeführt (sieht man im /var/log/messages)
- es erfolgt ein kill des Prozesses der auf satashare zugreifft, d.h. /volumeSata/satashare/autorun wird abgebrochen
- deswegen kommt kein return code 100 und autorun meldet keine weitere Aktion (anstatt z.b. unmount/eject auszuführen)

Damit fnkt. der backup bei dir, weil hier nur ein Job in die Queue gestellt wird.
Der wird dann von timepkbd ausgeführt und da das device immer noch gemounted ist, läuft es durch. Dennoch ist autorun hier gebrochen.
D.h. würde hier autorun erfolgreich ejecten, dann würde auch dein backup auf die Nase fallen.

Das ist aber sicherlich nicht im Sinne des Erfinders, denn wenn das Skript z.B. länger als die 3 Sekunden braucht, dann wird es einfach gekillt und autorun macht eben kein eject.

Ich habe mir vorerst recht einfach beholfen, indem ich einen 20 Sekunden sleep in /var/packages/autorun/target/autorun eingebaut habe:

#!/bin/sh

if [ -z "$1" ]
then
        echo "incorrect '\$1' - aborting ..."
        exit 1
fi

# RIC: add sleep
# device is mounted, unmounted and mounted again
/bin/sleep 20

source /var/packages/autorun/target/config
TRIES=20
LOGDIR="/var/packages/autorun/target"
[...]

Damit geht es und mein autorun Skript läuft problemlos durch, kann return code 100 setzen und autorun führt richtig einen eject durch. Würde aber bei einem update des autorun packages wieder brechen.
Interessanterweise beobachte ich das nur bei eSATA devices, USB devices hatten hier keine Probleme.
Man müsste hier irgendwie in /var/packages/autorun/target/autorun oder in /usr/syno/hotplug.d/default/99autorun.hotplug warten/prüfen bis der mount wirklich abgeschlossen ist. Da dies aber duch hotplugd und kernel geschieht, habe ich bisher (noch nicht lang gesucht) keine gute Lösung gefunden.
Vlt. kann der maintainer des autorun packages zumindest den sleep einbauen und evtl. in der UI konfigurierbar machen (ginge sehr einfach).

Zu beobachten ist das einfach mit einem Skript das z.B. permanent läuft und jede Sekunde "/bin/mount | grep $DEINDEVICE" ausgibt. Da sieht man das beschriebene Verhalten.

Mein autorun skript sieht übrigens so aus, und damit brauche ich natürlich mehr als die 3 Sekunden

#!/bin/sh
#creates a new version for time backup task and checks every 1mins if its still running
PATH=/opt/bin:/opt/sbin:/syno/bin:/usr/syno/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin

LOGFILE=$1/autorun.log
exec >$LOGFILE 2>&1
TASK_NAME=mytaskname

log() {
  echo "`date +%c`: $1"
}

log "STARTED creating version for $TASK_NAME"

# workaround for now, --task segfaulting
# timebkp create_version --task=$TASK_NAME
timebkp create_version --unique=1
sleep 10
# the latest backup is last, 5 lines describe it
log "$( timebkp list_version --task=$TASK_NAME | grep -A 4 "version:" | tail -n 5 )"

#checking if time backup is still processing
while [ "$( timebkp list_version --task=$TASK_NAME | grep processing )" ]
do
  sleep 60
done

log "FINISHED creating version for $TASK_NAME"
# the latest backup is last, 5 lines describe it
log "$( timebkp list_version --task=$TASK_NAME | grep -A 4 "version:" | tail -n 5 )"

cat $LOGFILE | nail -s "MyMachine: autorun TimeBackup $TASK_NAME" mymail@my.host

exit 100

 

[Urban51]

Ah ja! Scheint zu laufen.
Es wurde ja schon viel mit Pausen gespielt: im Skript, in localbackup; aber in autorun ist mir neu.
Ergibt ja auch Sinn, dass man die Pause einbaut bevor ein Prozess gestartet wird, der auf die Platte wirklich zugreift.

 

[Merthos]

Man müsste hier irgendwie in /var/packages/autorun/target/autorun oder in /usr/syno/hotplug.d/default/99autorun.hotplug warten/prüfen bis der mount wirklich abgeschlossen ist.

Es wird schon gewartet bis der Mount fertig ist (die while-Schleife).

Man müsste mal schauen, was der hotplug so aufruft (/usr/syno/hotplug.d/default/99autorun.hotplug), eventuell könnte/müsste man dann jetzt nach anderen Werten filtern. Da ich aber noch nicht auf 4.3 bin (und wohl auch nicht werde), kann ich das hier selbst nicht testen...

 

[riggert]

Es wird schon gewartet bis der Mount fertig ist (die while-Schleife).

Ja, das habe ich schon gesehen, allerdings wird wie gesagt gemountet, umountet und wieder gemountet.
Der check läuft nach dem ersten mount erfolgreich weiter und fliegt dann beim anschliessendem umount auf die Nase.
Im /var/log/messages sieht man es:

Dec 30 23:41:24 FortKnox hotplugd: ##### ACTION:add
Dec 30 23:41:24 FortKnox hotplugd: DEVNAME:sdc
Dec 30 23:41:24 FortKnox hotplugd: DEVICE:/proc/bus/usb/000/000
Dec 30 23:41:24 FortKnox hotplugd: DEVGUID:WD-WCAU429208370
Dec 30 23:41:24 FortKnox hotplugd: DEVPATH:sdc
Dec 30 23:41:24 FortKnox hotplugd: SUBSYSTEM:block
Dec 30 23:41:24 FortKnox hotplugd: PHYSDEVPATH:/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/host2/target2:0:0/2:0:0:0
Dec 30 23:41:24 FortKnox hotplugd: usb_get_device_id.c:56 failed get usb id Vendor=0000, ProdID=0000, SN=0000:01:0d.0
Dec 30 23:41:24 FortKnox hotplugd: hotplugd.c:793 Get usb id failed, DEVICE=/proc/bus/usb/000/000, error=No medium found
Dec 30 23:41:24 FortKnox hotplugd: hotplugd.c:1417 failed to setup usb config, (DEVPATH, DEVICE, ACTION, DEVNAME, INTERFACE)=(sdc, /proc/bus/usb/000/000, add, sdc, )
Dec 30 23:41:24 FortKnox hotplugd: hotplugd.c (1439) ==== eSATA device [sdc] plugged in ====
Dec 30 23:41:24 FortKnox hotplugd: SYNOUSBIGetNumByName(42): fail to get the value for key [sdc]
Dec 30 23:41:24 FortKnox hotplugd: SYNOUSBDevGetInfo: get devnum & busnum for [sdc]
Dec 30 23:41:24 FortKnox timebkp: [10412]BK_WARN:Getting path of destination share failed
Dec 30 23:41:24 FortKnox umount: Kill the process "autorun" with /volumeSATA/satashare/autorun.log.
Dec 30 23:41:24 FortKnox umount: Kill the process "timebkp" with /volumeSATA/satashare/autorun.log.
Dec 30 23:41:24 FortKnox umount: Kill the process "timebkp" with /volumeSATA/satashare/autorun.log.
Dec 30 23:41:26 FortKnox kernel: [92371.691133] EXT3-fs (sdc1): error: couldn't mount because of unsupported optional features (240)

Evtl. macht mich die letzte Zeile stutzig, ist aber zeitlich nach dem umount und das FS wird correct als ext4 gemounted.

Ich habe mit mal das hotplug env. gedebugt und ich sehe keine anderen wirklich relevanten Variablen/Werte die man checken könne (ausser das evtl. auf DEVTYPE=partititon statt "disk" geprüft sollte - die partititon wird gemountet nicht die disk, ist aber eher nicht von belang für dieses Thema).
Es fliegt btw. für die disk bzw. partition korrekterweise nur ein event...
Falls von Interesse, hier mal der debug des Partition events:

Mon Dec 30 23:40:48 2013: arguments (block) env (DEVNAME=sdc1
ACTION=add
HOME=/
SEQNUM=1626
MAJOR=8
DEVPATH=/block/sdc/sdc1
SUBSYSTEM=block
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MINOR=33
PHYSDEVPATH=/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/host2/target2:0:0/2:0:0:0
PHYSDEVDRIVER=sd
PHYSDEVBUS=scsi
PWD=/
DEVTYPE=partition)

Ich denke es wäre interessant wie die Syno den entgültigen Zustand feststellt, bis sie ein device als ready anzeigt.
Bin gerne bereit hier mal noch tiefer reinzugraben und bin für Vorschläge offen.
Mir scheint, als würde der check auf den mount nicht reichen - was schon sehr komisch ist..

 

[lrlr]

BITTE die aktuelle Version (bzw. wo man sie bekommt) ins 1. Postig schreiben, ich hab mir jetzt eine WOLF gesucht bis ich die (vermutlich) aktuellste (1.3) gefunden habe..

 

[UweLe]

bei mir stecke ich die Exterene hdd als eSATA an und es beept einmal (für festplatte gefunden und los gehts) und paar sekunden später beept er wieder für bin fertig und zeigt das auch im DSM an, obwohl er noch nichts gemacht hat... und danach fängt er dann mit der sicherung an und nach erfolgreicher sicherung wirft er die festplatte nicht automatisch aus... woran liegt das?

2013-12-31 14:34:15: device 'sdg' - inserted, trying to find mount point
2013-12-31 14:34:21: device 'sdg' - mount point '/volumeSATA/satashare' found
2013-12-31 14:34:21: device 'sdg' - script '/volumeSATA/satashare/autorun' found, executing
2013-12-31 14:34:21: device '/volumeSATA/satashare' - mounting the encrypted file system
2013-12-31 14:34:22: device 'sdg' - script '/volumeSATA/satashare/autorun' finished (142.0G left on device), no further actions
2013-12-31 14:34:33: device '/volumeSATA/satashare' - local backup 'Cloud-Auf-eSATA-sichern' started
2013-12-31 14:35:14: device '/volumeSATA/satashare' - local backup 'Cloud-Auf-eSATA-sichern' finished
2013-12-31 14:35:14: device '/volumeSATA/satashare' - unmounting the encrypted file system
2013-12-31 14:35:14: device '/volumeSATA/satashare' - problem while unmounting the encrypted file system, aborting