FileNotFoundError

Seit dem Update auf 24.1.0529 habe ich da ein ganz seltsames Phänomen. Alle Sync- und Backup-Jobs, mit und ohne Versionierung usw laufen wie gewohnt. Aber genau ein Backup-Job verhält sich seltsam.

Diesen Job habe ich erst mal probehalber angelegt, ohne Versionierung, täglich verschlüsseltes Backup auf den QNAP-Cloud-Speicher. Das gesicherte Verzeichnis enthält unterschiedlichste Dokumente, Fotos und DVD/CD-Images. Alles Funktioniert wie gewünscht - fast. Genau ein DVD-Image weigert sich HBS3 zu sichern. Dieses Image ist nicht besonders groß, es gibt wesentlich gröére. Der Name ist genau nach dem gleichen Schema wie alle anderen. Aber vor allem wundert miuch die Fehlermeldung:FileNotFoundError. Das File ist definitv da. Ich habe es schon manuell auf den Cloudspeicher kopiert - geht ohne Problem. Ich habe ien Kopie erstellt mit anderem Namen - geht nicht. Hab das Image neu erstellt - geht nicht. Hab's mal gezippt - geht nicht (in der Fehlermeldung ist dann das "ISO" durch "ZIP" ersetzt). Später hinzugekommene ISOs und andere Dokumente funktionieren wieder ohne Problem. Nur genau dieses eine File eben nicht.

Der Support kann ohne Logfile nicht helfen und kennt das Problem nicht. Aus besonderen Gründen gibt's diesmal aber kein Log zum rausgeben. Vielleicht hat jemand was ähnliches erlebt? Ich habe gehofft, es gibt nach den letzten Problemen mit HBS3 bald ein weiteres Update, aber da warte ich nun schon länger. Ist ja nicht kritisch, die eine Datei konnte ich auch manuell sichern, alles andere geht ja. Dennoch wurmt mich diese tägliche Meldung.

App Name: Hybrid Backup Sync
Category: Job Status
Message: [Hybrid Backup Sync] Backup job "Backup xyz": Failed to upload file/folder from "/Verzeichnis1/Verzeichnis2/Verzeichnis3/DVD CT 13_06_24.ISO". Error: FileNotFoundError

Nein, ist alles wirklich identisch. Und der Name ist genau so, nur die Verzeichnisse habe ich verfälscht. Jetzt habe ich den Job mal komplett gelöscht und auch die Daten auf dem Server. Dann das nochmal neu eingerichtet. Mal sehen, was passiert.

EDIT: Ok, immerhin ist es jetzt einheitlich: Jetzt werden nach und nach 10 ISO-Files als fehlend genannt und dann der Job wegen der maximal 10 erlaubten Fehlern abgebrochen. Also warte ich doch erst mal wieder auf das nächste Update oder verzichte auf dieses Backup - war ursprünglich auch nur ein Versuch.

Gut und recht (hatte auch oben noch was ergänzt) - aber das kann es nicht sein.

Die Verzeichnisse enthalten Umlaute und Leerzeichen, das ist richtig. Der Inhalt der problematischen Datei ist per isoburn erstelltes Image einer DVD eines CTs, so wie ca. 15 weitere in genau diesem Ordner vorhandene, welche bisher alle ohne Anstand kopiert wurden, vor dem Update.

Seltsam ist allerdings, dass nach dem Löschen des Jobs inklusive der Sicherung und dem exakt gleichen neu Anlegen mindestens 10 dieser ISOs auch nicht gesichert werden - und der Job dann eben abbricht.

Die exakt gleichen Dateien werden allerdings mit Versionierung lokal nochmal ohne Verschlüsselung problemlos mit HBS3 gesichert.

Ein anderer Punkt, passt aber dazu: Mit ddm Qdedup-Tool für Windows lassen sich aber leider nur schlecht Files wieder finden, es gibt da keine vernünftige Suchfunktion.

Zitat von Anthracite

Entferne mal die Umlaute aus den Verzeichnisnamen. Dann funktioniert es (nehme ich an).

Das kann ich gerne mal probieren. Aber selbst, wenn es denn erfolgreich wäre, ist das nicht die Lösung in meinem Fall. Die Dateien und Verzeichnisse kann ich nicht dauerhaft umbenennen, weil sie teils automatisch generiert werden. Würde ich das vor jedem Backup machen, kann ich auf das automatische Backup gleich komplett verzichten und das per Hand durchführen - ist nicht mein Ziel. Normalerweise halte ich mich auch daran, auf Umlaute und Leerzeichen zu verzichten. Aber unter Windows wird man da eben irgendwann nachlässig (wahrscheinlich genauso unter Linux, wenn man GUIs verwendet, oder am Iphone, das beim Scan schon mal selber Namen generiert).

Und warum wird denn das Verzeichnis mit Umlauten und Leerzeichen richtig im Backup erstellt, sowie auch alle anderen Dateien, die selber sowas enthalten? Und vor dem Update ging es noch? Und andere Backups der gleichen Quelle gehen auch?

Natürlich schließe ich nicht aus, dass Du recht hast und ich probiere es auch gerne mal aus. Muss dann nur verhindern, dass eben das andere parallel stattfindende Backup wiederum Probleme macht in der Zeit.

Ich poste das Ergebnis dann - bitte etwas Geduld.

EDIT: Das war's also wirklich nicht - Nach Umbenennen der Verzeichnisse (genauer gesagt habe ich eine komplett neue Freigabe erstellt und den Inhalt umkopiert, um oben beschriebenes Problem zu vermeiden) ohne Sonder- und Leerzeichen ergibt sich haargenau das gleiche Bild: Nach 10 Fehlermeldungen bei *.ISO-Files wird der Job abgebrochen. Dabei sind aber bereits 115 Dateien mit insgesamt ca 3.4 GB gesichert worden.

Ist doch schon passiert. Ich bin mir recht sicher, es liegt am Update. Entweder ist plötzlich die Dateigröße ein Problem oder aber der Weg über Hybridmount.

Hatte die Hoffnung, jemand hat vielleicht eine ähnliche Konstellation: Backup kleinerer und größerer Files (mehrere 100 MB bis ca 1-2 GB) mit HBS3 auf einen QNAP-Cloud-Speicher.

5 GB haben die Files aber nicht. Trotzdem wird es an der Größe liegen. Sicher ist auch, dass es früher geklappt hat und manuell kopieren auch funktioniert.

Becker2020

Besten Dank! Dann ist es also scheinbar die Verschlüsselung, die diese irreführende Meldung bewirkt. Das erklärt ja dann auchm warum ich die erste problematische Datei manuell durchaus hochladen konnte. Vor dem Update konnte ich dies auch mit beispielsweise 2.5 GB großen verschlüsselten tun.

Ist halt wieder interessant zu erkennen, dass der deutsche Support bei allem Respekt offensichtlich nicht immer mit den anderen Ländern zusammenarbeitet. Mir wurde gesagt, das Problem sei nicht bekannt, im englischsprachigen Forum haben aber User auch von ihren Tickets berichtet.

Aus dem englischen Forum: Ist in HBS 3 V25.0.0529 gefixed. Also: warten auf's Update.

Passt jetzt zwar nicht zum Thema, aber inhaltlich dann doch - also riskier ich mal die Schimpfe vom Mod.

Anthracite

Gerade hatte ich das mit den "Leerzeichen in Filenamen" als Lösung für ein mir unverständliches Phänomen gefunden.

Seit Monaten suche ich ja, welches Programm verursacht. dass mir meinen RAM vollgestopft wird. Dazu habe ich mittlerweile so einige Tools aufgestöbert. Aktuell (nicht zum ersten Mal, stelle ich nach einigem Hantieren damit fest) versuche ichh mich mit dstat. Da gibt es ein Plugin top_mem, das den Prozess mit den höchsten Verbrauch an RAM anzeigt (vereinfacht als Dummie gesprochen). Und da wunderte ich mich, warum das mir dann Plex mit 296G oder gar 550G anzeigt, wo mein Teil doch nuir 64G eingebaut hat.

Nachdem ich mir das Plugin mal angesehen hab, habe ich sogar als Dummie schnell die Lösung gefunden: Das Plugin holt sich die Zahl aus /proc/[pid]/stat aus Spalte 23 (weiß nicht, ob die bei 1 oder 0 anfangen zu zählen - egal). In der zweiten Spalte sollte aber in Klammern der Programmname stehen, und dieser lautet bei Plex eben Plex DLNA Server. Mit den Leerzeichen. Das führt eben dazu, dass der Wert aus der falschen Zeile gegriffen wird - und ich so dstat hierfür vergessen kann. Ok, war sowieso nicht die Lösung. Und wie mir jetzt langsam klar wurde - war es auch nicht, als ich es vor mehreren Monaten schon mal probiert hatte....

Leider ist es immer sehr abhängig, welchen Support-Menschen man antrifft. Oder zum Glück? Manchmal kniet sich einer auch wirklich richtig rein, so wurde ich einmal sogar von einem bei einem Problem angerufen und wir haben recht schnell gemeinsam am Telefon eine Lösung gefunden. Andere geben erst mal nur die Standardantworten und ohne Logfile beispielsweise geht gar nichts.