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
     "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
    "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
      PID  PPID  Uid     Stat Command
    21982     1 admin    S   python /share/CACHEDEV1_DATA/.qpkg/HybridBackup/CloudConnector3/python/bin/rra d9ef20bc-0fd1-11ea-a845-245ebe1625d1 start
    21996 21982 admin    S   /usr/bin/RTRR -C:/etc/qsync/qsynchbs3.conf -J:Job0
    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
    "[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

  • Zu Deinem Problem , Auswurf des USB LW nach Synchronisierung, hatte ich ein Ticket eröffnet. Da bei mir bei Synchronisierung mit Zeitplan auch kein Auswurf möglich war. Heute kam die Antwort s.O. mal sehen ob sich da noch etwas ändert.?(

  • Update:

    1. Eine weitere externe Platte mit ext4-Dateisystem hat nach zwei erfolgreichen Sicherungen beim dritten Mal den bereits beschriebenen Zustand erreicht, dass die GUI bei "Running...0%" stehen bleibt und der RTRR-Prozess einen Zombie-Kindprozess [sh] hat. Wieder ein anderer Typ und Hersteller, und nein, auch die steht nicht auf der QNAP-Kompatibilitätsliste. Macht mich aber zuversichtlich, dass ich nach Anschaffung einer USB-Platte, die auf der Kompatibilitätsliste steht, das Problem auch damit werde reproduzieren können.

    2. Nach einigen Verhandlungen mit dem QNAP-Supportmitarbeiter habe ich im Angebot von Mediamarkt eine USB-Festplatte gefunden, die "fast" auf der QNAP-Kompatibilitätsliste steht: eine "Seagate Expansion Portable". Auf der QNAP-Kompatibilitätsliste steht zwar "Protable", aber der Supportmitarbeiter hat mir zugestanden, dass das wohl ein Tippfehler sei. Mal sehen ob er sich daran erinnert wenn ich das Problem mit dem Teil reproduziert habe.

  • Update:

    Erwartungsgemäß ist das Problem auch mit der extra dafür beschafften Seagate Expansion Portable alsbald aufgetreten.

    Ich habe das Ergebnis dem QNAP Support am 2020-02-06 23:54:41 mitgeteilt und bin sehr gespannt wie es weitergeht.


    Update 2:

    Nachdem der HBS3-Job mit der neuen, QNAP-kompatibilitätsgelisteten Festplatte 22 Stunden 54 Minuten bei 0% hing, meldete QTS die Platte als "removed successfully" und unmittelbar darauf wieder als "detected". Den laufenden bzw. hängenden HBS3-Job hat das nicht weiter gekümmert, aber HBS3 wollte - weil Platte vermeintlich neu eingesteckt - denselben Job noch einmal starten und meldete folgerichtig:

    Code
    Severity Level    Date    Time    Users    Source IP    Application    Category    Content    
    Error    2020/02/07    21:48:06    System    127.0.0.1    Hybrid Backup Sync    Job Status    [Hybrid Backup Sync] Failed to complete Backup job: "QNAPBug". Previous instance of "QNAPBug" still in progress. Wait until the job completes, and try again.    

    Zum fraglichen Zeitpunkt war niemand in der Nähe des NAS, es ist also auszuschließen dass jemand tatsächlich die Platte aus- und eingesteckt oder am Kabel gewackelt hat.

    Mit den anderen, nicht QNAP-genehmigten Platten ist so etwas bisher nicht vorgekommen,

    Einmal editiert, zuletzt von tgsbn ()

  • 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.

    Ergänzung: Das funktioniert nur, wenn das Label kein Leerzeichen enthält.

    Bei meinem obigen Test mit der QNAP-kompatibilitätsgelisteten Festplatte hatte ich die ext4-Partition zunächst als "QNAP Bug" gelabelt. Prompt hat QTS sie als "USBDisk1" eingebunden. Nachdem ich das Label auf "QNAPBug" geändert habe, erscheint sie jetzt wie gewünscht unter ihrem eigenen Namen, so dass HBS3 nicht mehr durcheinanderkommt.

  • und steht seitdem mit Status "Running...0%" in der Jobübersicht.

    Dass die Jobs hängen habe ich seit Monaten, siehe auch Synchronisierung hängt. Es betrifft bei mir aber externe Platten als auch RTRR Sicherungen und Syncs zu anderen Qnap Geräten. Immer wieder abwechselnd unterschiedliche HBS Aufträge.


    Aktuell hängt ein Sicherungsjob bei einem TVS-882 auf eine externe Festplatte die nicht in der Kompatibilitätsliste ist (wobei das Produkt grundsätzlich schon in der Liste ist aber halt nicht mit 12 TB), die gleiche externe Platte an einem anderen Qnap (TVS-882T) ohne Probleme seit Wochen funktioniert.

  • Update:

    Der QNAP Support hat sich gemeldet und nach drei Runden Nachfragen mit Anforderung diverser Screenshots schließlich die folgende Fehlerbeschreibung vorgeschlagen:

    Zitat von QNAP Support

    Also zusammenfassend kann man sagen das mit der Kompatiblen Festplatte der Automatische Backup Job nicht funktioniert.

    Ist das soweit korrekt ?

    Um die Bearbeitung nicht weiter hinauszuzögern, habe ich keine Präzisierung mehr angeregt, sondern dem so zugestimmt. (Es ist ja auch nicht falsch, nur nichtssagend.)

    Der Supportmitarbeiter hat mir daraufhin mitgeteilt, er habe meinen Fall an die Entwicklung weitergegeben und hoffe auf eine schnelle Bearbeitung.

    Ich bin gespannt, wann und wie es weitergeht.


    In der Zwischenzeit behelfe ich mir damit, immer, wenn die Sicherung auf eine meiner regulären (laut QNAP-Support "nicht kompatiblen") Sicherungsplatten wieder einmal bei 0% hängenbleibt, auf der betroffenen Zielplatte irgendetwas zu löschen, was ich verschmerzen kann. Bisher hat das jedesmal so weit geholfen, dass wenigstens eine weitere Sicherung durchlief. So stehe ich wenigstens nicht ganz ohne Sicherung da. Mit dieser Beobachtung wollte ich den QNAP-Support jetzt aber nicht zusätzlich verwirren, zumals es ja auch nur die "nicht kompatiblen" Platten betrifft, mit denen er sowieso nichts zu tun haben will. (Ob das auf der "kompatiblen" Platte auch hilft, habe ich vorsichtshalber nicht ausprobiert.)

  • Update: Der Support verlangt jetzt, dass ich auf QTS 4.4.1 update.

    Das ist jetzt echt blöd, weil die Version ja soweit ich im Forum lese, immer noch das Problem hat, dass das Media Center die komplette Platte indizieren will, was ich auf keinen Fall will.

    Was tun?

  • Update: Heute bot mir mein NAS ein Update für HBS3 auf Version 3.0.200212 an.

    Mit dieser Version tritt das Problem nicht mehr auf.

    Außerdem ist beim Editieren eines Jobs jetzt die Schedule-Optionen "Auto-backup" und "Eject after completion" auch dann sichtbar, wenn die externe Festplatte nicht angeschlossen ist.

    Also Gewinn auf der ganzen Linie.


    Dann will ich mich mal freundlich beim QNAP Support für die erfolgreiche Lösung bedanken.