Ultimate Backup Ultimate Backup

dachserl · 27. Apr. 2017

Hallo Tommes,

danke - war bisher stiller Leser

Hier einmal das komplette Debug - entweder habe ich Tomaten auf den Augen oder foundbackups.txt ist dort nicht zu finden.

Danke schonmal vorab!

Rich (BBCode):

Gesetzte Variablen:

BASH=/bin/bash
BASHOPTS=cmdhist:complete_fullquote:extquote:force_fignore:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath
BASH_ALIASES=()
BASH_ARGC=([0]="1")
BASH_ARGV=([0]="./debug.sh")
BASH_CMDS=()
BASH_LINENO=([0]="145" [1]="0")
BASH_SOURCE=([0]="./debug.sh" [1]="/usr/syno/synoman/webman/3rdparty/UltimateBackup/index.cgi")
BASH_VERSINFO=([0]="4" [1]="3" [2]="48" [3]="1" [4]="release" [5]="armle-unknown-linux-gnu")
BASH_VERSION='4.3.48(1)-release'
CONTENT_LENGTH=
CONTENT_TYPE=
DIRSTACK=()
DOCUMENT_ROOT=/usr/syno/synoman
DOCUMENT_URI=/webman/3rdparty/UltimateBackup/index.cgi
ENABLE_X_ACCEL_REDIRECT=yes
EUID=0
GATEWAY_INTERFACE=CGI/1.1
GROUPS=()
HOSTNAME=DachsStation
HOSTTYPE=armle
HTTPS=on
HTTP_ACCEPT='text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8'
HTTP_ACCEPT_ENCODING='gzip, deflate, sdch, br'
HTTP_ACCEPT_LANGUAGE='de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4'
HTTP_CONNECTION=keep-alive
HTTP_COOKIE='stay_login=0; id=m7UhBJz9pjofY1510MYN335101'
HTTP_HOST=nas.dachs.lan:5001
HTTP_REFERER=https://nas.dachs.lan:5001/webman/3rdparty/UltimateBackup/index.cgi
HTTP_UPGRADE_INSECURE_REQUESTS=1
HTTP_USER_AGENT='Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36'
IFS=$' \t\n'
INSTANCE=
JOB=apparmor
MACHTYPE=armle-unknown-linux-gnu
OPTERR=1
OPTIND=1
OSTYPE=linux-gnu
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/syno/bin:/usr/syno/sbin
PATH_INFO=
PIPESTATUS=([0]="0")
PPID=5539
PS4='+ '
PWD=/volume1/@appstore/UltimateBackup
QUERY_STRING=page=debug
REMOTE_ADDR=192.168.179.90
REMOTE_PORT=53946
REQUEST_METHOD=GET
REQUEST_SCHEME=https
REQUEST_URI='/webman/3rdparty/UltimateBackup/index.cgi?page=debug'
SCGI=1
SCRIPT_FILENAME=/usr/syno/synoman/webman/3rdparty/UltimateBackup/index.cgi
SCRIPT_NAME=/webman/3rdparty/UltimateBackup/index.cgi
SERVER_ADDR=192.168.179.119
SERVER_NAME=nas.dachs.lan
SERVER_PORT=5001
SERVER_PROTOCOL=HTTP/1.1
SERVER_SOFTWARE=nginx/1.11.3
SHELL=/bin/ash
SHELLOPTS=braceexpand:hashall:interactive-comments
SHLVL=1
SOCKET=/run/synoscgi.sock
TERM=linux
UID=0
UPSTART_EVENTS='syno.network.ready started'
UPSTART_INSTANCE=
UPSTART_JOB=synoscgi
_='

Gesetzte Variablen:
'
backifs=$' \t\n'
debuginfo=$'foundbackups.txt\nvar.txt'
decode_value=debug
dir=/volume1/@appstore/UltimateBackup
encode_page=debug
encode_value=debug
login=$'\ntoken: B7bY4WYTDdpmI user: admin\n admin: 1'
login_admin=1
login_user=admin
mainpage=debug
page=debug
script=debug.sh
site=debug
siteless=
sitemore=
stop=/volume1/@appstore/UltimateBackup/usersettings/stop.txt
usersettings=/volume1/@appstore/UltimateBackup/usersettings
var=/volume1/@appstore/UltimateBackup/usersettings/var.txt
variable=page

Tommes · 27. Apr. 2017

Das ist ja seltsam. Kannst du bitte mal unter "Aufträge" die Auftragsliste aktualisieren, also das Symbol mit den beiden sich drehenden Pfeilen, oben rechts! Nach dem Suchlauf bitte nochmal die Seite "Debug" aufrufen und schauen ob jetzt eine foundbackups.txt existiert. Falls ja, dann sollten die Aufträge auch im Zeitplaner auftauchen. Falls nicht, tja dann... müssen wir weiter suchen.

Tommes

dachserl · 27. Apr. 2017

Na klar - bin nun auf die beiden Pfeile, habe dann auf dem externen Datenträger nach dem Script suchen lassen, dieses wurde auch gefunden.

Neues Debug:

Rich (BBCode):

Gesetzte Variablen:

BASH=/bin/bash
BASHOPTS=cmdhist:complete_fullquote:extquote:force_fignore:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath
BASH_ALIASES=()
BASH_ARGC=([0]="1")
BASH_ARGV=([0]="./debug.sh")
BASH_CMDS=()
BASH_LINENO=([0]="145" [1]="0")
BASH_SOURCE=([0]="./debug.sh" [1]="/usr/syno/synoman/webman/3rdparty/UltimateBackup/index.cgi")
BASH_VERSINFO=([0]="4" [1]="3" [2]="48" [3]="1" [4]="release" [5]="armle-unknown-linux-gnu")
BASH_VERSION='4.3.48(1)-release'
CONTENT_LENGTH=
CONTENT_TYPE=
DIRSTACK=()
DOCUMENT_ROOT=/usr/syno/synoman
DOCUMENT_URI=/webman/3rdparty/UltimateBackup/index.cgi
ENABLE_X_ACCEL_REDIRECT=yes
EUID=0
GATEWAY_INTERFACE=CGI/1.1
GROUPS=()
HOSTNAME=DachsStation
HOSTTYPE=armle
HTTP_ACCEPT='text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8'
HTTP_ACCEPT_ENCODING='gzip, deflate, sdch'
HTTP_ACCEPT_LANGUAGE='de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4'
HTTP_CONNECTION=keep-alive
HTTP_COOKIE='stay_login=0; id=kzcCFoeSRMGzE1510MYN335101'
HTTP_HOST=192.168.179.119:5000
HTTP_REFERER='http://192.168.179.119:5000/webman/3rdparty/UltimateBackup/index.cgi?page=start'
HTTP_UPGRADE_INSECURE_REQUESTS=1
HTTP_USER_AGENT='Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36'
IFS=$' \t\n'
INSTANCE=
JOB=apparmor
MACHTYPE=armle-unknown-linux-gnu
OPTERR=1
OPTIND=1
OSTYPE=linux-gnu
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/syno/bin:/usr/syno/sbin
PATH_INFO=
PIPESTATUS=([0]="0")
PPID=6017
PS4='+ '
PWD=/volume1/@appstore/UltimateBackup
QUERY_STRING=page=debug
REMOTE_ADDR=192.168.179.94
REMOTE_PORT=61372
REQUEST_METHOD=GET
REQUEST_SCHEME=http
REQUEST_URI='/webman/3rdparty/UltimateBackup/index.cgi?page=debug'
SCGI=1
SCRIPT_FILENAME=/usr/syno/synoman/webman/3rdparty/UltimateBackup/index.cgi
SCRIPT_NAME=/webman/3rdparty/UltimateBackup/index.cgi
SERVER_ADDR=192.168.179.119
SERVER_NAME=192.168.179.119
SERVER_PORT=5000
SERVER_PROTOCOL=HTTP/1.1
SERVER_SOFTWARE=nginx/1.11.10
SHELL=/bin/ash
SHELLOPTS=braceexpand:hashall:interactive-comments
SHLVL=1
SOCKET=/run/synoscgi.sock
TERM=linux
UID=0
UPSTART_EVENTS='syno.network.ready started'
UPSTART_INSTANCE=
UPSTART_JOB=synoscgi
_='

Gesetzte Variablen:
'
backifs=$' \t\n'
debuginfo=$'foundbackups.txt\nvar.txt'
decode_value=debug
dir=/volume1/@appstore/UltimateBackup
encode_page=debug
encode_value=debug
login=$'\ntoken: vzdUeD8FWW8kU user: admin\n admin: 1'
login_admin=1
login_user=admin
mainpage=debug
page=debug
script=debug.sh
site=debug
siteless=
sitemore=
stop=/volume1/@appstore/UltimateBackup/usersettings/stop.txt
usersettings=/volume1/@appstore/UltimateBackup/usersettings
var=/volume1/@appstore/UltimateBackup/usersettings/var.txt
variable=page

Gruß

PsychoHH · 27. Apr. 2017

Ah alles klar.
Haben zuletzt die ganze Suche geändert.
Ich schaue mir das bald mal an.

Danke

Swp2000 · 02. Mai 2017

Kann man mit UB auch eine bereits gesicherten Datenkopie wieder aufnehmen? Sprich, wenn das Quell NAS neu installiert werden musste, sodass ich meine bereits gesicherten Daten an der Stelle wieder fortführen kann, oder ist dies nicht möglich?
Das vermisste ich bei der "Remote Datenkopie" von Synology schon. Ich möchte ungern nochmal x- TB an Daten neu sichern nur weil der Backup Job weg ist.

Tommes · 02. Mai 2017

Ehrlich gesagt habe ich dieses Szenario noch nie durchgespielt, aber theoretisch sollte dein Vorhaben funktionieren. Das setzt jedoch voraus, das weder an den Daten in der Qelle noch im Ziel zwischenzeitlich etwas verändert wurde. Wirklich aussagekräftig wäre aber wohl nur ein Selbstversuch... also nur zu. Wenn ich die Zeit dafür finde (aktuell leide ich mal wieder unter akutem Zeitmangel), werde ich das auch gerne mal selber austesten. Ich kann dir aber nicht sagen, wann das sein wird.

Tommes

PsychoHH · 02. Mai 2017

Sollte klappen.

WoodyT · 02. Mai 2017

Ich habe dieses Szenario schon getestet, mit Erfolg. Und da muss ich leider dem Entwickler widersprechen, eine Änderung auf dem Quell NAS ist unerheblich. Genau das ist ja das gewünschte. Rsync vergleicht die Daten und sichert die Änderungen. Eine Voraussetzung gibt es aber schon, der Pfad zur Sicherung und die Freigaben auf der Quell NAS müssen identisch sein.

m0useP4d · 02. Mai 2017

Swp2000 schrieb:
Das vermisste ich bei der "Remote Datenkopie" von Synology schon. Ich möchte ungern nochmal x- TB an Daten neu sichern nur weil der Backup Job weg ist.

Was ist mit "Remote Datenkopie" gemeint und welches Backup Programm?

dil88 · 02. Mai 2017

Es gibt in dem Paket Hyper Backup eine Option namens "Remote Datenkopie", mit der die Daten ins Filesystem einer andere DiskStation geschrieben werden kann (siehe Screenshot).

m0useP4d · 03. Mai 2017

@dil88
Danke für die Info!
Es gibt tatsächlich keine Möglichkeit ein vorhandenes filebasiertes Backup wieder zu verknüpfen

@Swp2000
Hast Du schon neuen Job auf vorhandenes Backup angelegt und trotz der Daten wird alles komplett neu kopiert?
Was sagt Syno-Support dazu?

dil88 · 03. Mai 2017

Ich vermute, dass Synology die Datenkopie nur wieder hinzugenommen hat (hieß vorher "Datensicherung & Replikation"), weil sie mitbekommen haben, dass viele User nur mit einer datenbankbasierten Backuplösung unglücklich sind. Ich kann mir aber nicht vorstellen, dass sie die ernsthaft supporten werden, sondern auf die datenbankbasierte Variante verweisen werden. Mit Ultimate Backup und den passenden Pfaden sollte es m.E. klappen, sehe das wie PsychoHH und Tommes.

Tommes · 03. Mai 2017

Soweit ich informiert bin, funktioniert das Neuverknüfen nur bei einer datenbankbasierten Sicherung, bei einer dateibasierten jedoch nicht. Selbst wenn man anfängt zu tricksen, indem man eine neue Remote Backup Aufgabe konfiguriert, diese kurz startet und kurz danach abbricht. Benennt man dann sein altes Backup-Ziel in das neue um und kopiert die von Synology erstellten Datein des neu erstellten Backups, so werden nach dem erneutem Start des Jobs trotzdem nochmal alle Daten neu geschrieben. So jedenfalls war es, als ich das vor etwas längerer Zeit mal probiert hatte.

Tommes

Swp2000 · 03. Mai 2017

Mh.. ich versuche es mal. Bei mir kommt es in gewissen Abständen bzw. Spätestens bei einer neues Major DSM zu diesem Vorgang. Evtl. Ist das mit der Datenbank für mich dann besser geeignet. Leider habe ich jedoch schonmal gelesen ( wo kann ich nun nicht genau sagrn) das bei dem Datenbank Backup die Dateien später defekt waren und konnten nicht entpackt werden. Das wäre natürlich "Worst Case"

Tommes · 03. Mai 2017

Genau aus diesem Grund ist Ultimate Backup entstanden.

matt42 · 08. Mai 2017

Hallo,
ich hatte in Beitrag #856 schon mal gefragt, warum meine Skripts über den "alle auf einmal" Button nicht funktionieren, und kann nun nach langer Suche endlich die Lösung präsentieren: alle Skripte verwenden die gleiche temporäre Datei "stop.txt".
Wenn also eines der Skripte aus irgendeinem Grund auf einen Fehler läuft (ich komme gleich zu meinem), dann brechen alle Skripte ab - und zwar an unterschiedlichen Stellen (was es so schwierig machte, das ganze einzugrenzen).
Es gibt m.E. eine einfache Lösung dafür:

Rich (BBCode):

stop="${dir}/stop_${scriptname}.txt"

Eines meiner Skripte lief übrigens immer sofort auf einen Fehler, da ich als eine der zu sichernden Quellen eine Datei und kein Verzeichnis angegeben hatte. Gibt es einen speziellen Grund, warum Dateinamen als Quelle nicht erlaubt sind? (Sie werden über das "share_mount=$(find ... -type d ..." abgefangen.)

Dabei ist mir übrigens aufgefallen, dass bei Angabe mehrerer Quellen nicht bei einem Fehler abgebrochen wird, sondern weiter versucht wird, die verbleibenden Quellen zu sichern. Dies führt wiederum dazu, dass ein anderer Exit Code und Fehlermeldung angezeigt werden kann, da dieser mit der "nächsten" Quelle überschrieben werden. Es kann sogar Erfolg vermeldet werden, obwohl mehrere Quellen davor auf Fehler liefen, lediglich die letzte korrekt gesichert wurde.

Schöne Grüße, Matt

PS Danke für die schnelle Änderung des "nv" Parameters.

matt42 · 08. Mai 2017

Nachtrag für alle, die mit mehreren Skripten gleichzeitig auf eine andere DS sichern wollen:
der Standard-Wert für die Anzahl gleichzeitiger ssh Verbindungen liegt bei 10.

Wenn also scheinbar zusammenhanglose Verbindungsabbrüche, oder Sicherungsfehler auftauchen, kann es auch daran liegen.

Dies kann man über den Parameter MaxSessions in der Datei /etc/ssh/sshd_config ändern. Dabei auch den Parameter MaxStartups nicht vergessen. Ggf beide Werte auch in /etc.defaults/ssh/sshd_config übertragen.

Swp2000 · 08. Mai 2017

m0useP4d schrieb:
@Swp2000
Hast Du schon neuen Job auf vorhandenes Backup angelegt und trotz der Daten wird alles komplett neu kopiert?
Was sagt Syno-Support dazu?

Habe beim gestrigen Backup dem Job den gleichen Namen (Storage_1) verpasst, aber leider ohne Erfolg. Er meckert das dieser Job schon vorhanden ist.
So musste ich alles erneut kopieren. Das ist sehr schade. Für mich ist das von großer Bedeutung, im Falle eine Neuinstallation ist sowas natürlich extrem komfortabel.oder wie macht ihr sowas? Bei Szenarirn mit x TB ist das schon sehr sinnvoll.

Tommes · 08. Mai 2017

@matt42
Wow, da hast du dich ja wirklich intensiv mit unserem Script auseinandergesetzt. Vielen Dank schon mal, das du deine gewonnenen Erkenntnisse mit uns teilst. Wir werden uns das anschauen und ggf. einbauen/ändern. Wann wir das aber veröffentlichen, können wir noch nicht genau sagen, da wir im Verborgenen bereits an einer neuen Sache dran sind und wir hierfür ziemlich viel umbauen müssen. Leider ist dieser Umbau sehr Zeitintensiv und Zeit ist bei PsychoHH und mir grad Mangelware. Aber wir bleiben am Ball... dauert halt alles nur was länger.

Tommes

matt42 · 08. Mai 2017

Zeit ist bei mir auch Mangelware, aber wenn Ihr was braucht, pingt mich einfach an. Ich kenn mich mit dem Skript ja jetzt aus

und unterstütze gerne.

Ultimate Backup Ultimate Backup

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Additional post fields

Kaffeautomat