Ultimate Backup Ultimate Backup

[PsychoHH]

Super das es so schon mal geht. Dann fließt das mit ein.

Hab dir mal ne pn geschrieben.

 

[SynKlaus]

@Anguel, @PsychoHH, @Tommes: Danke noch mal für Eure Hinweise bzgl. der Entschlüsselung. Werde ich die Tag mal probieren und hier auch noch mal kurz Rückmeldung geben.

Grüße.

 

[mzenker]

So, das "echte" Backup ist durchgelaufen.
Eine Frage hätte ich noch: Die gesicherten Dateien gehören alle dem admin, die Benutzerrechte wurden offenbar nicht übernommen. Hätte ich das irgendwo extra einstellen können?

Grüße,
Matthias

 

[Tommes]

Der rsync Optionsschalter-a behält Rechte und Gruppenrechte bei, nur die Besitzrechte können sich ändern, wenn rsync nicht als root ausgeführt wird. Daher wäre es interessant zu erfahren, welches Backup du unter welchem (SSH-)Benutzer ausgeführt hast.

 

[Tommes]

Ultimate Backup 1.3.3


Release-Notes vom 04.09.2018
(...sobald von den Machern von CPHub freigegeben!)

• Rsync Optionsschalter --iconv=iso-8859-1,utf8 wurde als Standardwert implementiert. Dieser Optionsschalter sorgt für eine Konvertierung von Ordner- und Dateinamen zwischen Systemen unterschiedlicher Codepages (Umlaute).
• Timeout-Probleme mit Autostart bzw. udev wurden behoben, die ein Auswerfen von USB/SATA-Datenträger verinderte.
• Auftretende rsync-Fehlermeldungen der Standardfehlerausgabe (stderr) werden ab sofort ins Sicherungsrotokoll geschrieben.
• Speicherort der Schlüsseldatei (des Key-Files) der Zielordnerverschlüsselung kann ab sofort sowohl über die GUI als auch direkt im Backupscript frei gewählt werden. Somit kann das Key-File nun auch getrennt von einem zielordnerverschlüsselten USB/SATA-Datenträgers aufbewahrt werden.
• (De-)Installationsscripte überarbeitet. Während der Deinstallation von Ultimate Backup werden ab sofort Zeitpläne, Autostarteinstellungen, Gerätekonfigurationen sowie eingestellte Benutzerrechte gelöscht.
• Die Ultimate Backup Hilfe wurde aus der DSM-Hilfe entkoppelt und in ein eigenständiges System überführt.

Hinweis:
Da wir am eigentlichen Backup-Script ebenfalls Änderungen vorgenommen haben, müssen eure Backup-Aufträge entsprechend aktualisiert werden.

(Immer noch ein...) Wichtiger Hinweis:
Bedingt durch einen Fehler im DSM (betrifft wohl alle Versionen von DSM 6.1 und DSM 6.2) wird Ultimate Backup direkt nach dem Upgrade den ersten Start verweigern und hängen bleiben. Wir können dieses Verhalten leider nicht beeinflussen geschweige denn beheben. Die einzige Möglichkeit ist, das ihr den DSM refresht (z.B. F5 - Taste) oder einen rechtsklick auf das Ultimate Backup Symbol ausführt um es in einem neuen Fenster zu öffnen. Wie gesagt, dieses Verhalten tritt nur beim ersten Start und auch nur nach einem Upgrade auf, nicht bei einer Neuinstallation.

In eigener Sache:
Ein ganz dickes Dankeschön an all die fleißigen Helfer, die uns tatkräftig Bugs gemeldet und oftmals auch gleich eine Lösung beigepackt haben. Ohne euch würde es dieses Uptate wohl nicht geben.


Wir wünschen euch wie immer viel Spaß mit Ultimate Backup.

Tommes & PsychoHH

 

[mandragora]

Guten Morgen Leute,

Hab leider aktuell ein Problem mit meiner Auftragsliste nach dem Upgrade.
Hab nichts dergleichen gefunden oder ich hab ev. falsch danach gesucht.
Nach dem Upgrade läuft Ultimate Backup und ich versuche gerade meine Auftragsliste zu aktualisieren.
Bei der Scriptsuche gebe ich den Ordner an wo ich meine Scripte gespeichert habe.
Scripte sind vorhanden in dem Ordner.
Wenn ich die Suche dann starte bekomm ich nach ein paar Sekunden die Meldung das der Ordner nicht durchsucht werden kann.
Kann mir jemand ev. kurz sagen was hier nicht stimmt.

vielen herzlichen Dank schon mal
lg
mandragora

 

[PsychoHH]

Bitte einmal die debug Ausgabe mir per pn schicken

 

[Anguel]

Ein ganz dickes Dankeschön an all die fleißigen Helfer, die uns tatkräftig Bugs gemeldet und oftmals auch gleich eine Lösung beigepackt haben. Ohne euch würde es dieses Uptate wohl nicht geben.

Euch auch vielen Dank für die Fixes! Ich habe das neue Skript erstellt und mit meinem modifizierten verglichen. Alles passt soweit
Das einzige, was evtl. noch fehlt ist die versprochene Option, das Recycle bei großen Dateien komplett abzuschalten, was ich bei mir momentan durch
recycle="--delete"
statt
recycle="--delete --backup --backup-dir=@Recycle/${date}_${scriptname_recycle}"
löse.

Was auch mir wie mandragora als Problem aufgefallen ist:
Obwohl das Backup jetzt läuft bleibt die Auftragsliste leer. Vorhin war der neu erstellte Auftrag noch da.

 

[Tommes]

Gut, das mit dem Recycle hatten wir wohl nicht mehr auf dem Sender (ich jedenfalls nicht). Warum aber die Auftragsliste Probleme macht, ist mir grad unverständlich. Bei mir hat das gestern alles funktioniert. Wir prüfen das auf jeden Fall und melden uns.

 

[Tommes]

Hab leider aktuell ein Problem mit meiner Auftragsliste nach dem Upgrade....Wenn ich die Suche dann starte bekomm ich nach ein paar Sekunden die Meldung das der Ordner nicht durchsucht werden kann.

Obwohl das Backup jetzt läuft bleibt die Auftragsliste leer. Vorhin war der neu erstellte Auftrag noch da.

Ich habe ein bestehenden Backupauftrag in Richtung meiner DS216+ sowie einen Backupauftrag Richtung lokal angeschlossenen USB-Stick und eben einen weiteren lokalen Backupauftrag auf die interne Festplatte meiner DS218+ erstellt. Alle drei Aufträge werden mir in der Auftragsübersicht angezeigt. Habe dann mal die Datei /volume1/@appstore/UltimateBackup/usersettings/foundbackups.txt gelöscht. In dieser Datei werden alle Pfade zu gefundenen Backupaufträgen gespeichert. Durch das löschen werden somit keine Backupaufträge mehr in der Übersicht angezeigt. "Auftragsliste aktualisieren" - Pfad ausgewählt (intern und USB) - und schwupps, alles wieder da.

Ich kann das Verhalten bei mir nicht reproduzieren, was die Fehlersuche natürlich sehr erschwert. Warten wir mal ab, was PsychoHH noch so rausfindet. Vielleicht habt ihr zwischenzeitlich ja auch neue Erkenntnisse?

Tommes

 

[Oceanwaves]

Habe dann mal die Datei /volume1/@appstore/UltimateBackup/usersettings/foundbackups.txt gelöscht. In dieser Datei werden alle Pfade zu gefundenen Backupaufträgen gespeichert. Durch das löschen werden somit keine Backupaufträge mehr in der Übersicht angezeigt. "Auftragsliste aktualisieren" - Pfad ausgewählt (intern und USB) - und schwupps, alles wieder da.

Ich kann das Verhalten bei mir nicht reproduzieren, was die Fehlersuche natürlich sehr erschwert. Warten wir mal ab, was PsychoHH noch so rausfindet. Vielleicht habt ihr zwischenzeitlich ja auch neue Erkenntnisse?

Tommes

Ich habe hier das gleiche Problem. Nach dem Update von 1.32 auf 1.33 gestern wurde mein Auftrag nicht mehr angezeigt. Manuelles Suchen brachte ihn wieder zurück. Heute läuft zwar der Auftrag, aber er wird nicht mehr angezeigt und auch nicht mehr gefunden. Löschen der foundbackups.txt hilft auch nicht. Nach der Suche steht das Skript zwar wieder drin, wird aber trotzdem nicht angezeigt.

Zudem dauert das Backup heute deutlich länger. Normalerweise braucht es 30-45 Minuten, heute ist es nach 2 Stunden noch nicht fertig und mir geht langsam der Platz auf dem Ziel (ds214play) aus.

Habe festgestellt, dass z.T. große Datenmengen gesichert werden. Z.B. das eigentlich sehr statische Verzeichnis /volume1/data:

Backup-Log von gestern:
Number of files: 408069
Number of files transferred: 0
Total file size: 235.66G bytes
Total transferred file size: 0 bytes


Backup-Log von heute:
Number of files: 408069
Number of files transferred: 8897
Total file size: 235.66G bytes
Total transferred file size: 63.03G bytes
Literal data: 63.03G bytes
Matched data: 0 bytes
File list size: 6.64M
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 63.05G
Total bytes received: 203.98K

sent 63.05G bytes received 203.98K bytes 37.97M bytes/sec

Obwohl sich an Größe und Dateianzahl (und m.W. auch am Inhalt) nichts geändert hat, wurden 63 GB neu übertragen.

Meine Vermutung:

Rsync Optionsschalter --iconv=iso-8859-1,utf8 wurde als Standardwert implementiert. Dieser Optionsschalter sorgt für eine Konvertierung von Ordner- und Dateinamen zwischen Systemen unterschiedlicher Codepages (Umlaute).

Werden deswegen evtl. alle Dateien/Verzeichnisse, die ein Sonderzeichen enthalten, neu übertragen?

Aktuell wird gerade mein video-Verzeichnis (1,5 TB) gesichert. Da dürfte dann wohl auch einiges an GB neu übertragen werden....

PS: dieses Forum nervt :-(. Antwort geschrieben, auf "Antworten" geklickt und... Nachricht ist futsch. Also alles noch mal neu schreiben... (aber vor "Antworten" Ctrl-A und Ctrl-C drücken...)

 

[Tommes]

Das mehr Dateien gesichert werden liegt mit ziemlicher Sicherheit an dem Optionsschalter --iconv=iso-8859-1,utf8. Das wird aber dann eine einmalige Sache sein.

An der Sache mit der Auftragsliste sind wir dran. Wir sammeln grade erste Indizien haben aber noch micht die Wurzel des Übels gefunden. Wir tun aber unsere Möglichstes das Problem schnellstmöglich zu beheben.

Und zum Forum. Du kannst neben deinen Logindaten den Haken bei „save“ setzten, damit du angemeldet bleibst. Aber falls es das beruhigt, mir passiert das auch regenmäßig.

 

[Anguel]

Soweit ich das verstehe, wird die foundbackups.txt nur benutzt, wenn sich das Skript nicht auf einer ext. Platte befindet, oder?

if [[ "$scriptpath" != /volumeUSB[[:digit:]]/usbshare* ]] && [[ "$scriptpath" != /volumeSATA/satashare ]]; then
	scriptpath=$(echo "$scriptpath" | sed 's#/volumeUSB[[:digit:]]/usbshare.*/#/volume????/*share*/#;s#/volumeSATA/satashare/#/volume????/*share*/#')
	echo "$scriptpath/$scriptname" >> "$usersettings/foundbackups.txt"
fi

Um das einzugrenzen wäre evtl. interessant, ob die Leute bei denen die Aufträge verschwinden, die Verschlüsselung nutzen?

EDIT: Bei mir zumindest ist die Datei foundbackups.txt leer. Achso, mein neu erstelltes Skript hieß übrigens autorun und nicht rsync_*.sh
EDIT2: Wenn ich die autorun nach rsync_test.sh kopiere findet er sie und schreibt sie in die foundbackups.txt. Mein Backup läuft jetzt noch im Hintergrund und ich kann momentan nicht weiter testen.
EDIT3: Habe jetzt die Diskstation doch neu gestartet und plötzlich war auch die autorun wieder zu sehen, also können die obigen Anmerkungen denke ich ignoriert werden. Als ich die USB-Platte aber ausgeworfen und per Autostart eingesöpselt habe, ist die Liste wieder leer und das autorun wird nicht mehr gefunden. Das autorun steht in backupjobs.txt drin, in foundbackups.txt nicht.

 

[Oceanwaves]

Keine Verschlüsselung hier. Mein Backup-Skript liegt lokal auf der zu sichernden DS und steht in backupjobs.txt und foundbackups.txt. In backupjobs.txt steht zusätzlich noch der Eintrag "/volume????/*share*/autorun".

Nach 4 Stunden war das Backup durch, ich lösche gerade diverse Versionierungen, um wieder etwas Platz frei zu bekommen. Insgesamt wurde durch den -- iconv Parameter knapp 500 GB mehr als sonst gesichert.

Nachdem ich UB gerade wieder gestartet habe, wird mir mein Auftrag auch sauber angezeigt...

Leider mit fehlerhaftem Ergebnis (RSync-Code 23). Ursache dürfte eine alte (2014) XML-Datei sein, die "okular" (PDF-Viewer unter Linux) mal angelegt hatte. Die enthielt viele Sonderzeichen, was UB mit einem

rsync: recv_generator: failed to stat ".../docdata/8037421.???? ????? ???? ????????? ????-????? ???? ?? ???¤.pdf.xml": File name too long (36)

und anschließendem

rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1355) [sender=3.0.9]

quittierte. Dürfte auch an --iconv liegen, die Datei wurde bislang immer ohne Murren gesichert. Egal, hab den gesamten Inhalt des Verzeichnisses weggeworfen, da lagen Dateien von 2012-2017 drin. Ich denke nicht, dass okular die noch braucht ;-).

 

[Anguel]

Nachdem ich UB gerade wieder gestartet habe, wird mir mein Auftrag auch sauber angezeigt...

Genau, mein Fazit ist momentan: Während der Job läuft sieht und findet UB den Job nicht.

 

[SynKlaus]

@Anguel, @PsychoHH, @Tommes: Danke noch mal für Eure Hinweise bzgl. der Entschlüsselung. Werde ich die Tag mal probieren und hier auch noch mal kurz Rückmeldung geben.

Grüße.

So, als erstes habe ich gerade die Entschlüsselung per SSH direkt an der DS versucht:

Wenn ich hier dann die Zeile

yes "" | /bin/mount -t ecryptfs[/I] ...

ausführe, sagt er auch Mounted eCryptfs
Schaue ich dann in den entschlüsselten Ordner rein, ist dieser leer. Das selbe passiert, wenn ich ein falsches Passwort angebe - Daher vermute ich, dass es an meinem Passwort liegt - Dies beinhaltet nämlich ein Ausrufezeichen und so kann ich den Parameter

key=passphrase:passphrase_passwd="mein!passwort"

nicht so, wie im Beispiel angeben, weil er durch das Ausrufezeichen die Zeichenkette unterbricht:

Ich habe dann folgende beiden Varianten probiert:

key=passphrase:passphrase_passwd="mein\!passwort"

key=passphrase:passphrase_passwd='mein!passwort'

Beide beiden Befehlen sagt er wieder Mounted eCryptfs, aber immer ist der Ordner leer.

Hat jemand einen Tipp?

Grüße.

 

[Oceanwaves]

Hat jemand einen Tipp?

Kenn mich zwar mit Verschlüsselung nicht aus, aber mal

key=passphrase:passphrase_passwd=\'mein\!passwort\'

versucht?

$ key=passphrase:passphrase_passwd=\'mein\!passwort\'
$ echo $key
passphrase:passphrase_passwd='mein!passwort'

Oder das "!" durch ein anderes Sonderzeichen ersetzen, z.b. "-". Das "!" hat für die Shell mitunter eine Sonderfunktion...

 

[SynKlaus]

Ich kann das Ausrufezeichen aber nicht einfach durch ein anderes Sonderzeichen ersetzen, da die Backups nun mal mit dem Ausrufezeichen verschlüsselt wurden - Ansonsten müsste ich diese alle noch mal neu erstellen. Aber ich habe das Problem nun gefunden. Meine Herangehensweise war schon richtig, einfach das Passwort in Hochkommas statt in Anführungszeichen zu setzen, damit das Ausrufezeichen nicht von der Shell interpretiert wird:

key=passphrase:passphrase_passwd='mein!passwort'

Und wenn man dann noch das korrekte Passwort verwendet, klappt es auch - Seltsamerweise war nämlich das damals von mir notierte Passwort ein klein wenig anders, als das Passwort, welches ich gerade nochmal aus der Key-Datei extrahiert habe. Mein Fehler.

Grüße.

 

[PsychoHH]

Ganz genau so geht das.

 

[Oceanwaves]

Aber ich habe das Problem nun gefunden. Meine Herangehensweise war schon richtig, einfach das Passwort in Hochkommas statt in Anführungszeichen zu setzen, damit das Ausrufezeichen nicht von der Shell interpretiert wird

Das wäre auch mein 1. Vorschlag gewesen, aber den hattest du ja schon selbst (ohne Verbesserung) ausprobiert ;-).