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.