HBS 3 Hybrid Backup Sync 16.0.0415 released

    Ich mache mal mit meinem heutigen "Release-Verkünder-Job" weiter... da es seit einigen Monaten ja vermehrt Probleme mit HBS3 gibt, hier ein Release das Hoffnung gibt.

    Ich hoffe inständig, dass damit die Masse der Probleme, die zuletzt in mehreren Threads behandelt wurden, beseitigt sind.

    Anbei die Release Notes.


    RTRR ist nach dem Update deaktiviert und der Port ist angeblich von einem anderem Dienst blockiert.


    Läuft scheinbar wenig rund im Moment.


    Wenn es dann aber läuft, zeigt es auf dem Ziel die Jobs wieder an.

    ... war klar, dass ich wieder ohne Probleme aus der Nummer rauskomme.


    Was mir aufgefallen ist, ist dass ein Job, der nichts zu übertragen hat, fast doppelt so schnell beendet wird als die Wochen zuvor. Bin gespannt ob es auch schneller ist wenn Daten übertragen werden müssen.


    Edit:

    Hm, bei der automatischen Ausführung in der Nacht hatte ich dann auch das Problem, dass der RTRR Server deaktiviert war. Allerdings schlugen nur Jobs mit QuDedup fehl, ein Job ohne Dedup ist zur selben Zeit anstandslos durchgelaufen, aber ebenfalls mittels RTRR :/

    Habe nun den Port des RTRR Servers geändert, da ich den Server mit dem Standardport zunächst auch nicht aktivieren konnte.

    Einmal editiert, zuletzt von tiermutter ()

    Der von mir schon erfolglos an den Support gemeldete Fehler, dass Backup-Jobs auf USB-Festplatte bei 5% hängenbleiben (unmittelbar bevor normalerweise die Werte Total files und Total size angezeigt werden), aber nach mehrfachen manuellen Startversuchen irgendwann erfolgreich laufen, ist immer noch da.

    Auch die fehlerhafte Meldung

    Code
    "Updated settings will be used the next time this job is run"

    wenn man die Einstellungen eines gerade laufenden Job ändert, erscheint weiterhin.

    Zitat von tgsbn

    Auch die fehlerhafte Meldung

    Code
    "Updated settings will be used the next time this job is run"

    Was ist daran fehlerhaft?


    Ich kann von der Version 16 auf jeden Fall nur abraten, zumindest für Zielsysteme mit RTRR Server.

    Wie Crazyhorse schon beschrieben hat, ist der RTRR Server nach jedem Neustart gestoppt und kann nicht ohne Portänderung wieder aktiviert werden.

    Bin wieder auf die vorherige Version zurück, auf dem Quellsystem läuft die aktuelle Version ansonsten ohne Probleme.

    Zitat von tiermutter

    Was ist daran fehlerhaft?

    Dass die geänderten Settings eben nicht erst beim nächsten Lauf des Jobs wirksam werden, zumindest nicht alle.

    Mein schon dutzende Male durchgespieltes Szenario:

    • Job mit gesetztem "Eject external volume after completion" bleibt hängen.
    • Wenn ich den Job jetzt stoppen würde, würde das externe Laufwerk ausgeworfen, was ich nicht will.
    • Ich editiere die Einstellungen und nehme das Häkchen bei "Eject external volume after completion" raus.
    • Ich klicke auf "Save". HBS3 meldet: "Updated settings will be used the next time this job is run."
    • Ich stoppe den Job.
    • Das externe Laufwerk wird nicht ausgeworfen.

    Das heißt: meine Änderung ist sehr wohl auf den bereits laufenden Job angewendet worden.

    Die Meldung war falsch.

    Zitat von tgsbn

    Das heißt: meine Änderung ist sehr wohl auf den bereits laufenden Job angewendet worden.

    Ich verstehe... Habe solch ein Szenario noch nicht gehabt. Einen Englisch-Deutsch Übersetzungsfehler kann man auf jeden Fall ausschließen :)

    Irgendetwas ist an der neuen Version doppelplusungut.

    Nachdem mein Backupjob zum zweiten Mal hängen geblieben war, fand ich per ssh mit ps einen laufenden Prozess

    Code
    /bin/rm -rf /share/Tosh1T/Nessy/Tosh1T/.VersionRecycle

    und zwei laufende Prozesse

    Code
    /bin/cp -alr /share/Tosh1T/Nessy/Tosh1T/latest/ /share/Tosh1T/Nessy/
Tosh1T/202104171419

    (mit unterschiedlicher letzter Pfadkomponente beim Zielordner.)

    top meldet ein Load Average von 4-51/4.46/4.48, aber CPU 69.1% idle.

    Als ich den älteren der cp-Prozesse mit kill abgeschossen habe, lief der hängende Backup-Job auf einmal weiter, zählte Total Files und Total Size hoch, und auch die Fortschritts-Prozentzahl begann zu steigen, allerdings extrem langsam.

    Der Job läuft jetzt seit vier Stunden, ist laut Admin-Oberfläche bei 74% mit 18h Remaining Time, 693 Processed Files und 16 GB Total Transferred Size.

    In dem Ordner .VersionRecycle, den der /bin/rm-Prozess löschen will, lagen vier Ordner mit dem Namensschema yyyymmddhhmm, und in den drei Stunden, ich dem ganzen jetzt zuschaue, ist noch keiner davon verschwunden.

    Selbst auf einer lahmen rotierenden USB-Festplatte sollte meiner Meinung nach weder das Löschen (rm -rf) noch das Verlinken (cp -alr) eines Ordnerbaums von 80.000 Dateien über vier Stunden dauern.


    Außerdem hat der /bin/rm-Prozess die PPID 1, d.h. er läuft losgelöst vom Backup-Job im Hintergrund.

    Ich frage ich mich, was passieren wird, wenn der Backup-Job durch ist und die Platte auswerfen will, das /bin/rm aber immer noch läuft.


    Update:

    Nun war das Backup plötzlich doch fertig - nach deutlich weniger als den vorhergesagten 18 Stunden. ;)

    Die Platte wurde ausgeworfen, obwohl der /bin/rm-Prozess noch lief.

    In dmesg findet sich die lapidare Meldung:

    Code
    [533946.967611] ufsd: "rm" (sdc1): is unmounted at 2021-04-17 18:00:35

    Da die Platte NTFS-formatiert ist, habe ich mir mal mit einem Windows-Rechner angeschaut, in welchem Zustand das NAS sie hinterlassen hat.

    Die Datenträgerüberprüfung meldet Fehler - das Auswerfen mitten im laufenden Löschvorgang war wohl doch keine so gute Idee von HBS3.

    Die Reparatur meldet Erfolg.

    Der Ordner .VersionRecycle ist noch da, aber immerhin einer der vier Unterordner ist weg, der rm-Prozess war also nicht ganz untätig.

    Da QTS bzw. HBS3 ihn ja los sein wollte, tue ich ihm den Gefallen und lösche ihn unter Windows, vielleicht hilft's ja.


    Update2:

    Das Löschen unter Windows ist ohne Probleme durchgelaufen.

    Hat eine halbe Stunde gedauert - offenbar ist Ordnerlöschen bei NTFS eine aufwendige Angelegenheit.

    Aber eine halbe Stunde für den Gesamtordner mit drei Unterordnern ist immer noch deutlich flotter als vier Stunden für einen Unterordner.

    2 Mal editiert, zuletzt von tgsbn ()

    Zitat von Crazyhorse

    RTRR ist nach dem Update deaktiviert und der Port ist angeblich von einem anderem Dienst blockiert.


    Zitat von tiermutter

    Ich kann von der Version 16 auf jeden Fall nur abraten, zumindest für Zielsysteme mit RTRR Server.


    Ich staune immer wieder aufs neue wie man es schafft eine funktionierende App durch ein Update konsequent kaputt zu patchen.

    Noch dazu eine App welche man zur Sichrung seiner Daten einsetzt.

    Habe ebenfalls die Version 16.0.0415 installiert. RTRR-Server auf remote Ziel-NAS meckert auch bei mir den Port an. Und auf dem Quell-NAS geht es nicht mehr, einen Job mit Versionierung anzulegen. Um es auch für mich auf den Punkt zu bringen: Es ist schlichtweg ein Desaster mit HBS!

    Zitat von Iowa

    Es ist schlichtweg ein Desaster mit HBS!

    So wie ich das sehe ist HBS das Desaster.
    Hab zum Glück noch nicht geupdatet und ältere Versionen archiviert.
    Für den Fall eines nötigen Downgrades.

    Hat für mich den Anschein, daß interne Tests vor dem Rollout keine so große Rolle spielen.

    Wie bei QTS halt auch.

    Zitat von rednag

    So wie ich das sehe ist HBS das Desaster.

    Was mich zur Frage nach Alternativen zurückbringt.

    Als ich die das letzte Mal in diesem Forum stellte, gab's leider nur Antworten auf der Linie:

    "Wozu Alternativen? HBS ist doch prima. Wenn es bei dir nicht läuft, machst du etwas falsch."

    Aber vielleicht hat ja jemand aus der Runde eine Idee?

    Zitat von tgsbn

    "Wozu Alternativen? HBS ist doch prima. Wenn es bei dir nicht läuft, machst du etwas falsch."

    Das war dann wahrscheinlich noch zu Zeiten, als HBS wirklich noch (relativ) problemlos lief.

    Das ist (bei mir) seit v14 aus Dezember 2020 vorbei :( Davor hatte ich eigentlich nichts zu bellen.


    Aber ja... Alternative... die nicht von QNAP kommt... gute Frage!

    Man könnte sich auch ein Script zurechtbasteln.

    Gibt halt dann keine GUI zum rumklicken.

    Schon... Das mag für "Kopieren und ersetzen" gehen, aber wenn es dann um Versionierung geht stelle ich mir das "etwas" komplizierter vor. Aber ich bin ja auch ein GUI-Kind das ohne Maus unglücklich ist :P

    Na ja, so ein script erstellt mal einmal. In die Crontab damit und fertig.

    Finde grad aber kein passendes Beispiel.

    Es ist aber auch kein Hexenwerk.

    Skriptschreiben wäre jetzt nicht das Problem, so etwas mache ich sowieso regelmäßig für die Brötchen.

    Ein rsync-Aufruf ist in der Tat kein Hexenwerk.

    Das hätte den Vorteil, dass ich genau weiß, was es tut, und vor allem, dass ich es selbst ändern kann, wenn mir das nicht passt.

    Mein Problem ist die Einbindung, konkret: wie erreiche ich, dass mein Skript dann ausgeführt wird, wenn ich eine Sicherungsplatte anstecke?

    Ein crontab-Eintrag läuft einfach zur festgelegten Zeit los, stellt fest: oh, huch, keine Platte, und fällt auf die Nase.