HBS3 startet falschen Job und killt damit den richtigen

  • Ich habe drei externe USB-Festplatten, die ich reihum für Backups meines TS-228A nutze(n möchte).

    Dementsprechend habe ich in Hybrid Backup Sync drei Backup Jobs, jeweils mit Schedule "Auto Backup" und "Eject after completion", die beim Anstecken der betreffenden Platte starten, eine Sicherung durchführen und die Platte dann auswerfen (sollen).

    Nach einer Kette von Problemen, die man in meinen anderen Beiträgen hier im Forum nachlesen kann, dachte ich eigentlich, ich hätte das jetzt soweit lauffähig hinbekommen.


    Als ich heute die nächste Sicherungsplatte im Zyklus angesteckt habe, hat HBS3 allerdings nicht nur den Job für diese Platte gestartet, sondern auch einen für eine andere Platte.

    Dieser ist nachvollziehbarerweise sofort abgebrochen mit der Meldung

    Code
    1. "Folder pairs are invalid or inaccessible"

    hat allerdings trotzdem die Platte ausgeworfen.

    Als Folge davon ist dann auch der andere, korrekte Sicherungsjob abgebrochen, weil sein Zielverzeichnis plötzlich weg war.

    Fehlermeldung (von Hand abgetippt - wann lernen die Leute endlich, dass es eine Sch***idee ist, Meldungstexte unkopierbar zu machen??):

    Code
    1. "File or directory doesn't exist. Attempting to retry. Error code: -2"


    WTF?


    Oder zivilisiert ausgedrückt: hat jemand ähnliches erlebt und/oder eine Idee, wie man das verhindern kann?

  • Hast du die Jobs mit der HBS3 eingerichtet oder wurde die unter einer älteren Version erstellt oder noch mit dem Sicherungsmanager?


    Ich habe hier eine HD immer dran, Tägliche Versionssicherung und stecke 2 HDs im welche an.


    Jede HD ist mit ihrer Volume ID dem jeweiligem Job zugeordnet. Bei HBS2 musste man dafür einen Hacken setzten, die 3er macht das automatisch.

    Wenn der fehlte, du von der 2er auf die 3er bist, würde das das Verhalten erklären.


    Also ich würde die Jobs noch mal alle löschen und sauber neu einrichten.


    Dann wird auch bei dir HBS3 sauber, zuverlässig und vor allem schnell arbeiten.

  • Ich hatte die drei Platten auch schon mit dem Sicherungsmanager in Verwendung.

    Damals hat auch alles zuverlässig funktioniert.


    Beim Wechsel auf HBS3 wurden die Jobs zu Sync Jobs migriert.

    Damit gab es aber diverse Probleme und Merkwürdigkeiten.

    Deshalb habe ich sie dann reihum alle neu eingerichtet.


    Also gut, richte ich nochmal alle neu ein, diesmal alle gleichzeitig.

    Gibt es eine Möglichkeit, dabei die alten Backups zu retten, bis auf die jeweilige Platte ein neues Backup geschrieben wird?

    Mir ist etwas unwohl dabei, ohne vollständigen Backup-Satz dazustehen, bis der erste Sicherungszyklus durch ist.

    Und gibt es inzwischen irgendwo eine klare Aufstellung, was die diversen Optionen wirklich bedeuten?

    Die Doku zu HBS3 ist ja eher, hmja.

  • Also ich würde die Jobs noch mal alle löschen und sauber neu einrichten.


    Dann wird auch bei dir HBS3 sauber, zuverlässig und vor allem schnell arbeiten.


    Habe ich probiert.


    Management Summary: funktioniert nicht. HBS3 arbeitet nach wie vor weder sauber noch zuverlässig noch schnell.


    Detailbericht:


    Zunächst habe ich HBS3 auf die neue Version 3.0.191115 aktualisiert.


    Dann habe ich in HBS alle vorhandenen Sicherungsjobs gelöscht. Zuerst habe ich versucht sie alle auf einmal auszuwählen und per Klick auf "Delete" in einem Rutsch zu löschen. Das führte dazu, dass zwei gelöscht wurden, einer übrig blieb und eine Meldung "Internal System Error" erschien. (Genauen Wortlaut habe ich nicht notiert, da ich zu dem Zeitpunkt noch glaubte, sie entweder reproduzieren oder trotzdem eine funktionierende HBS-Konfiguration erreichen zu können.) Im zweiten Anlauf ließ sich dann auch der verbliebene Job ohne Fehler löschen und HBS3 präsentierte sich jungfräulich mit der Begrüßungsseite, ich möge doch jetzt einen Sicherungsjob einrichten.


    Anschließend habe ich die erste meiner drei Sicherungsplatten angeschlossen und den Job dafür eingerichtet: Schedule "Auto-Backup", "Backup now" und "Eject external volume after completion" aktiviert, Smart Versioning, bei Policies alles bis auf "Exclude system-generated temp files" aus. Der Job lief an und glatt durch (brauchte allerdings 2 Stunden für 280 GB) und die Platte wurde wie gewünscht ausgeworfen.


    Dann habe ich die zweite Sicherungsplatte angeschlossen. Daraufhin passierte genau dasselbe wie im Ausgangsposting dieses Threads: nach Erkennung der Platte startete HBS den bereits eingerichteten Job, der beschwerte sich "Folder pairs are invalid or inaccessible" und warf die Platte aus. Ich hatte nicht einmal eine Chance, für die zweite Platte einen eigenen Job einzurichten.


    Das mit der Zuordnung der Volume ID zum Backup-Job funktioniert also zumindest auf meinem QNAP nicht.


    Followup


    Inzwischen ist mir aufgefallen, dass QTS die ext4-Partition der zweiten Sicherungsplatte unter demselben Namen gemountet hat wie die erste, nämlich "ImageStore".

    Das ist der Name (e2label) der ext4-Partition der ersten Sicherungsplatte. Die zweite hatte überhaupt keinen Label. (Ausgabe von e2label = leer.)

    Anstatt ihr dann einen Mountpoint "USBDisk1" o.ä. zu geben, hat QTS den Mountpoint der ersten Platte recycelt, nur um dann festzustellen "ups, das ist ja eine ganz andere Platte" und auf die Nase zu fallen.


    Abhilfe: Ich habe die zweite Platte an meinen Linux-PC gehängt und der ext4-Partition mit e2label ein Label verpasst - natürlich ein anderes als der ersten.

    Beim nächsten Anschließen an das QNAP hat HBS3 dann auch nicht mehr den Job für die erste Platte gestartet und ich konnte einen eigenen für sie einrichten.

    Der läuft gerade - bis jetzt sieht alles gut aus.


    Bin gespannt, was dem QNAP einfällt, wenn ich als nächstes die erste Platte wieder anhänge, und was passiert wenn ich versuche auch noch die dritte einzubinden.

    Stay tuned!


    Followup2


    Erste Platte wieder angehängt, Sicherung darauf hat einwandfrei funktioniert. Auch die Fehlermeldung:

    Failed to create multi-version

    ist nicht wieder aufgetreten. Es wurde korrekt eine neue "latest" Version gesichert und die alte entsprechend des Datums umbenannt.

    Die dritte Platte habe ich dann von vornherein mit einem Label versehen, auch sie wurde daraufhin korrekt erkannt, unter ihrem Label gemountet und ich konnte für sie einen eigenen Job einrichten.


    Fazit: HBS greift bei der Zuordnung offenbar nicht auf die Volume-ID zurück, sondern auf das Filesystem-Label, und geht nicht sauber damit um, wenn dieses Label leer ist. Also bei externen Platten immer schön die Partitionen labeln, bevor man sie ans QNAP anschließt!

    2 Mal editiert, zuletzt von tgsbn () aus folgendem Grund: Man kann hier im Forum offenbar kein Followup auf einen Thread schreiben, wenn man selbst der letzte Poster war.

  • Ok, jetzt will mich die Forumssoftware das letzte Posting nicht mehr editieren lassen, dafür darf ich jetzt ein Followup schreiben, obwohl ich der letzte Poster war. Na ja, ist ja auch eigentlich egal. Jedenfalls ...


    Followup3


    Zu früh gefreut, nach zwei erfolgreichen Sicherungszyklen ist der Spaß schon wieder vorbei.

    Vor fünf Stunden habe ich turnusmäßig die nächste USB-Platte zwecks Sicherung angeschlossen.

    Sie wurde auch erkannt und eingehängt, der richtige HBS3-Job startete ... und steht seitdem mit Status "Running...0%" in der Jobübersicht.

    Da die vorhergehende Inkrementsicherung nur dreieinhalb Minuten brauchte und selbst die initiale Vollsicherung in neunzig Minuten durch war, deutet das doch stark auf ein Problem hin.


    Laut Dashboard idlet das NAS mit 6% CPU und 49% RAM vor sich hin.

    In der FileStation kann ich auf die USB-Platte zugreifen.

    Ich sehe auch die beiden alten Sicherungen darauf.

    Für die neue wurde noch nicht einmal ein Ordner angelegt.

    Merkwürdig auch, dass das Verzeichnis "latest" nicht auf die letzte, sondern auf die vorletzte Sicherung verweist.


    Wenn ich per ssh auf das NAS gehe, sehe ich mit ps -o pid,ppid,user,stat,args eine Prozessfamilie

    Code
    1. PID PPID Uid Stat Command
    2. 21982 1 admin S python /share/CACHEDEV1_DATA/.qpkg/HybridBackup/CloudConnector3/python/bin/rra d9ef20bc-0fd1-11ea-a845-245ebe1625d1 start
    3. 21996 21982 admin S /usr/bin/RTRR -C:/etc/qsync/qsynchbs3.conf -J:Job0
    4. 22354 21996 admin Z [sh]

    Da der letzte Prozess im Zustand Z ist, habe ich nicht viel Hoffnung, dass sich da bei weiterem Warten noch etwas tun wird.


    Das Notification Center zeigt als letzte Meldung

    Code
    1. "[Hybrid Backup Sync] Started Backup job"

    , seitdem Funkstille.

    Ebenso sieht's im Logs-Tab von HBS3 Reports aus.


    Followup4


    Nach 30 Stunden war der Zustand in jeder Hinsicht unverändert. Ich habe dann in HBS3 mal auf "Stop" geklickt. Die Platte wurde ausgeworfen und die oben gelisteten Prozesse sind weg. In der per Save-Button heruntergeladenen "full log history" findet sich in nas\data\system\nas\d9ef20bc-0fd1-11ea-a845-245ebe1625d1\rra.log der Verlauf des Jobs.

    (Leider länger as das Größenlimit des Forums, deshalb müsst Ihr mir meine Interpretation einfach glauben.)

    Demnach hat HBS3 vom Start gestern um 13:16 bis zum Abbruch heute um 18:54 buchstäblich nichts getan, hat auch auf das Beendigungssignal nicht reagiert, wollte dann aber, nachdem die Sicherungsplatte wegen Jobende ausgeworfen war, die Sicherung auf einmal doch noch durchführen und warf dann 2134 Fehlermeldungen aus, weil der Zielordner verschwunden war.


    Ich habe dann die Platte nochmal neu angesteckt, mit genau demselben Resultat: Job startet, bleibt dauerhaft bei "Running...0%" stehen, und in ps hat der RTRR-Prozess einen Zombie-Kindprozess [sh].

    In /share/CACHEDEV1_DATA/.qpkg/HybridBackup/data/system/nas/d9ef20bc-0fd1-11ea-a845-245ebe1625d1/rra.log sehe ich dabei auch, dass die Fehlermeldungen wegen des fehlenden Zielverzeichnisses tatsächlich erst nach Abbruch des Jobs auftauchen.


    Nächster Versuch mit einer anderen Platte, und was soll ich sagen: genau dasselbe Ergebnis. Auch deren Job startet und bleibt bei 0%.

    6 Mal editiert, zuletzt von tgsbn ()

  • Der letzte Versuch läuft jetzt seit 5 Tagen, 4 Stunden, 7 Minuten und steht immer noch bei "Running...0%".

    Schätze, damit ist nachgewiesen, dass sich da nichts mehr tut.

    Habe jetzt einen Support Request bei QNAP gestellt.


    Edit

    Bis jetzt natürlich noch keine Antwort.

    Um die Wartezeit zu überbrücken, habe ich mir die erste Platte nochmal vorgenommen und folgendes gemacht:

    1. den HBS3-Job für diese Platte deaktiviert (was, wie ärgerlicherweise bekannt, die Option "Schedule" von "Auto-Backup" auf "No schedule" geändert, die Option "Eject after completion" aber, wiewohl ausgeblendet, diesmal aktiviert gelassen hat)
    2. die Platte angeschlossen
    3. per ssh mit df -i kontrolliert, ob sie womöglich keine freien inodes mehr hat (Antwort: nein - 112k used, 69M available)
    4. in File Station ihren Inhalt inspiziert und eine alte HBS2-Sicherung, die neben dem HBS3-Sicherungsordner noch darauf lag, gelöscht
    5. den HBS3-Job wieder aktiviert, dabei "Schedule" wieder auf "Auto-Backup" gesetzt, die Option "Eject after completion" deaktiviert und die Option "Backup now" aktiviert.

    Und was soll ich sagen: der Job lief fehlerfrei durch!


    Ich sehe verschiedene mögliche Erklärungen:

    • HBS3 mag es nicht, wenn auf derselben Zielplatte noch HBS2-Sicherungen liegen. (Aber warum dann erst beim dritten Durchlauf?)
    • HBS3 hat ein Limit von 100.000 inodes auf dem Zielmedium.
    • HBS3 hat ein Problem mit der Option "Eject after completion".
    • HBS3 hat ein Problem mit dem automatischen Start nach Anschließen des Zielmediums.
    • Der Job hatte ein Problem, das irgendwie durch das Deaktivieren und Reaktivieren behoben wurde.

    Sollte die Antwort des QNAP-Supports länger auf sich warten lassen, werde ich die Versuchsreihe fortsetzen.

    Die zweite Platte und ihren Job sollte ich wahrscheinlich im jetzigen Zustand lassen, damit der Support etwas zu untersuchen hat.

    Aber ich habe ja noch mehr USB-Platten, mit denen ich spielen kann.

    Einmal editiert, zuletzt von tgsbn () aus folgendem Grund: EDV

  • Der QNAP Support hat auf mein Ticket reagiert, will mir aber nicht helfen. Der Support-Mitarbeiter hat mich erst nach Hersteller und Modell meiner externen USB-Platte gefragt, um mir dann mitzuteilen, dass gerade dieses Modell nun aber nicht auf der QNAP-Kompatibilitätsliste stehe. Zitat: "somit können wir diese nicht als Fehler Quelle ausschließen"


    Dass der Fehler mit zwei verschiedenen externen Festplatten unterschiedlicher Hersteller auftrat, ist offenbar uninteressant.

    Der QNAP Support wird erst tätig, wenn alle anderen möglichen Fehlerquellen ausgeschlossen sind.


    Mal schauen, ob er bei dieser Position bleibt.

    Wenn ja, kann ich QNAP als seriösen Lieferanten ausschließen.

  • Wie hier nachzulesen weigert sich der QNAP-Support weiterhin, sich mit dem HBS3-Fehler zu befassen.

    Da der Thread von der Moderation geschlossen wurde, kann ich die Nachfragen dort nicht mehr beantworten und bitte alle Fragesteller, die erbetenen Details stattdessen hier nachzulesen.

    Solange dieser Thread hier nicht auch geschlossen wird, bin ich gerne bereit, weitere Detailfragen zu beantworten.


    Fortsetzung der Testreihe: Das Problem ist nun auch einmal bei abgeschalteter Option "Eject after completion" aufgetreten.

    Ein Abbruch und manueller Neustart des Sicherungsjobs hat nicht geholfen.

    Auf der Sicherungsplatte war auch keine HBS2-Sicherung mehr.

    Nach Löschen eines Ordners außerhalb des HBS3-Zielordners lief die Sicherung wieder problemlos durch.


    Die Erklärungen:

    • HBS3 mag es nicht, wenn auf derselben Zielplatte noch HBS2-Sicherungen liegen.
    • HBS3 hat ein Problem mit der Option "Eject after completion".
    • HBS3 hat ein Problem mit dem automatischen Start nach Anschließen des Zielmediums.
    • Der Job hatte ein Problem, das irgendwie durch das Deaktivieren und Reaktivieren behoben wurde.

    sind damit meiner Ansicht nach raus, ebenso die Theorie des QNAP-Supports von einem Kompatibilitätsproblem der USB-Festplatte.

    Es bleibt eigentlich nur noch die Erklärung, dass HBS3 mit externen Festplatten ein Problem hat, auf denen bereits zu viele Dateien liegen.


    Beobachtung am Rande: Der Fehler trat bis jetzt nur mit ext4-formatierten Sicherungsplatten auf.

    Meine NTFS-formatierte Sicherungsplatte (deren Sinnhaftigkeit hier im Forum ja schon heftig in Frage gestellt wurde) war bis jetzt nicht betroffen.

    Einmal editiert, zuletzt von tgsbn () aus folgendem Grund: neue Testergebnisse