Ich habe mit "Sync & Backup" ein größeres Backup gemacht. Problem ist, daß eine Datei nicht gesichert wird - egal wie oft die Sicherung anstoße. Die Datei ist 150GiB groß und wird nicht gefiltert (alle Filter aus). K.A. ob es "intern" ein Limit für sehr große Dateien gibt, aber so ist diese App für mich wertlos ![]()
Backup ist nicht vollständig
-
TanDeb05 -
January 6, 2026 at 1:55 AM -
Thread is Resolved
-
-
Wohin sicherst du denn genau und welches Dateisystem verwendet das Ziel? Bei einem externen USB-Datenträger mit FAT32 Dateisystem beträgt die max. Dateigröße z.B. nur 4 GB.
Kannst du die Datei „zu Fuß“, also durch normales kopieren von A nach B ins Ziel bringen?
Steht diesbezüglich irgendwas im Sync & Backup Protokoll?
-
Vom PC (WIN11) aufs NAS (BTRFS)
Warum auch immer hat das die App auf dem NAS diese eine Datei nicht kopiert. Erst, als ich diese umbenannt und das Backup neu angestoßen hab, wurde die Datei kopiert. Total unverständlich, da vor der Umbenennung ein "Ungleichgewicht" herrschte. Warum erkannte die App das nicht?
Hätte ich das Backup auf dem NAS nicht handisch verifiziert, wüsste ich das nichts. Ich werde die Zuverlässigkeit der NAS-App nun eine Weile beobachten müssen -
Ohne dir was zu wollen, aber vermutlich hast du irgendwelche seltsamen Umlaute, Sonderzeichen oder was auch immer verwendet, die evtl. nicht regelkonform sind und daher nicht übertragen wurden. Ich würde daher nicht unbedingt den Fehler der App zuschieben wollen, auch wenn du das so natürlich nicht behauptet hast. Da ich selbst auch Shell-Skripte für Linux schreibe, weiß aus leidlicher Erfahrung, das Umlaute, Sonderzeichen und vor allem Leerzeichen grade in der Stingverarbeitung oft die Hölle ist. Linux protokolliert aber eigentlich jeden Fehler, nur zieht sich UGOS Pro diese Informationen nicht immer aus den Logfiles heran. Ein Blick auf der Kommandozeile im Verzeichnis /var/log könnte evtl. weitere Aufschlüsse geben, falls du dem weiter nach gehen möchtest.
-
Nein, hab ich nicht...
Beim Umbenennen hab ich hinter *.img noch mehrere g´s gehangen (also *.imgggg). Die von dir vermuteten seltsamen Umlaute vor *.imgggg waren also immer noch unverändert daGenauer gesagt heißt die Dateil mit den "seltsamen" Zeichen "160GB.img", die nicht kopiert wurde. Erst als sie "160GB.imgggg" hieß, ging es

Gibts dafür eine plausible Erklärung? Ich habe keine...
-
Über die Gründe zu spekulieren, könnte mühselig werden, daher lass ich es besser. Eine plausible Erklärung habe ich jedenfalls grade nicht zur Hand, nur ein paar Ideen und Ansätze wie Probleme im Dateisystem, Metadaten, Inodes, etc. Aber wie gesagt... lassen wir das.
-
Ich hatte neulich tatsächlich das Sonderzeichen-Problem. Beim Backup auf eine frisch mit exFAT formatierte USB-Platte Fehler im Job-Log, leider ohne ausreichende Details. Auslesen der Protokolldateien wies auf Files mit ungültigen Zeichen hin; daraufhin diese umbenannt -> Backup erfolgreich.
Da waren tatsächlich noch tief in einem Unterverzeichnis alte Mail-Ordner aus dem Linux-Umfeld mit "Re:" und "Fwd:" im Dateinamen. Generell sind in Microsoft-Dateisystemen die Zeichen " * / : < > ? \ | nicht erlaubt.
-
War bei mir wohl ein anderes Problem
-
pzyko Prinzipiell ist wenn man das Dateisystem wechselt immer auf die unterstützten Werte im Dateinamen zu achten. Egal von wo nach wo. Gerade bei Maildateien, wo gerade im Betreff, gerne Sonderzeichen vorkommen, und sich dies dann gerne im Dateinamen wiederspiegelt.
-
Ist zwar ein anderer Fall, aber ich hatte schon eine Situation, die man offensichtlich als "normal" bzw "gleichwertig" ansah
Der Text von zwei Dateien war offensichtlich identisch, aber es gab trotzdem einen Unterschied (ANSI vs UTF 8). Das hat nicht damals wahnsinnig gemacht -
TanDeb05 guter zusätzlicher Punkt! 👍👍👍 UTF-16 etc. also die Zeichencodierung können auch noch wichtig sein.
Participate now!
Join our community with over 10,000 members!
Register yourself now for free to get full access to all content, graphics, downloads and other exclusive features!