Hyper Backup Guide: Automatische Sicherung auf USB-Datenträger beim Anstecken

plang.pl · 16. Aug 2023

Ich hatte schon einmal hier eine Anleitung gepostet. Da aber die Config. Datei nach dem Hyper Backup Update (HyperBackup 4.1.0-3716) woanders liegt und ich auf den dortigen Beitrag keinen Einfluss mehr habe, erstelle ich hier einen neuen Thread für das Thema Hyper Backup mit autorun.

Das 3rd-Party-Paket mit dem Namen "autorun" prüft beim Einstecken eines Speichermediums, ob dort eine Datei mit dem Namen "autorun" liegt und wenn ja, werden darin hinterlegte Befehle ausgeführt. Eignet sich gut, um automatisiert einen HyperBackup-Job zu starten. Fertig eingerichtet ist der Zustand folgender: Man steckt die USB-Platte an, es dauert kurz, die DS piept und macht das Backup. Wenn fertig, piept sie erneut und wirft die Platte aus. Während des Vorgangs ist die Status-LED der DS orange, sodass man ganz klar sehen kann, wann das Backup noch läuft und wann es fertig ist.

Man kann auch das Script von @luddi in Post #8 nutzen. Da kann man den Hyper Backup Job per Namen starten und nicht per ID, wie nachfolgend.

Zuerst musst du die Job-ID deines Hyper Backup-Jobs herausfinden:
1.) per ssh auf der DS anmelden als root
2.) ID ermitteln
Der Pfad für die Config-Datei, in der die ID steht, ist folgender: /usr/syno/etc/packages/HyperBackup/synobackup.conf (vor HyperBackup 4.1.0-3716 ist der Pfad /usr/syno/etc/synobackup.conf).
Der "beste Befehl", um Jobs aufzulisten, ist wohl dieser: more /usr/syno/etc/packages/HyperBackup/synobackup.conf | egrep "task|name".
Wenn das nicht hinhaut:
Für Anfänger würde ich zum Durchsuchen folgende Option empfehlen: more gefolgt vom Dateipfad eingeben. Wenn du viele Jobs hast, listet der Befehl nicht alle Zeilen auf, du musst immer wieder Enter drücken, um noch mehr aufgelistet zu bekommen. Du hälst die Augen offen nach deinem Job-Namen und merkst dir die dazugehörige Job-ID (nur die Zahl ist von Relevanz). Erfahrene User können die Datei natürlich auch mit nano öffnen. Da besteht aber die Gefahr, dass man etwas löscht. Unwahrscheinlich, aber sie besteht.

Beispiel:

Mein Backup-Job, den ich automatisiert starten möchte, heißt schlicht "USB". In meiner Ausgabe oben finde ich die Zeile name="USB". Ich gehe ein Stück zurück nach oben, da die Task-ID immer als erstes da steht und da sehe ich [task_23]. Diese Zahl benötige ich, um die autorun-Datei zu erstellen.

3.) autorun Datei erstellen
In die autorun-Datei auf das USB-Medium muss folgender Inhalt:

Bash:

#!/bin/bash
# Specify the Hyper Backup Task ID [task_?] from /usr/syno/etc/packages/HyperBackup/synobackup.conf
taskid=3

/var/packages/HyperBackup/target/bin/dsmbackup --backup "$taskid"
pid=$(ps aux | grep -v grep | grep -E "/var/packages/HyperBackup/target/bin/(img_backup|dsmbackup|synoimgbkptool|synolocalbkp|synonetbkp|updatebackup).+-k $taskid" | awk '{print $2}')
while ps -p $pid > /dev/null; do
    sleep 60
done
exit ${?}

Quelle Script

Diese Datei kannst du mit einem beliebigen Texteditor erstellen und speichern als "autorun" (OHNE .txt o.Ä.) direkt ins Stammverzeichnis des USB-Mediums.
Achte aber darauf, dass keine Windows-Zeilenumbrüche in der Datei sind. Am besten die Datei mit dem Texteditor des DSM erstellen (kann im Paket-Zentrum installiert werden).

Nun musst du natürlich noch das autorun-Paket auf der DS installieren: GitHub
Unter DSM 7 ist nach der Installation noch folgendes Kommando per ssh als root abzusetzen:
cp /var/packages/autorun/conf/privilege.root /var/packages/autorun/conf/privilege

Weitere Links:
Anleitung (veraltet, nicht alle Schritte sind notwendig)
Thread im Forum

23-10-21
-Script, welches via Name statt ID auskommt verlinkt
23-08-26
-Übersichtlichkeit verbessert
23-089-02
-Script verbessert

Anzeige · 16. Aug 2023

Hallo plang.pl,

Bücher und Hardware zum Thema gibt es bei Amazon: Guide: Automatische Sicherung auf USB-Datenträger beim Anstecken

plang.pl · 26. Aug 2023

Es gibt jetzt eine Alternative - ein Package aus der Community mit GUI: https://www.synology-forum.de/threads/autopilot-fuer-externe-datentraeger.128487/
Ich habe es noch nicht getestet, werde das aber bald nachholen!

daschmidt94 · 28. Aug 2023

Kurze Frage,

was macht diese Schleife?

Code:

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)" ]

plang.pl · 29. Aug 2023

Prüfen, ob das Backup noch läuft

luddi · 02. Sep 2023

@plang.pl eine kleine Korrektur habe ich noch für das grep command.
Die Binary heißt nicht synoimgbktool sondern synoimgbkptool. Da fehlte bisher der Buchstabe "p".

Wenn du das in Beitrag #1 bitte noch aktualisieren möchtest. Vielen Dank

plang.pl · 02. Sep 2023

Danke für den Hinweis. Ist ausgebessert.

luddi · 02. Sep 2023

Vielleicht sollten wir auch noch in naher Zukunft das grep Command im Auge behalten.
Denn in einer Sache bin ich mir selbst noch unsicher.

Ich hatte bisher nur Folgendes berücksichtigt und auf alle anderen binaries geschlossen.
Lediglich sucht man nach einem Eintrag in der Prozessliste welcher wie folgt aussieht.

/var/packages/HyperBackup/target/bin/img_backup -B -k "$taskid"

Aus diesem Grund hatte ich wohl vermutet, dass alle anderen binaries gleichermaßen bzw. mit ähnlichen Argumenten aufgerufen werden insebesondere das Erkennungsmerkmal der Task ID und somit -k "$taskid" am Ende.

Aber wir haben ja zumindest schon einmal gesehen, dass der Aufruf von
/var/packages/HyperBackup/target/bin/dsmbackup --backup "$taskid"

in der PID Liste resultiert zu:
/var/packages/HyperBackup/target/bin/img_backup -B -k "$taskid"

In diesem Fall scheint alles gut zu laufen und wir finden die korrekte PID.

Doch schaut man die Hilfe aller Binaries genauer an, so habe ich die Vermutung, dass dies wohl nicht auf alle zutreffen wird.

Code:

Copyright (c) 2003-2023 Synology Inc. All rights reserved.

Usage: img_backup

SYNOPSIS
        img_backup -h


        [Action]
        img_backup -B:               Backup
        img_backup -D:               Download
        img_backup -L:               Relink
        img_backup -O:               Clean locks
        img_backup -I:               Do Keep Alive
        img_backup -C:               Discard
        img_backup -W:               Wait Process
        [Parameters]
        img_backup -k Task ID:
        img_backup -K Task Config String:
        img_backup -P Repo Config String:
        img_backup -p: Files for Parameter String (option map serialized string)
        img_backup -i: silent, not verbose
        img_backup -U: unique id for job queue daemon
        img_backup -n: resume backup
        img_backup -w: don't resume or discard the suspended task before backing up
        img_backup -d: get remote version delete status
        img_backup -R: not rebuild index on relinking
        [Examples]

          -  Do direct backup (Backup Now) with task ID
        img_backup -B -w -k TASK_ID

          -  If the task is supended, resume or discard the task and then do backup with task ID
          -  (it is used for scheduled backup)
        img_backup -B -k TASK_ID

          -  Do direct resume with task ID
        img_backup -B -k TASK_ID -n

          -  Discard last backup version by task ID
        img_backup -C -k TASK_ID

          - Wait process done and discard last backup version by task ID
        img_backup -W -C -k TASK_ID

          -  Full relink
        img_backup -L -K TASK_CONFIG_JSONSTR -P REMO_CONFIG_STR

          -  Do Keepalive
        img_backup -I -p PARAMETER_FILE

          -  Clean all locks
        img_backup -O -k TASK_ID

Code:

Usage:
  synobackup <action> [options...]

Actions:
  -h, --help
  --running-on-dev <dev name>     check local backup is running on dev or not.
  --cancel-backup
  --backup <task id>
  --export-task-config <task id> <export_path>
  --clean-backup-snapshot                       return 0 if success
  --mark-share-fullbackup <share name> <share name> ...         return 0 if success

Code:

usage:
1) remove marked versions:
   synoimgbkptool -r REPO_PATH -t TARGET_ID -I loginUid -c
2) set save-point (duplicate necessary index/DB):
   synoimgbkptool -r REPO_PATH -t TARGET_ID -s [bkp|del|sus]
3) set save-point and update guard file CRC (duplicate necessary index/DB):
   synoimgbkptool -r REPO_PATH -t TARGET_ID -s [bkp|del|sus] -K 2
4) roll back:
   synoimgbkptool -r REPO_PATH -t TARGET_ID -b
5) roll back and designate the objective target's status, pid, and pcmd:
   synoimgbkptool -r REPO_PATH -t TARGET_ID -b -a STATUS -i PID -m PCMD
6) roll back followed by version deletion:
   synoimgbkptool -r REPO_PATH -t TARGET_ID -b -d LIST_VERSION_ID
   Example: synoimgbkptool -r /volume1/shareName -t 3 -b -d 1,2,5,3,7,
7) scan all repositories or repositories in specific volume and roll-back needed local/remote targets:
   synoimgbkptool -n -y local
   synoimgbkptool -n -y remote
   synoimgbkptool -n -y local -q VOLUME_PATH
   synoimgbkptool -n -y remote -q VOLUME_PATH
8) scan all  repositories or repositories in specific volume and mark the local/remote targes needing migrate scan:
   synoimgbkptool -M -y local
   synoimgbkptool -M -y remote
   synoimgbkptool -M -y local -q VOLUME_PATH
   synoimgbkptool -M -y remote -q VOLUME_PATH
10)do version rotation:
   synoimgbkptool -r REPO_PATH -t TARGET -o
11)do repository upgrade
   synoimgbkptool -g VOLUME_PATH
12)scan all volumes to do repository upgrade
   synoimgbkptool -G
13)remove specified versions (Image Cloud):
   synoimgbkptool -k TASK_ID -c -C -v 1,2,3
14)rotate versions (Image Cloud):
   synoimgbkptool -k TASK_ID -o -C
15)clear temp folders in the all cloud image cache
   synoimgbkptool -e
16) compute the space usage of the target:
   synoimgbkptool -r REPO_PATH -t TARGET_ID -p
17) compute the space usage of the cache (Image Cloud):
   synoimgbkptool -r REPO_PATH -t TARGET_ID -k TASK_ID -P
18) scan image remote target in volume:
   synoimgbkptool -l SHARE_NAME
19) scan image remote target and reset target action in server target list:
   synoimgbkptool -L
20)recover virtual-file index reference count and skip invalid broken records
   synoimgbkptool -r REPO_PATH -t TARGET -f -R vf
21)recover virtual-file index reference count and stop if any broken record is found
   synoimgbkptool -r REPO_PATH -t TARGET -R vf
23)perform error detection on index
   synoimgbkptool -r REPO_PATH -t TARGET -z i -T LAUNCH_TIME
23)perform error detection on index, data and guard
   synoimgbkptool -r REPO_PATH -t TARGET -z idg -x SESSION_INFO_PATH -T LAUNCH_TIME
24)update candidate chunk db into guard db, <type|idx|name>
   synoimgbkptool -r REPO_PATH -t TARGET -u <1|-1|config/candidate_chunk.db>
25)update 6.0 beta cloud image cache owner and mode
   synoimgbkptool -U
26)compact a bucket of objective cloud target (synocloud):
   synoimgbkptool -k TASK_ID -B BUCKET_ID
27)vacuum cand-chunk db
   synoimgbkptool -r REPO_PATH -t TARGET -V cand
28)vacuum version-list db
   synoimgbkptool -r REPO_PATH -t TARGET -V ver
29)integrity check with time limit
   synoimgbkptool -r REPO_PATH -t TARGET -z id -T LAUNCH_TIME -O TIME_LIMIT
-r, --repository             indicate the objective repository
-t, --target                 indicate the objective target
-c, --compact                unlink and compact the objective target
-s, --save-point             duplicate necessary index/DB when backup(bkp) or delete(del) or suspend(sus) in the objective target
-b, --roll-back              roll back the objective target
-i, --pid                    assign pid to the objective target after roll back
-m, --pcmd                   assign pcmd to the objective target after roll back
-a, --status                 assign status to the objective target after roll back
-d, --run-del                a list of version ids for deletion
-n, --roll-back-scan         scan all targets after service start
-M, --mark-migrate           mark the target need migrate scan
-o, --version-rotate         execute version rotation
-g, --repository-upgrade     repository upgrade
-v, --version                 versions
-G, --all-repo-upgrade       scan all available volumes to do repository upgrade
-C, --cloud-cache            work for cloud cache
-e, --clear-cache-tmp        clear temp folders in all cloud caches
-E, --error-info             save error-info at the desired path
-p, --space-local            compute the local space usage for a target
-P, --space-cloud            compute the cloud space usage for a target
-l, --scan-target             scan image remote target in share
-L, --scan-target-all        scan image remote target and reset target action
-y, --scan-type              target type for scan is local/remote
-R, --recover                recover index reference count; vf: virtual-file index
-f, --force                  force to recover index reference count
-z, --detect                 perform error detection on index only
-x, --session-info           path for session info
-u, --update-guard           update file in guard db
-U, --update-cloudcache      update 6.0 beta cloud cache
-V, --vacuum                 vacuum DB; cand: cand-chunk DB, ver: version-list DB
-B, --server-compact         compact the indicate bucket of objective cloud target (synocloud)
-T, --launch-time            launch time, used by error detect
-O, --time-limit             time limit for integrity data part
-S, --silent                 be silent and do not print log, for delete version local only
-K, --save-option            save-point option [SAVEPT_RUN_AFTER_WRTIE_COMPLETE = 0x01
                                                SAVEPT_UPDATE_FILE_CRC = 0x02]

Code:

Copyright (c) 2003-2023 Synology Inc. All rights reserved.

Code:

Copyright (c) 2003-2023 Synology Inc. All rights reserved.

Code:

Usage:
  synobackup <action> [options...]

Actions:
  -h, --help
  --update-config <new version> check and update synobackup.conf. if success, update version of conf. ex: binary --update-config 1.1.0-0001
  --update-last-result <new version>    check and update backup.last. if success, update version of backup.last. ex: binary --update-last-result 1.1.0-0100
  --check-ext3-bad-archive      check there are backup task on ext3 volume with bad archive version or not. ex: binary --check-ext3-bad-archive

luddi · 03. Sep 2023

Hallo zusammen, ich habe nach einer Möglichkeit gesucht die Task-ID direkt über das Skript mittels des Task-Namen zu identifizieren.
Das könnte dem ein oder anderen helfen die Task-ID nicht für jede Aufgabe explizit manuell bestimmen zu müssen.

Hier einmal das Script:

Bash:

#!/bin/bash

# Shell Colors
#Black='\e[0;30m'
#Red='\e[0;31m'
Green='\e[0;32m'
Yellow='\e[0;33m'
Blue='\e[0;34m'
#Purple='\e[0;35m'
#Cyan='\e[0;36m'
#White='\e[0;37m'
Error='\e[41m'
C_Off='\e[0m'

# Wait time to remain in loop for a continous check if process is still running
wait=60

# Check if Argument is given, otherwise abort operation
if ! [ -z "$1" ]; then
  taskname="$1"
else
  echo -e "${Error}"No Argument given! Abort Script execution..."${C_Off}"
  exit 255
fi

# Identify task ID of Backup Job via unique task name
taskid=$(synoschedtask --get | awk -v pat="Name: \\\[$taskname\\\]" '$0~pat' RS= | grep dsmbackup | grep -Eo [0-9]+)

# Check if task ID could identified, otherwise abort operation
if [ -z "$taskid" ]; then
  echo -e "${Error}"No Task ID idendified! Abort Script execution..."${C_Off}"
  exit 128
fi

# Check if task ID variable contains numbers only, otherwise abort operation
if [[ "$taskid" =~ ^[0-9]+$ ]]; then
  echo -e Identified Task ID: "${Blue}""$taskid""${C_Off}"
else
  echo -e "${Error}"Task ID invalid, does not contain numbers only! Abort Script execution..."${C_Off}"
  exit 64
fi

# Start HyperBackup job with previous identified task ID !!! No Error handling implemented, just firing dsmbackup !!!
/var/packages/HyperBackup/target/bin/dsmbackup --backup "$taskid"

# Identify process ID of previous invoked Hyper Backup Job via "ps aux"
pid=$(ps aux | grep -v grep | grep -E "/var/packages/HyperBackup/target/bin/(img_backup|dsmbackup|synoimgbktool|synolocalbkp|synonetbkp|updatebackup).+-k $taskid" | awk '{print $2}')
echo -e PID of Backup Task: "${Yellow}""$pid""${C_Off}"

# Check continously if PID is still running and leave loop when process has finished
while ps -p $pid > /dev/null; do
  #echo Processing Backup...
  sleep "$wait"
done
echo -e "${Green}"Backup with PID "$pid" finished!"${C_Off}"

exit 0

Aufgerufen wird das Script mit Angabe des jeweiligen Task Namen als Argument.
Hier ein Beispiel:
Es wurde hierfür in meiner Umgebung die Aufgabe mit dem Namen "hetzner_nextcloud" verwendet so wie der Name auch unter Hyper Backup zu finden ist.

Aufruf des Scripts mit Ausgabe auf der Konsole:

Bash:

root@MyNAS: ~  $ ./hyperbackup.sh hetzner_nextcloud
Identified Task ID: 185
PID of Backup Task: 32248
Backup with PID 32248 finished!

Falls man einen Namen verwendet welcher nicht definiert ist, so wird auch keine entsprechende Task gefunden und die Ausführung des Scripts beendet wie in diesem Beispiel gezeigt.

Code:

root@MyNAS: ~  $ ./hyperbackup.sh foo
No Task ID idendified! Abort Script execution...

Sollte man in dem Task Namen aus unerklärlichen Gründen Leerzeichen verwendet haben, dann bitte daran denken diese entsprechend mit einem escape Character zu versehen oder den gesamten Namen in double Quotes zu setzten.
Das würde in diesem Fall etwa so aussehen.
Option A: ./hyperbackup.sh hetzner\ nextcloud
Option B: ./hyperbackup.sh "hetzner nextcloud"

Probiert es doch gerne in eurer Umgebung aus und lasst mich wissen wenn es hier noch Nachholbedarf gibt bzw. es sich bei dem ein oder anderen anders verhält als von mir gedacht.

Tommes · 03. Sep 2023

Hey @luddi
Ich würde die Tage gerne mal versuchen, ob ich die Identifizierung der Task-ID irgendwie für AutoPilot nutzbar machen kann. Ich würde dazu zunächst einfach ein Eingabefeld generieren, indem man den Hyper Backup Auftragsnamen eingeben kann um dann nach der Task-ID zu suchen. Sollte das klappen… wäre es okay für dich, wenn ich mir deinen Code bzw. Teile davon unter den Nagel reiße?

luddi · 03. Sep 2023

Hi @Tommes, Feuer frei!
Ja das wäre doch eine coole Sache wenn du das direkt mit Eingabefeld für den Auftragsnamen in AutoPilot integrieren kannst.
Absolut okay für mich wenn du den Code (für was auch immer) verwndest, ist ja schließlich kein Geheimnis und bereits hier publiziert.

abrocksi · 04. Sep 2023

luddi schrieb:
Hallo zusammen, ich habe nach einer Möglichkeit gesucht die Task-ID direkt über das Skript mittels des Task-Namen zu identifizieren.
Das könnte dem ein oder anderen helfen die Task-ID nicht für jede Aufgabe explizit manuell bestimmen zu müssen.

Aufruf des Scripts mit Ausgabe auf der Konsole:

Bash:

root@MyNAS: ~ $ ./hyperbackup.sh hetzner_nextcloud Identified Task ID: 185 PID of Backup Task: 32248 Backup with PID 32248 finished!

Hallo Luddi,

habe heute Dein Script getestet. Funktioniert soweit. Vielen Dank.

Allerdings habe ich den Eindruck, dass alle getesteten Hyper-Bakup-Jobs nicht nur hinsichtlich ID abgefragt, sondern auch gestartet wurden. Ich bekam 3 Mails vom NAS, dass der Job xyz gestartet wurde. Da die entsprechenden Festplatten aber nicht angeschlossen waren, sind die Backups mit Fehlern abgebrochen.

Ist das beabsichtigt? Ich dachte, dass Script dient dazu die IDs herauszufinden.

cheers,
abrocksi

luddi · 04. Sep 2023

Hi @abrocksi,

Das ist schon richtig! Das von mir publizierte Script sucht die entsprechende Task-ID heraus UND startet das Backup.

Das ist der Aufruf in dem Script um den Job zu starten.

Bash:

# Start HyperBackup job with previous identified task ID !!! No Error handling implemented, just firing dsmbackup !!!
/var/packages/HyperBackup/target/bin/dsmbackup --backup "$taskid"

Oder habe ich deine Anmerkung falsch verstanden?

Tommes · 04. Sep 2023

Nur so eine Idee. Vielleicht lauten die Aufträge von @abrocksi ähnlich, fangen gleich an oder enden gleich. Evtl. (Hab es mir nicht weiter angeschaut) filterst du nicht explizit nach dem Auftragsnamen sondern nur auf „muß enthalten“. Das würde erklären, warum mehrere Aufträge ausgeführt wurden.

abrocksi · 04. Sep 2023

luddi schrieb:
Oder habe ich deine Anmerkung falsch verstanden?

Ja, hast Du richtig verstanden. Dann kommentier ich das eben aus.

Ich wollte das Script nutzen, um die ID herauszufnden und nicht damit den Job anzuschmeißen. Wäre natürlich auch eine Idee.

Vielen Dank

Cheers,
abrocksi

luddi · 04. Sep 2023

@abrocksi Ihr könnt ja das Script verwenden für was auch immer ihr möchtet. Ich biete ja hier keine Individaullösung für Jedermann sondern wollte eignetlich nur das von @plang.pl erwähnte Script aus Beitrag #1 erweitern damit die ID über den Namen identifiziert wird.
Also habe ich den Aufruf um den Backup Job zu starten hier auch nicht entfernt.

Alle meine Scripte und Code Schnipsel sollen lediglich eine Hilfe sein um sie dann für die eigenen Bedürnisse anpassen zu können oder nur Teile davon wiederzuverwerten.

@Tommes, den Befehl den ich hierfür verwende um die ID herauszufinden sucht exakt nach dem Namen und nicht nach dem Muster "muss enthalten". Es wird nach folgendem String gesucht Name: [$taskname] und muss exakt so lauten.

Der Befehl liefert in meinem Fall zwei Resultate mit dem gleichen Namen, einmal die Scheduled ID 74 und 75.
Der einzige Unterschied ist, dass die Schedule ID 75 für die Integritätsprüfung zuständig ist und die ID 74 für das Backup selbst.
Man kann den Unterschied am Atrribut "CmdArgv" erkennen, einmal wird die Binary "detect_monitor" aufgerufen und im Falle des Backup Jobs die Binary "dsmbackup".

Code:

root@MyNAS: ~  $ synoschedtask --get | awk -v pat="Name: \\\[hetzner_nextcloud\\\]" '$0~pat' RS=
             User: [root]
               ID: [75]
             Name: [hetzner_nextcloud]
            State: [enabled]
            Owner: [root]
              App: [SYNO.SDS.Backup.Application]
          AppName: [#backup:backup_replication#]
             Type: [weekly]
       Start date: [0/0/0]
     Days of week: [Mon]
         Run time: [2]:[34]
     Next Trigger: [2023-09-11 02:34]
          CmdArgv: ['/var/packages/HyperBackup/target/bin/detect_monitor' '-t' '-k' '185' '-f' '-T' '-1']
          Command: [\/\v\a\r\/\p\a\c\k\a\g\e\s\/\H\y\p\e\r\B\a\c\k\u\p\/\t\a\r\g\e\t\/\b\i\n\/\d\e\t\e\c\t\_\m\o\n\i\t\o\r \-\t \-\k \1\8\5 \-\f \-\T \-\1]
           Status: [Not Available]
             User: [root]
               ID: [74]
             Name: [hetzner_nextcloud]
            State: [enabled]
            Owner: [root]
              App: [SYNO.SDS.Backup.Application]
          AppName: [#backup:backup_replication#]
             Type: [daily]
       Start date: [0/0/0]
         Run time: [3]:[17]
     Next Trigger: [2023-09-05 03:17]
          CmdArgv: ['/var/packages/HyperBackup/target/bin/dsmbackup' '--backup' '185']
          Command: [\/\v\a\r\/\p\a\c\k\a\g\e\s\/\H\y\p\e\r\B\a\c\k\u\p\/\t\a\r\g\e\t\/\b\i\n\/\d\s\m\b\a\c\k\u\p \-\-\b\a\c\k\u\p \1\8\5]
           Status: [Not Available]

Wenn man hier z.B. nur nach einem Teil des Task Namen sucht bekommt man kein Resultat:

Code:

# Suche nach Teil des Namens, Bsp: hetzner_

root@MyNAS: ~  $synoschedtask --get | awk -v pat="Name: \\\[hetzner_\\\]" '$0~pat' RS=
# Hier wird nichts gefunden und es folgt somit keine Ausgabe. Es wird ohnehin im Anschluss abgefangen falls die Variable taskid leer ist.

Hängt man an diesen Befehl noch ein grep an um nach dsmbackup zu suchen bekommt man eben genau diese Zeile des Attributs "CmdArgv" ausgegeben.

Code:

root@MyNAS: ~  $synoschedtask --get | awk -v pat="Name: \\\[hetzner_nextcloud\\\]" '$0~pat' RS= | grep dsmbackup
          CmdArgv: ['/var/packages/HyperBackup/target/bin/dsmbackup' '--backup' '185']

Und am Schluss wird noch die Nummer herausgefiltert mit grep -Eo [0-9]+.

Code:

synoschedtask --get | awk -v pat="Name: \\\[hetzner_nextcloud\\\]" '$0~pat' RS= | grep dsmbackup | grep -Eo [0-9]+
185

Sollte ich wohl irgendeinen wichtigen Punkt vergessen haben oder es Verbesserungsvorschläge für die eindeutige Erkennung gibt dann gerne her damit.

Tommes · 04. Sep 2023

Au man @luddi, es geht schon wieder los mit uns beiden. Ich habe sowohl @abrocksi Frage falsch interpretiert und mir auch nicht die Mühe gemacht, dein Script genauer in Augenschein zu nehmen, wobei ich eigentlich hätte wissen müssen, das du an all das denkst. Ich setz mich daher schnell wieder auf meine Hände, werde mir die Tage dein Script genauer anschauen und versuchen es mit AutoPilot zu verbinden, bevor ich weiter rede!

luddi · 04. Sep 2023

Das ist ja schön dass du so denkst. Ich würde von mir aber nicht behaupten immer an alles gedacht zu haben, auch ich bin ein Mensch und mache Fehler. Deshalb fragte ich nach eurem Feedback ob hier im Individualfall noch etwas anders läuft als erwartet. Es kann ja sein, dass meine Config nicht alle Möglichkeiten enthält und ihr evlt. auch andere Einträge habt was dazu führen kann die ID nicht richtig erkennen zu können.

Und ich habe mir dabei extra Mühe gegeben die einzelnen Schritte im Scirpt zu kommentieren

Tommes · 04. Sep 2023

luddi schrieb:
Und ich habe mir dabei extra Mühe gegeben die einzelnen Schritte im Scirpt zu kommentieren

Und ich habe mich ja bereits dafür entschuldigt, das ich …

Tommes schrieb:
…mir auch nicht die Mühe gemacht […habe…], dein Script genauer in Augenschein zu nehmen

… und schäme mich auch dafür.

Also hör bitte auf, in offenen Wunden rum zu popeln

…und ich schieb die Hände jetzt auch wieder unter mein Gesäß!

luddi · 04. Sep 2023

Alles gut @Tommes ich weiß doch dass wir uns verstehen

Du brauchst dich dafür nicht zu entschuldigen.

Tommes · 16. Sep 2023

Tommes schrieb:
Ich würde die Tage gerne mal versuchen, ob ich die Identifizierung der Task-ID irgendwie für AutoPilot nutzbar machen kann.

Hat geklappt! AutoPilot kann ab sofort neben Basic Backup, auch Hyper Backup Aufgaben verarbeiten. Das bedeutet, das innerhalb der AutoPilot GUI alle gefundenen Backup Aufgaben der grade genannten Apps aufgelistet werden. Möchte man eine Aufgabe durch anstecken eines ext. Datenträgers automatisch ausführen lassen, wählt man die entsprechende Aufgabe und den passenden ext. Datenträger aus und AutoPilot legt auf diesem dann eine AutoPilot Scriptdatei mit entsprechendem Inhalt an.

Wer es gerne ausprobieren möchte: Links zu AuoPilot findet ihr in meiner Signatur

Tommes