Ultimate Backup Ultimate Backup

[Anguel]

Beim Update von Version 1.3.2 auf 1.3.3 ist der Inhalt des Benutzerordner /volume[X]/@appstore/UltimateBackup/usersettings verloren gegangen worin all eure benutzerdefinierten Einstellungen beheimatet sind. Das hatte zur Folge, das u.a. die Auftragsliste und der Gerätemanager leer blieb.

Seid ihr da sicher? Bei mir verschwindet die Liste nur, während das Backup läuft. Davor und danach sind alle Aufträge zu sehen.

 

[Tommes]

Nach dem Update von 1.3.2 auf 1.3.3. gab es Rückmeldungen von euch, das die Auftragsliste leer bleibt. Ich hab das bei mir dann mehrfach getestet indem ich UB (Abkürzung für Ultimate Backup) komplett deinstalliert hatte um im Anschluss wieder die 1.3.2 zu installieren. Dann habe ich den Ordner /usersettings mit ein paar Daten gefüttert (Auftragsliste, Serverdaten aus dem Gerätemanager, etc.) und im Anschluss auf 1.3.3 upgedated. Ergebnis war, das Sowohl Auftragsliste als auch der Gerätemaner leer blieben.

Grund dafür ist ein Kopierfehler in den Installationsscripten von UB, da ich hier u.a. vom Ordner /tmp/ub/ auf den Ordner /tmp/UltimateBackup umgestellt hatte. Die benutzerdefinierten Daten der 1.3.2 liegen zwar unter /tmp/UltimateBackup wurden jedoch nicht mehr zurück in die 1.3.3 kopiert. Dazu mußt du wissen, das auch bei einem Update das komplette SPK deinstalliert und anschließend wieder installiert wird. Unter /tmp/UltimateBackup sichern wir also nötige Daten bevor die Deinstallation losgeht, daher sind die Daten glücklicherweise noch vorhanden.

Die Frage ist nun: Sollen wir euch die Daten automatsch wieder zurückbringen oder wollt ihr das ggf. lieber zu Fuß erledigen. Egal wir das Problem lösen, es wird eh wieder ein Chaos geben. Hier bei mir habe ich das automatische zurückholen der Daten bereits fertig geschrieben. Ich könnte auch hingehen und einfach einen anderen Zielpfad angeben, das die Daten irgendwo für euch greifbar bleiben... bestenfalls auch unter /tmp/UB_Settings_132 z.B. ..... mir egal.

Tommes

 

[ong10]

Hallo,

Zwischeninfo:
Habe eben ein Backup von 4TB laufen lassen das alle Shares sichert. Lief gut durch, doch die Log-Ausgabe gefällt mir noch nicht ganz. Werde also in den nächsten Tagen eine neue Version posten in der das "normale" Log noch deutlicher mitteilt was Sache ist.

Olaf

 

[uwe-beach]

...
Solltet ihr zwischenzeitlich neuere Daten unter .../usersettings abgelegt haben, werden diese überschrieben. Falls dieses Verhalten nicht gewünscht ist, bitte melden.
...

Hallo,

ich habe im Gerätemanager das Zielgerät wieder angelegt und den Job im Zeitplaner wieder eingetragen.
Für mich läuft das Backup jetzt wieder.
Diese Einstellungen sollten mit dem nächsten Update nicht überschrieben werden.

Mir ist aufgefallen, daß beim Bearbeiten eines Auftrages die rsync-Spezifischen Einstellungen so angezeigt werden, wie sie im rsync-Skript vorhanden sind. z.B. eigene Anpassungen beim Ausschlussverhalten werden angezeigt. Beim Schreiben des rsync-Skriptes gehen die
eigenen Anpassungen aber verloren. Eben getestet mit 1.3.3.


uwe

 

[Tommes]

@uwe
Wir haben das jetzt so gelöst, das die verloren gegangenen /usersettings - also eure persönlichen Einstellungen - beim Update auf die nächste Version unter /tmp/UltimateBackupFix/usersettings verschoben werden. Dann kann jeder selbst entscheiden, was er davon zurück haben möchte. Leider ist dieses dann mit einem Besuch auf der Konsole verbunden... aber besser als nichts.

Bezüglich der rsync-Spezifischen Einstellungen... bei mir funktioniert das. Grade eben getestet.

@all
Das Update wird wohl erst morgen kommen. Wie grübeln grade noch über das Umlauteproblem nach und wie wir das alles in Zukunft handhaben wollen.

Tommes

 

[ong10]

Hallo Tommes,

hilft bei den Umlauten nicht meine Lösung ( Variable characterset)?

Olaf

 

[Tommes]

Wir verstehen nicht ganz was du mit --iconv=utf8,utf8 bezwecken willst. Es ergibt für uns keinen Sinn die selbe Codepage als Quelle und Ziel anzugeben. Oder soll das vielleicht Codepages ala de_DE.utf8 und en_GB.utf8 egalisieren?

 

[Anguel]

Leider ist dieses dann mit einem Besuch auf der Konsole verbunden... aber besser als nichts.

Haken im Installer wäre natürlich optimal ;-)

Aber mein 3.6 TB Backup ist endlich durch, so dass ich testen konnte und ich poste mal wie mein Problem aussieht:
Vor dem Backup: Auftrag zu sehen (1 Screenshot)
Während des Backups: Auftrag weg und nicht auffindbar (3 Screenshots)
Nach dem Backup: Auftrag wieder da (1 Screenshot)
Ich glaube nicht, dass das an der Installation liegt, da ich die Einstellungen neu vorgenommen und das Skript komplett neu erstellt hatte.

EDIT: Da diese Forumsoftware nervt, hier die Screenshots in Google Drive:
https://drive.google.com/open?id=14gw4f6FefUJ8v2E6vWQPKX3EZPEKTf8a

 

[Tommes]

Haken im Installer wäre sicherlich eine Option. Mal schau‘n. Da es sich aber um keine Lebenswichtigen Daten handelt und man die Auftragsliste sowie die Serverdaten für den Gerätemanager relativ Fix wieder implementiert hat, stellt sich die Frage, ob der ganze Aufwand überhaupt lohnt.

Deine Screenshots haben aber erstmal nichts gemein mit meinen und PsychoHH‘s Tests. Wir haben Probleme dieses Verhalten bei uns nachzustellen. Keine Ahnung welche Anomalien da wieder am Werke sind.

 

[Anguel]

Deine Screenshots haben aber erstmal nichts gemein mit meinen und PsychoHH‘s Tests. Wir haben Probleme dieses Verhalten bei uns nachzustellen. Keine Ahnung welche Anomalien da wieder am Werke sind.

Ich hatte mal vorgestern einige UB-Dateien, die sich zwischen 1.3.2 und 1.3.3 ändern mal kurz verglichen, aber keine Hinweise auf einen möglichen Fehler gefunden. Die Frage ist, was im Interface anders ist, wenn ein Backup grade läuft.
Oceanwaves scheint aber das gleiche Problem zu haben, wenn ich seine Posts richtig deute:
https://www.synology-forum.de/showt...Backup/page206&p=788199&viewfull=1#post788199

 

[ong10]

Hallo Tommes,

Wir verstehen nicht ganz was du mit --iconv=utf8,utf8 bezwecken willst. Es ergibt für uns keinen Sinn die selbe Codepage als Quelle und Ziel anzugeben. Oder soll das vielleicht Codepages ala de_DE.utf8 und en_GB.utf8 egalisieren?

ja, sieht komisch aus - löst aber das Umlautproblem bei mir. Ich erkläre es mir so (bin aber wie gesagt kein shell-Mensch), dass ich damit rsync zwinge die gelesenen Daten als UTF8 zu interpretieren und diese dann auch einfach so wegzuschreiben, ohne irgendwelche Konvertierungen.
Letztlich wissen wir ja auch gar nicht ob Quelle und Ziel gleich sind: Bei DS -> usbshare sind es 2 Datenträger, ggf. 2 unterschiedliche Dateisysteme und bei DS -> DS ist es noch unklarer.

Wie gesagt: Bei mir sind Umlaute in Ordner- und Dateinamen mit dieser Einstellung korrekt auf der Sicherung angelegt worden.

Olaf

 

[PsychoHH]

Man findet auch nirgends korrekte antworten. Es heißt, dass halt lokal und remote angegebenen werden muss und dann on the fly umgewandelt wird. Hab auch gelesen, dass es erst ab rsync 3.0.0 gehen soll. Mit dem mac utf8 ist dies z.B. auch der Fall.

Die Frage ist ob es ohne den iconv Parameter bei dir Probleme gibt?

Eventuell muss der Parameter sonst von jeder Person selbst gesetzt werden, da es zu unterschiedliche Codepages gibt.

Selbst ein auslesen und setzen per variable haben wir überlegt. Wer weiß aber ob es nicht auch dort zu Problemen kommt.

 

[ong10]

Hallo,

ich habe die neue 1.3.3 von Euch getestet - damit gab es Probleme bei Umlauten. Dann habe ich meine Variante wieder eingebaut was die Probleme löste.
In Eurer vorherigen Version (ohne iconv) hatte ich auch Umlautprobleme. Wenn ich mich recht entsinne, traten die mindestens dann auf, wenn ich auf usbshare gesichert habe (weiß nicht mehr was DS->DS war).

Dass ein Nutzer die Einstellungen evtl. selbst setzen muss hatte ich damals schon (evtl. in PN an Dich) angedeutet, da MAC hier "besonders" zu sein scheint (ich arbeite auf Windows).

Olaf

 

[Tommes]

Also ich verstehe das eher so, das wenn eine „local Codepage“ dem Wert von iconv entspricht, dann wandelt er diese Richtung „remote“ nach z.B. utf8 um. Daher ist für mich --iconv=utf8,utf8 nicht logisch. Sicherlich kann ich mich irren, aber man findet nirgendwo Hinweise im Netz die deine Theorie bestätigen, Es ist eigentlich immer von zwei unterschiedlichen Codepages für local und remote die Rede, also z.B. wie beim Mac --iconv=utf8-mac,utf8

@Anguel
Ist gebongt. Man hat während des Updates die Wahl ob man seine Benutzereinstellungen wieder haben will oder nicht, wobei dann zwischenzeitliche Änderungen natürlich wieder verloren gehen, Will man die Benutzereinstellungen nicht wiederherstellen, wandern sie vorsichtshalber nach /tmp/UltimateBackupFix

Tommes

 

[uwe-beach]

@uwe
Wir haben das jetzt so gelöst, das die verloren gegangenen /usersettings - also eure persönlichen Einstellungen - beim Update auf die nächste Version unter /tmp/UltimateBackupFix/usersettings verschoben werden. Dann kann jeder selbst entscheiden, was er davon zurück haben möchte. Leider ist dieses dann mit einem Besuch auf der Konsole verbunden... aber besser als nichts.

Kein Problem, habe das Verzeichnis usersettings gesichert und schaue beim nächsten Update danach.

Bezüglich der rsync-Spezifischen Einstellungen... bei mir funktioniert das. Grade eben getestet.

Tommes

Habe das rsync-Skript nach /tmp/kopiert und 'Auftrag bearbeiten' ausgeführt, dabei immer nur 'Weiter' gedrückt.
Im dabei erstellten rsync-Skript fehlen einige Sourcen und eine exclude-Anweisung.

diff rsync_uwe-lokal.sh /tmp
8c8,13
< sources="/volume2/Backup"
---
> sources="/volume1/Fileserver/kunden
> /volume1/Fileserver/VDR
> /volume1/Fileserver/video
> /volume1/Fileserver/home
> /volume1/Fileserver/bilder
> /volume2/Backup"
275c280
< exclude="--delete-excluded --exclude=@eaDir/*** --exclude=@Logfiles/*** --exclude=#recycle/*** --exclude=#snapshot/*** --exclude=.DS_Store/***"
---
> exclude="--delete-excluded --exclude=snapback/ --exclude=@eaDir/*** --exclude=@Logfiles/*** --exclude=#recycle/*** --exclude=#snapshot/*** --exclude=.DS_Store/***"
1779c1784
< fi
\ No newline at end of file
---
> fi

 

[Anguel]

aber man findet nirgendwo Hinweise im Netz die deine Theorie bestätigen

Habe auf die Schnelle das hier gefunden:
http://www.excito.org/forum/viewtopic.php?t=2381#p11341

@Anguel
Ist gebongt. Man hat während des Updates die Wahl ob man seine Benutzereinstellungen wieder haben will oder nicht

Danke! War so eine Idee um auch jedem gerecht zu werden ;-)

 

[Tommes]

@Anguel
Hm... klingt interessant. Dann bitte ich dich mal, auf die Manpage von rsync zu gehen ( https://linux.die.net/man/1/rsync ) und dir den Abschnitt --iconv=CONVERT_SPEC (im unteren Drittel der Seite) durchzulesen. Vielleicht habe ich da ja auch was falsch oder nicht richtig interpretiert... da mein Englisch nicht wirklich sehr ausgeprägt ist. Evtl. könnte somit --iconv=utf8 die Lösung unserer Probleme sein.

@uwe
Die Variable exclude überlebt ein Update nicht. Deshalb auch der Hinweis im Script...

# ------------------------------------------------------------------------
# Ab hier bitte nichts mehr ändern, wenn man nicht weiß was man tut !!!  |
# ------------------------------------------------------------------------

Variablen, die oberhalb dieses Abschnittes liegen, können dagegen nach Belieben angepasst werden (bis auf die Textvariablen fürs Logfil, soweit ich mich entsinnen kann) und überleben ein Update.Was aber mit deiner Variable sources geschehen ist, kann ich dir nicht beantworten.

 

[mzenker]

Bin zwar kein Lunux-Kenner, aber Ist deine externe Platte NTFS formatiert? Ich glaube dann werden die Berechtigungen eh nicht übertragen.

Du hast völlig Recht! Das hatte ich ganz vergessen und entschuldige mich für die Verwirrung! Nun werde ich wahrscheinlich die Platte umformatieren und nochmal ein Komplettbackup fahren. Dabei erwarte ich dank der Unterstützung und den Hinweisen von euch allen keine Probleme mehr, die ich nicht selbst lösen kann.
Vielen Dank, dass ihr so unermüdlich daran arbeitet, UB immer weiter zu verbessern!

Grüße,
Matthias

 

[ong10]

UB Extended

Hallo,

wie angekündigt noch eine kleine Erweiterung meiner vorherigen (s. weiter oben).
Mit hat in der Ausgabe bzw. der Mail eine kleine Übersicht gefehlt, an der man direkt sehen kann wie die Sicherung ausgegangen ist. das ist nun erledigt und hier ein Beispieloutput.

Ausgeführtes RSync-Script: rsync_test.sh
Script Version (UBV): 1.3.3.1014
Beginne: Ultimate Backup - 09.09.2018	17:08:06
Ein extra rsync Log wird im Logverzeichnis erstellt.
----------------------------------------------------------------------
 
Zusammenfassung:
/volume1/offen - Kein Fehler.
/volume1/xxx/A/Users/tttttt/Documents/ - Kein Fehler.
----------------------------------------------------------------------
 
 
**********************************************************************
Beginne: Basissicherung - 09.09.2018	17:08:06
**********************************************************************

Der gleiche Output, falls die Log-Datei/Mail zu groß ist.

Die Logdatei ist zu groß und wird hier nicht komplett angezeigt.
Ihre Mail enthält nur die ersten 10000 von 136768 (7%) Zeichen des Logs.
Das komplette Logfile findet sich hier: /volumeUSB1/usbshare/@Logfiles/2018-09-09_17h11m25s_backup_rsync_test.sh.log
 
Ausgeführtes RSync-Script: rsync_test.sh
Script Version (UBV): 1.3.3.1014
Beginne: Ultimate Backup - 09.09.2018	17:11:25
Ein extra rsync Log wird im Logverzeichnis erstellt.
----------------------------------------------------------------------
 
Zusammenfassung:
/volume1/yyyyy- Kein Fehler.
/volume1/xxx/A/Users/tttttt/Documents/ - Kein Fehler.
----------------------------------------------------------------------
 
 
**********************************************************************
Beginne: Basissicherung - 09.09.2018	17:11:25
**********************************************************************

Hier gibt's den Download (einbau in Euer Script genau so, wie zuvor von mir beschrieben): https://dl.olaf-noehring.de/?t=216a4d6f15c7f9021cda3bd0facdf146
PS: Download der vorherigen Version habe ich entfernt.

Olaf

 

[Anguel]

Mit hat in der Ausgabe bzw. der Mail eine kleine Übersicht gefehlt, an der man direkt sehen kann wie die Sicherung ausgegangen ist. das ist nun erledigt und hier ein Beispieloutput.

Sieht gut aus, hab jetzt nicht ins Detail geschaut, da ich meine DS nicht zur Hand habe, aber was ich gern noch sehen würde:
- Gesamtdauer des Backups in Tage, Stunden, Minuten
- Total gesicherte Größe

Der gleiche Output, falls die Log-Datei/Mail zu groß ist.

Aufgrund welcher Fehler kam es eigentlich bei dir zu diesen übergroßen Mails?