HBS3 Warnung "Failed to create multiple versions for backup"

    Zum zweiten Mal innerhalb von vierzehn Tagen hat einer meiner Backups auf externe USB-Platten die Ereignismeldung generiert:


    Code
    Warning    2021-08-08    00:05:35    admin    127.0.0.1    Hybrid Backup Sync    Custom Job Event    [Hybrid Backup Sync] Finished Backup job "ImageStore" with errors. Failed to create multiple versions for backup.


    Beim Klick darauf wird die Meldung in QuLog angezeigt, da scheint es aber keinerlei Möglichkeit zu geben, weiterführende Informationen zu bekommen. Auch in HBS3 finde ich keine weiteren Informationen, sondern nur auf dem Reiter "Logs" des betreffenden Jobs dieselbe knappe Meldung.

    In dem per Save-Button heruntergeladenen Systemlog-Archiv stehen in der /system/ImageStore/detail/qsync-8556ff68-0edf-11ea-8289-245ebe1625d1.log die Warnungen:

    Code
    [2021/08/07 23:59:59] # WARNING:Cannot create a multi-version backup.
[2021/08/07 23:59:59] # WARNING: The second path of the folder pair [Download, /ImageStore/Nessy/ImageStore/latest/Download/] is invalid or inaccessible, the synchronization will skip this folder pair.
[2021/08/08 00:05:38] # WARNING: Job finished with warning. (Cannot create multi-version for this job.)

    Sonst nichts, insbesondere keinerlei Information, warum die Version nicht angelegt werden konnte und was das für Konsequenzen hat.


    Das Dateisystem auf der Sicherungsplatte ist ext4.

    Darauf sind 568 GB von 1,8 TB und 121755559 von 122077184 Inodes frei.

    Der laut Job-Warnmeldung "invalid or inaccessible" Ordner /ImageStore/Nessy/ImageStore/latest/Download/ ist vorhanden und sieht auf den ersten Blick korrekt aus.


    Bei allen meinen Backup Jobs ist Versioning aktiv.

    Bei den beiden, die die Warnung ausgelöst haben, steht es auf Simple Versioning mit Retained Versions = 100.

    Vorhergehende Sicherungen auf die beiden Platten liefen ohne Fehler oder Warnung durch.

    Die Konfiguration der Jobs wurde nicht verändert, und die Platten wurden zwischendurch nirgendwo anders angeschlossen.


    Woran kann es liegen, dass HBS3 plötzlich keine Versionen mehr anlegen kann und einen der Zielordner nicht mehr zugreifen mag?

    Zitat von tiermutter

    Scheint ja irgendwas mit den Dateien zu tun zu haben, Du hattest das Problem vor zwei Jahren ja schonmal mit den Dateien:

    HBS3 Backup Version Management geht nicht

    Naja, der Fall damals lag doch etwas anders.

    Damals hatte ich bei einem bestehenden Job die Versionierung nachträglich aktiviert, und HBS3 hat sich von Anfang an geweigert, irgendwelche Versionen anzulegen.

    Diesmal betrifft es Jobs, die über die letzten Jahre schon klaglos eine ganze Reihe von Versionen auf dem Zielmedium angelegt haben. Die sind auch noch alle da. Nur eine weitere Version hinzuzufügen soll nun ohne nähere Begründung auf einmal nicht mehr möglich sein.


    Ein weiterer Unterschied ist diesmal die Meldung, einer der Zielordner sei "invalid or inaccessible".

    Die hatte ich damals auch nicht.


    Und dann verschwand das Problem damals ja nach einem HBS3-Update, Neulabeln der Platte und Neuanlegen des Jobs, ohne dass sich je geklärt hätte, was denn nun eigentlich der Grund war.

    Deshalb würde ich diesmal der Sache doch gerne auf den Grund gehen.

    Gerade beim Backup möchte man doch nicht, dass irgendwelche Probleme ungeklärt unter der Decke schlummern.

    Zitat von tiermutter

    Schonmal mit einer vorherigen HBS3 Version versucht oder ggf. die aktuellste Version installiert?

    Zwischen den beiden Fällen habe ich das Update auf 17.2.0726 installiert.

    Das Problem ist also mit zwei verschiedenen HBS3-Versionen aufgetreten.

    Andererseits ist dazwischen ein ebenfalls versioniertes Backup auf eine andere USB-Platte ohne Fehler oder Warnungen durchgelaufen.


    Wenn niemand eine Idee hat, werde ich jetzt mal beobachten, ob ich irgendeine Regelmäßigkeit finde, wann der Fehler auftritt und wann nicht.

    Derzeit habe ich fünf Platten im Sicherungszyklus, mit zweien davon ist er bis jetzt je einmal aufgetreten.

    Da kann man noch nicht wirklich viel sagen, ob es an der Platte hängt, an der HBS3-Version, an der Tageszeit oder an der mittleren Mondfeuchte.

    Das Problem weitet sich aus. Heute ist der Fehler bei einer dritten Platte aufgetreten. Da das meine eigens für einen früheren QNAP Support Case beschaffte einzige auf der QNAP Hardware Compatibility List stehende Platte ist, könnte ich jetzt einen Support Case aufmachen. Aber vorher müsste ich QTS aktualisieren, da wird sich der Support sonst erfahrungsgemäß sofort dran aufhängen. Das wird also jedenfalls heute nichts mehr.


    Weitere Beobachtungen:

    • Wenn das Problem bei einer Platte einmal aufgetreten ist, tritt es auch bei jeder weiteren Sicherung auf diese Platte wieder auf.
    • Die drei bis jetzt betroffenen Platten sind alle mit ext4 formatiert, die beiden bisher nicht betroffenen mit NTFS.

    Zumindest bis jetzt - bin gespannt, ob es dabei bleibt.

    Zitat von tgsbn

    Aber vorher müsste ich QTS aktualisieren, da wird sich der Support sonst erfahrungsgemäß sofort dran aufhängen.

    Ich würde trotzdem schon ein Ticket erstellen, das Problem scheint ja kaum mit der FW im Zusammenhang zu stehen. Und wenn das Thema dann doch auf den Tisch kommt und es zwangsläufig sein muss... naja denn... aber so geht es wenigstens schonmal voran.

    Was mich halt stutzig gemacht hatte war, dass damals bei Dir ja auch der gleiche Ordner mit vermutlich den gleichen/ ähnlichen Dateien betroffen war.

    Ist das der einzige Ordner in dem Job? Könntest Du sonst eventuell mal ausschließen. Zu lange Dateinamen/ Pfade in dem Ordner?

    Ok, gutes Argument.

    Ticket Q-202108-68158 erstellt.

    Schau'n wir mal, wann und wie QNAP reagiert.


    Der Ordner "Download" enthält (wie der Name schon sagt) nur meine Sammlung aus dem Internet heruntergeladener Dateien, also einerseits nichts unersetzliches und andererseits nur Dateien mit verhältnismäßig "normalen" Namen, nichts überlanges oder mit komischen Zeichen drin - schließlich wollen die Anbieter ja auch, dass der Download bei jedem klappt.


    Den vorgeschlagenen Test, diesen Ordner mal von der Sicherung auszunehmen, habe ich gemacht.

    Und tatsächlich: ohne den Ordner "Download" läuft die Sicherung fehlerfrei durch.

    Nehme ich ihn wieder rein, ist auch der Fehler wieder da.

    Scheint also doch irgendetwas mit dem Inhalt dieser Freigabe zu tun zu haben.

    Nur was, warum erst jetzt und warum nur bei Sicherung auf eine ext4-formatierte Platte?


    Die Längen der Dateipfade in der Freigabe habe ich geprüft.

    Der längste Pfad ist

    Code
    "Documents/Exchange-Schulung/Exchange/Hardening Microsoft Exchange 2016 Server-Dateien/You_do_not_have_the_permission_to_send_the_message_on_behalf_of_tn.gif"

    mit 157 Zeichen, die längste Pfadkomponente (Datei- oder Ordnername)

    Code
    "18362.30.190401-1528.19h1_release_svc_refresh_CLIENTENTERPRISEEVAL_OEMRET_x64FRE_de-de.iso"

    mit 91 Zeichen.

    Ok, für einen alten System-III-Unixer (max. 14 Zeichen), PDP-11-er (9+3) oder CP/M-ler (8+3) schon exzessiv, aber für heutige Verhältnisse doch noch im Rahmen.


    Die letzte dazugekommene Datei ist:

    Code
    Software/ct2112_desinfect_2021.iso

    am 2021-06-29 20:45:08. Danach liefen noch zwei erfolgreiche Backups auf die Platte, mit der ich jetzt getestet habe.


    Alles sehr merkwürdig. Bin gespannt, was der QNAP Support sagt.

    Der Inhalt kopiert in in einen Ordner BUtest, lässt der sich sichern?


    Wenn du dann die Dateien im Download löscht und durch die anderen ersetzt geht es dann?


    Könnte in dem Fall ein Rechteproblem sein oder die Datei ist für das NAS in Verwendung und damit blocked.


    Werden bei deinen Jobs Snapshots erstellt? Hat diese Funktion einen Einfluss?

    QNAP-Support hat erwartungsgemäß geantwortet:

    Zitat von QNAP Support

    vielen dank das Sie sich an den Qnap Support gewendet haben. Bitte führen Sie zunächst ein Update auf die aktuelle Firmware Version und die aktuelle HBS Version durch. Prüfen Sie, nach einem Neustart im Anschluss an die Updates, ob das Problem weiterhin besteht

    Also kein Support ohne vorheriges Update.

    Zitat von Crazyhorse

    Der Inhalt kopiert in in einen Ordner BUtest, lässt der sich sichern?

    Das ist mir nicht ganz klar, was ich da testen soll. Soll ich BUtest als eine separate neue Freigabe anlegen oder als Ordner unter einer der vorhandenen Freigaben, die sich sichern lassen? Soll ich dann BUtest alleine sichern oder den Sicherungsjob, der aktuell bei Einschluss des Ordners Download fehlschlägt und ohne ihn erfolgreich ist, auf BUtest anstelle von Download umstellen?


    Ich frage so dumm, weil mir nicht ganz klar ist, welche Aussage Du Dir von diesem Test erhoffst. Es ist ja nicht so, dass sich der Ordner Download grundsätzlich nicht sichern lässt. Nur auf drei meiner fünf Sicherungsplatten schlägt es fehl, auf den anderen beiden läuft die Sicherung einwandfrei durch.

    Einmal editiert, zuletzt von tgsbn () aus folgendem Grund: Antwort von Crazyhorse gesehen

    Ich würde den Inhalt in einen neuen Ordner auf dem NAS kopieren und dann einen Test Job in HBS3 neu anlegen und schauen ob er diesen Ordner sichern kann.

    Auf ein HD bei der ein normaler Job Probleme bereitet.


    So kannst du nach dem Test den Ordner auf Quelle und Ziel einfach löschen.

    Der kopierte Ordner lässt sich einwandfrei sichern.

    Allerdings lässt sich auch der Originalordner "Download" in einem neu angelegten Job fehlerfrei sichern.

    In drei meiner vorhandenen Jobs verursacht er hingegen nach wie vor den Fehler "Cannot create a multi-version backup."

    Dort allerdings auch, wenn ich alle anderen drei Ordner abwähle und nur ihn alleine zu sichern versuche.

    Wenn ich andererseits nur den Ordner "Download" abwähle, werden die übrigen drei fehlerfrei gesichert.

    Und dann gibt es auch noch zwei vorhandene Jobs, in denen alle vier Ordner nach wie vor fehlerfrei gesichert werden.

    Gemeinsamkeiten der fehlschlagenden Jobs sehe ich mittlerweile keine mehr:

    • Die meisten Einstellungen sind ohnehin bei allen meinen Jobs identisch, z.B. habe ich die Option "Do not take snapshots" bei keinem meiner Jobs aktiviert.
    • Bei allen meinen Jobs ist Version Management aktiv, teils "Simple", teils "Smart". Unter den fehlschlagenden Jobs sind sowohl welche mit "Simple" als auch mit "Smart" Versioning.
    • Eine meiner fünf Sicherungsplatten ist NTFS-formatiert, die anderen vier mit ext4. Auf der NTFS-Platte ist der Fehler bis jetzt nicht aufgetreten. Von den vier ext4-Platten schlägt auf zweien das Backup des Download-Ordners fehl, auf einer läuft es fehlerfrei. Auf der vierten produziert der reguläre Job den Fehler, der obige Testjob aber nicht.

    Ich habe keine Idee mehr, was da die Problemursache sein könnte. Zumal ja auch nichts darüber herauszubekommen ist, woran denn das "create a multi-version backup" tatsächlich scheitert. "Cannot" - basta.

    Kannst du für den Job einen integrety check durchführen? Vllt erkennt und repariert der ja das Problem...


    Edit:

    Geht wahrscheinlich nicht, sonst wärst Du wahrscheinlich schon auf die Idee gekommen. Externe HDD gilt wohl als NAS to NAS Job und das geht dann nur mit QuDedup.

    Einmal editiert, zuletzt von tiermutter ()

    Jetzt habe ich mal aus einer Eingebung heraus in Rules > Policies die Option "Remove additional files in destination folder" aktiviert - und was soll ich sagen: der Fehler ist weg!


    Genauer:

    Ich dachte mir, irgendwas ist vielleicht in dem Zielordner auf der USB-Platte, was die Hardlink-Erzeugung für die Versionierung stört.

    Also, dachte ich mir, wie werde ich das los? Wenn ich, während der Ordner aus der Sicherung ausgenommen ist, diese Option aktiviere, löscht HBS3 dann vielleicht auch den Zielordner? Hat es aber nicht getan. Natürlich ist die Sicherung fehlerfrei gelaufen, wie immer wenn ich den Download-Ordner ausgenommen habe, aber auf der USB-Platte war er unter "latest" trotzdem noch da.

    Dann habe ich - jetzt kommt die Eingebung - den Download-Ordner wieder in die Sicherung mit reingenommen, aber die Option "Remove additional files in destination folder" aktiv gelassen. Und siehe da: die Sicherung lief nun auch unter Einschluss des Download-Ordners fehlerfrei durch.


    Erklärungsversuche willkommen. Ich werde das jetzt sukzessive mit den anderen betroffenen Platten auch testen, ob das nur Zufall war oder tatsächlich systematisch hilft. Falls letzteres, werde ich diese Option generell aktiv lassen. Da sie die "additional files" offenbar nur aus der "latest"-Sicherung löscht und in den datierten Versionen drin lässt, wäre das kein Verlust an Sicherheit.

    Wurde denn irgendwas, evtl. auch Verstecktes, bei dem Backup weggelassen?

    Und was passiert, wenn der nächste Job ohne die Option gestartet wird?

    Die Option wirkt tatsächlich nicht auf Versionen, sondern nur auf den latest, daher finde ich die Option bei versionierten Backups irgendwie überflüssig (man glaubt, man spare dadurch Kapa im Backup, was aber nicht so ist).

    Zitat von tiermutter

    Wurde denn irgendwas, evtl. auch Verstecktes, bei dem Backup weggelassen?

    Nicht, dass ich wüsste.

    Zitat von tiermutter

    Und was passiert, wenn der nächste Job ohne die Option gestartet wird?

    Naheliegende Frage, hätte ich auch selber drauf kommen können.

    Getestet:

    • Option "Remove additional files in destination folder" deaktiviert, Backup gestartet: Fehler
    Code
    Warning	2021-08-29	12:25:34	admin	127.0.0.1	Hybrid Backup Sync	Custom Job Event	[Hybrid Backup Sync] Finished Backup job "ImageStore" with errors. Failed to create multiple versions for backup.
    • Option "Remove additional files in destination folder" wieder aktiviert, Backup gestartet: kein Fehler
    Code
    Information	2021-08-29	13:11:38	admin	127.0.0.1	Hybrid Backup Sync	Job Status	[Hybrid Backup Sync] Finished Backup job: "ImageStore".


    Scheint also tatsächlich an der Option zu hängen.

    Tja, zu früh gefreut. Heute meldete ebendieser HBS3-Job trotz nach wie vor aktivierter Option "Remove additional files in destination folder" den Fehler "Cannot create a multi-version backup."


    Der QNAP-Support hat jetzt die Theorie geäußert, das Problem könnte durch ein HBS-Update ausgelöst worden sein. Tatsächlich wurde HBS3 Version 17.2.0726 laut App Center am 2021/08/06 installiert, was bei den Jobs, die das Problem haben, zwischen dem letzten erfolgreichen und dem ersten fehlerhaften Backup-Lauf liegt. Nicht so ganz dazu passt aber meiner Meinung nach das Hin und Her mit der Option "Remove additional files in destination folder."


    Ich werde weiter berichten.

    Auch wenn sich nicht viel getan hat, mal ein kleiner Zwischenstand aus der Bearbeitung des Supporttickets:

    • Das Ticket wurde von einem anderen Bearbeiter übernommen.
    • Ich wurde gebeten, den Remote Support zu aktivieren. Das habe ich getan, es hat sich aber nie jemand verbunden.
    • Stattdessen wurde ich drei Tage später aufgefordert, auf Firmware-Version 4.5.4.1800 zu aktualisieren und zu testen, ob das Problem damit weiterhin auftritt. Wenig überraschend war das der Fall.

    Bin gespannt, was die nächste Ausrede ist, warum der Fall noch nicht an die Entwicklung eskaliert werden kann.