HBS3-update V24.1.0523 erschienen

Moin agent0815

siehe hier: RE: Hybrid Backup Sync HBS3 Version V24.0.0304 erschienen

Bei mir läuft die Version auf beiden TS-x473A, allerdings nur mit Sync-Jobs.

Bisher keine Probleme, das Update wurde aber auch erst gestern installiert .

Also abwarten und .

Gruss

Zitat von FSC830

allerdings nur mit Sync-Jobs.

agent0815 ich mach auch nur Sync. Die sind heute morgen normal durchgelaufen (USB SSD), auch ein versuchsweise anderer externer Sync (USB mit HDD) hat das erwartete Ergebnis geliefert

Hab mir dann auch ein gegönnt, aber erst nach 12:00 Uhr gg

Habs installiert und verwende auch nur Sync-Jobs aber da funzt alles.

Ich mache damit incrementelle Backups (also mit Smart Versioning) auf externe USB3.0 Platte.
Nur seit dem Update vom HBS3 auf 24.1.0523 werden die Backup Jobs nicht mehr fertig, wenn die allein in der Nacht anlaufen. Es rattern dann ziemlich Laut meine Festplatten in der QNAP (auch noch Stunden später), bis ich die Jobs stoppe und nochmal manuell anstarte. Dann laufen die auch wie gewohnt in ein paar Minuten durch (hab nicht so viel Änderungsvolumen). Danach dauert es noch ein paar Minuten und die Festplatten beruhigen sich dann wieder.
Hat das Problem noch jemand ?

Mit der einfachen Versionierung habe ich das Problem nicht.

Ich mache Backups auf externe Disks nur sporadisch, habe das aber gerade mal zum Anlass genommen es mal wieder anzustoßen...

Nicht über Zeitplan, aber automatisch beim Verbinden der Disk. Der Job läuft noch (einfache Versionierung), mir macht der Blick in den Prozess aber etwas Sorge, da offensichtlich Daten übertragen werden, die schon längst vorhanden sind und garantiert nicht verändert wurden... Ich bin gespannt...

Was mir dabei auffällt:

Zitat von Ryker

wenn die allein in der Nacht anlaufen.

... bedeutet dass die Disk ständig angeschlossen ist?! Keine gute Idee! Oder sind das mehrere Disks im Wechsel, sodass eine Disk immer getrennt ist?

Das seltsame ist, das Backup meiner Dateiablage klappt wunderbar.
Das Backup meiner Filme-Ablage hängt bei bei

"Calculating and Storung MD5 value 100%"

auch wenn ich das manuell starte.
Dabei sind beide Backup-Jobs identisch konfiguriert - nur die Source und Destination-Folders und der Name ist anders.
Wenn ich den FilmeBackup nun abbreche, dann klappt der nächste Backup wieder ohne Probleme, aber der übernächste hangt dann wieder bei der gleichen Meldung.
Ich denke das mit MD5 ist das Problem. Eigentlich brauche ich das bei meinen Filmen auch den "Check Data Integrity" auch gar nicht auf dem Backup meiner Filmablage und nur dafür generiert er ja die md5-status-files.
Kann man das iwie abschalten ?

Zitat von tiermutter

etwas Sorge, da offensichtlich Daten übertragen werden, die schon längst vorhanden sind

Kommando zurück, ich habe bei dem Job ja "Check File Contents" aktiv, was sich in HBS dann so darstellt als würde die Datei auf die externe Disk übertragen werden.

Läuft bis dahin also wie es soll

Zitat von Ryker

Kann man das iwie abschalten ?

Wenn die Inhaltsprüfung mal aktiviert war, dann nicht... allenfalls über den Support...

Hat nicht Anthracite im oben genannten Thema #44 ähnliches berichtet? Sollte man vllt. auf einem Thread diskutieren.

Zitat von Ryker

Nur seit dem Update vom HBS3 auf 24.1.0523 werden die Backup Jobs nicht mehr fertig, wenn die allein in der Nacht anlaufen.

Ich hatte den Fehler mit der Version 24.1.0515, allerdings unabhängig davon, ob der Job automatisch oder manuell gestartet wurde. In der 24.1.0523 wurde an der Stelle vermutlich nichts geändert, da das nur der Patch auf einen fatalen Fehler ist. Nachdem ich auf die 20.0.0304 zurückgegangen bin, war das Problem behoben.

Welche qts-Version hast du im Einsatz? Der Herr vom Support meinte, ich solle die 5.1.7.2770 nehmen, weil es da Änderungen bzgl. HBS drin gebe. Ob die was mit meinem Problem zu tun haben, ist aber nicht sicher.

Eine genauere Analyse durch den Support ist daran gescheitert, dass ich nicht bereit war, die dafür nötigen Logdateien zur Verfügung zu stellen. Da standen mir zu viele vertrauliche Daten drin, Passwörter im Klartext zum Beispiel .

Zitat von Anthracite

, Passwörter im Klartext zum Beispiel .

Echt? Wo?

Ich weigere mich bei "Kleinigkeiten" ja auch schon, allein weil Dateinamen und Usernamen ersichtlich sein können, aber Kennwörter?

Nach den Problemen mit QVPN und der QTS Beta bin ich nun auf 5.1.7 "zurück" (vorher 5.1.2. QVPN startet jetzt zwar sauber, dafür schlagen die Jobs aus scheinbar anderen Gründen fehl, das kann ich mir aber frühestens übermorgen genauer anschauen... Nervt.

Anthracite Sprichst Du von den Protokollen im Hilfecenter, oder meinst Du andere? Das im Hilfecenter waren jedenfalls die, die QNAP immer von mir wollte.

Habe die gerade mal runtergeladen und nach meinem Passwort (Klartext) gesucht, das aber nicht gefunden. Würde mich jedenfalls auch unruhig machen...

Username und IP des Verbindungspartners sind da allerdings schon dabei

Zitat von Anthracite

Der Herr vom Support meinte, ich solle die 5.1.7.2770 nehmen, weil es da Änderungen bzgl. HBS drin gebe.

Bei meinem TS-251D läuft die neue HBS3 Version ohne Probleme mit QTS 4.5.4.2627.

Ich sehe da kein anderers Verhalten wie unter QTS 5.1.7/5.2

Zitat von tiermutter

Echt? Wo?

Ich kam auf die Idee, die Zip-Dateien für den Export zu entpacken und ein grep -R auf den Anfang meines Passwortes zu machen.

Fündig geworden bin ich an zwei Stellen:

in HBS:

cd /share/CE_CACHEDEV1_DATA/.qpkg/
grep -r Anfang-des-Passwortes HybridBackup
# oder
egrep -r '"plain_pwd": "[a-zA-Z0-9]+' HybridBackup

Fündig geworden bin ich in den beiden Dateien

HybridBackup/CloudConnector3/data/server/server.log.2
HybridBackup/CloudConnector3/data/server/server-error.log

Bei dem Passwort, das im Klartext auftaucht, handelt es sich möglicherweise um die Passphrase des SSH-Schlüssels; zumindest scheint das im Zusammenhang mit der Synchronisation über Rsync zu stehen.

Diese beiden Logdateien werden in das Zip des Logs in HBS mit eingeschlossen.

in der Virtualisierungsstation:

cd Verzeichnis/mit/den/virtuellen/Maschinen
grep '<qvs:graphics ' */.*.meta/[0-9]*.xml

(wenn's eine Fehlermeldung gibt wg. nicht gefundener Dateien, dann ward ihr im falschen Verzeichnis.)

Da handelt es sich wohl um das VNC-Passwort für den Konsolenbetrieb. (Und wenn man wie ich dafür das Login-Passwort nimmt, um sich nicht zu viele Passwörter merken zu müssen ...)

Diese Dateien landen im allgemeinen Zip, das in der Helpdesk-App erstellt wird.

Ich war doch erstmal geschockt über diese Entdeckungen. Das darf gar nicht sein. Da scheint an einigen Stellen das Sicherheitsbewusstsein der Programmierer mangelhaft zu sein.

So, ich hab jetzt meine Backup-Jobs gelöscht.
Dann auch auf der Backup-USB-Platte die Verzeichnisse nach _OLD umbenannt und die Backup-Jobs wieder eingerichtet.
Jetzt sieht das alles viel besser aus nach meinen ersten Tests. Also ich hab jetzt schon bei 2 Jobs wieder den initialen Full-Backup durch. Weitere incrementels liefen diesmal ohne Probleme.

Auch gibt es nun bei den neu angelegten Backup-Jobs einen zusätzlichen Punkt "Datenintegritätsprüfung" unter "Zeitplan". Das war vorher nicht da.
Da schein wohl doch durch die vielen Updates vom HBS3 in 5 Jahren irgendwas an den Backup-Jobs kaputt gegangen zu sein.

Mal schauen, wie es morgen aussieht, nach dem nächtlichen Backup.

Zitat von Anthracite

Passwörter im Klartext zum Beispiel

Bei mir bin ich in einer Log-Version in uLinux.cfg fündig geworden, offensichtlich als ich SNMP v1/v2 aktiv hatte. War mir nicht bewusst, dass dies dadurch bewirkt wird. Hab allerdings grepwin verwendet am PC für die Suche.

EDIT:

Interessanterweise bleiben die Einträge in uLinux.cfg selbst dann, wenn man SNMP deaktiviert. Um sie zu löschen muss man also irgendwelche Dummy-Angaben eintragen. Oder halt das Wagnis eingehen und mittel Konsole in Editor löschen.