Backup ist nicht vollständig

  • 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 X/

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

    FRITZ!Box 5590 Fiber | UniFi Express 7 | 2,5-GBit-LAN & Wi-Fi 7
    DXP2800 - 1TB Crucial P310 NVMe RAID1 - 2TB Crucial MX500 SSD RAID1 - 16 GB Crucial CT16G56C46S5 (5600Mhz)
    DS224+ 3TB WD Red HDD RAID1 18GB Ram | DS124 1TB Samsung 870 EVO SSD
    Linux Mint | Ubuntu-Server | Windows | iOS | iPadOS
    UGREEN.FORUM/Filebase | Synology-forum/Add-ons | GitHub.com/toafez

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

    FRITZ!Box 5590 Fiber | UniFi Express 7 | 2,5-GBit-LAN & Wi-Fi 7
    DXP2800 - 1TB Crucial P310 NVMe RAID1 - 2TB Crucial MX500 SSD RAID1 - 16 GB Crucial CT16G56C46S5 (5600Mhz)
    DS224+ 3TB WD Red HDD RAID1 18GB Ram | DS124 1TB Samsung 870 EVO SSD
    Linux Mint | Ubuntu-Server | Windows | iOS | iPadOS
    UGREEN.FORUM/Filebase | Synology-forum/Add-ons | GitHub.com/toafez

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

    Genauer gesagt heißt die Dateil mit den "seltsamen" Zeichen "160GB.img", die nicht kopiert wurde. Erst als sie "160GB.imgggg" hieß, ging es 8o

    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.

    FRITZ!Box 5590 Fiber | UniFi Express 7 | 2,5-GBit-LAN & Wi-Fi 7
    DXP2800 - 1TB Crucial P310 NVMe RAID1 - 2TB Crucial MX500 SSD RAID1 - 16 GB Crucial CT16G56C46S5 (5600Mhz)
    DS224+ 3TB WD Red HDD RAID1 18GB Ram | DS124 1TB Samsung 870 EVO SSD
    Linux Mint | Ubuntu-Server | Windows | iOS | iPadOS
    UGREEN.FORUM/Filebase | Synology-forum/Add-ons | GitHub.com/toafez

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

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

    NAS: mehrere DXP-4800+ mit Raid 5, 4 Toshiba 22 TB (Btrfs) und Raid 1, 2 Samsung 990 Pro 4 TB (Btrfs), 64 GB RAM

    Clients/Server: Linux Mint 22.3, MX-Linux, Debian Trixie.

  • 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

    Edited once, last by TanDeb05 (January 13, 2026 at 10:23 PM).

  • TanDeb05 guter zusätzlicher Punkt! 👍👍👍 UTF-16 etc. also die Zeichencodierung können auch noch wichtig sein.

    NAS: mehrere DXP-4800+ mit Raid 5, 4 Toshiba 22 TB (Btrfs) und Raid 1, 2 Samsung 990 Pro 4 TB (Btrfs), 64 GB RAM

    Clients/Server: Linux Mint 22.3, MX-Linux, Debian Trixie.

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!