HBS3 Version: 24.1.0529 .VersionRecycle schreibt komplette HDD voll

    Hallo zusammen,


    ich nutze QNAP schon relativ lange und auch das Backup davon schon einige Jahre - problemlos.


    Jetzt ist es nur allerdings so, dass das Backup vollläuft bzw eben die Target HDD, weil der Ordner .VersionRecycle bei einem neuen Start des Backuptasks mit einer Kopie aller vorhandenen Daten gefüllt wird.

    Ich habe mich auch an den QNAP Support gewandt. Der Support von QNAP will mir aber erzählen, dass aufgrund meines beigefügten Screenshots die Versionierung 7x komplett alle Daten auf meine HDD schreiben soll. Ich vermute mal, dass die Versionierung mit einer inkrementellen Sicherung einfach mit Deltas abgleicht wie bisher auch. Ich habe den Screenshot mal angehangen.


    Unabhängig davon wüsste ich nur gerne, ob mir jemand bei der Lösung helfen kann. Der Ordner befüllt sich leider immer wieder, auch wenn ich ihn lösche. Und da das Backup 15TB Daten enthält und ich eher ungerne den Lösungsansatz "ich lösche mal alles, dann gehts wieder" verwenden würde, hatte ich auf Hilfe der Community gehofft.

  • glasoline

    Hat den Titel des Themas von „HBS3 Version: 24.1.0529 .VersionRecylce schreibt komplette HDD voll“ zu „HBS3 Version: 24.1.0529 .VersionRecycle schreibt komplette HDD voll“ geändert.

    Hallo,


    kann ich nicht nachvollziehen. :/

    Meine ext. Datenträger sind aber auch alle mit NTFS formatiert.

    Wie sind die Einstellungen des Auftrags. :/

    Bei meinen Aufträgen schließe ich temp-Dateien aus.


    pasted-from-clipboard.png


    Zitat von glasoline

    Der Support von QNAP will mir aber erzählen, dass aufgrund meines beigefügten Screenshots die Versionierung 7x komplett alle Daten auf meine HDD schreiben soll.

    Kann ich fast nicht glauben. :huh:

    Bei meine Backups werden nur neue/geänderte Dateien dem Backup hinzugefügt. :)

    Die Verwendung des Verzeichnisses .VersionRecycle ist neu oder hat sich geändert, und an dieser Stelle ist HBS ziemlich bogus. Manchmal scheitert das Backup daran, dass dieses Verzeichnis nicht angelegt wird (da gibt es einen peinlichen Workaround dazu). Bei mir ist das Backup extrem langsam geworden.


    Geh auf HBS Version 24.0.0304 oder älter zurück. Jene Version hat diese Probleme noch nicht. (Aber nimm unter gar keinen Umständen eine der Versionen dazwischen. Da gibt es eine mit einem bösen Fehler, der dir u. U. die zu sichernden Quelldaten löschen kann.)

    Hm, ok danke schonmal für den Ratschlag.

    Würde ich auch gerne testen, aber ich kann leider nach etwas Recherche im Netz keine älteren Versionen finden zum download. Zumindest nicht von vertrauenswürdigen Quellen. Liegen die älteren Dateien noch irgendwo auf der NAS oder bin ich einfach nur blind?

    Du musst den Downloadlink anpassen sodass Version und Build stimmen...

    Danke. Der Task läuft gerade und der Ordner wurde zumindest bisher nicht erstellt. Glaube es sieht ganz gut aus.


    Ich kann halt immer noch nicht die inkompetente Antwort des Supports fassen. Und dafür habe ich 3 Tage lang Screenshots und Logfiles geschickt.

    Vielleicht gehört das nicht hier hin, dann bitte einfach ignorieren:

    Ist das bei Synology auch so? Also vom Support und der Qualität der Updates und der Kommunikation?


    Ich arbeite seit Ewigkeiten in der IT und habe einfach keine Lust mich in meiner Freizeit mit so einem Mist zu befassen. Da hätte ich mir auch selbst was zusammenbasteln können.


    Kleiner Nachtrag: Diesen Syncordner gelöscht, Job neu gestartet mit empfohlener Version: Das Backup war nach abschicken meines Beitrags erfolgreich. Vielen, vielen Dank nochmal!

    Zitat von Anthracite

    Die Verwendung des Verzeichnisses .VersionRecycle ist neu oder hat sich geändert,


    Zitat von glasoline

    Diesen Syncordner gelöscht, Job neu gestartet mit empfohlener Version:


    Wo soll sich dieses Verzeichnis denn befinden ? :/


    Weder im Verzeichnis von HBS3 noch auf dem ext. Datenträger finde ich dieses Verzeichnis :/

    Im Basisverzeichnis des Backups, in dem auch die ganzen Versionen und latest (das letzte Backup) liegen. In meinem Falle (Backup auf externe USB-Festplatte) ist das /share/external/DEV3304_1/mein-Backup/.

    Auf meinem ext. Datenträger (NTFS) gibt es dieses Verzeichnis nicht.


    /share/external/DEV3302_1/Backup/


    pasted-from-clipboard.png

    pasted-from-clipboard.png


    Ist dein ext. Datenträger mit ext4 formatiert :?:



    Nachtrag:

    Wenn die Sicherung bei 100% steht, füllt sich der ext. Datentäger kurzfristig

    HBS3_2024_3.JPG


    Wenn die Sicherung fertig ist, wird dieser Speicherplatz aber wieder freigegeben

    HBS3_2024_4.JPG


    Ein Verzeichnis .VersionRecycle ist aber auch während der Sicherung nicht auf dem ext. Datenträger zu finden.

    2 Mal editiert, zuletzt von Becker2020 () aus folgendem Grund: Nachtrag + Rechtschreibung

    Vielen Dank für den Thread, hat mir viel Zeit gespart.


    Nach dem FW-Update und dem Update von HBS3 auf 24.1.0529 brachen bei mir zwei Backups ab :/ . Irgendwann stellte ich fest, dass die USB-Platte (4TB) noch 400k frei hatte 8| . Bis zu den Updates ist alles prima gelaufen. Habe dann nach diversen Recherchen dieses Thread gefunden und bin den Empfehlungen gefolgt.


    Nach Installation / Downgrade von HBS3 auf v24.0.0304 und dem Löschen des Verzeichnis .../.VersionRecycle lief die erste Sicherung wieder fehlerfrei durch, die zweite läuft noch.


    Ich nutze das TS-453BU seit vielen Jahren, so etwas hatte ich bei den Updates des NAS (Firmware und Apps) bisher noch nicht erlebt. Ich hoffe, dass es dabei bleibt... ;)

    Freut mich, dass dir da kurzfristig geholfen werden konnte. Ich hatte im Vorfeld schon im Internet gesucht gehabt und leider nichts gefunden.


    Dem QNAP Support-Mitarbeiter habe ich gesagt, dass er das Ticket bitte einfach eskalieren soll, wenn er nicht weiß wovon er spricht. Hatte damit gerechnet nichts mehr zu hören, oder dass das einfach zugemacht wird, aber ich bekam heute die Nachricht, dass das Ticket eskaliert wurde. Ich sag' euch dann noch was dabei rauskam.

    Jetzt behaupte ich mal, das Problem tritt nur mit ext. Datenträgern die mit ext4 formatiert sind auf. :(


    Bei NTFS-Datenträger gibt es dieses Problem nicht. :)


    Nachtrag:

    Ich hatte bisher nur bei meinen TS-264 mit QTS 5.2.0.2782 RC Beta nachgeschaut. Hier gibt es diesen Ordner nicht.

    Kann aber auch daran liegen, dass bei diesem neuen NAS erst mit HBS 24.1.xxxx das erste Backup erstellt wurde. :/

    HBS3 Version 24.0.0304 war hier nie installiert. :/



    Bei meinen anderen NAS gibt es diesen Ordner .VersionRecycle doch. :huh:

    Der Ordner wurde aber am 18.03.2024 mit HBS3 Version 24.0.0304 erstellt. :/

    Bisher gab es aber noch kein Problem beim Backup

    Kann aber auch daran liegen, dass die Versionierung nicht bei allen Sicherung genutzt wird.


    Muss ich mir aber noch genauer ansehen.


    Nachtrag 2:

    Da ich 5 Versionen beibehalte, schiebt HBS3 24.1.0529 die 6-te Sicherung in den Ordner .VersionRecycle. :(

    Da diese Sicherungen aber scheinbar nicht gelöscht werden, füllt sich langsam der Sicherungsdatenträger. :(

    Ob der Fehler schon vor HBS3 24.1.0529 auftritt kann ich nicht mehr feststellen. :/

    Zukünftig muss ich den Speicherplatz auf dem ext. Datenträger bei/nach jeder Sicherung überwachen. :(


    Nachtrag 3:

    Gerade bei meinem TS-251D mit QTS 4.5.4xx und HBS3 24.1.0529 getestet.

    Der Ordner .VersionRecycle wird während der Sicherung kurzzeitig angelegt. Wenn die Sicherung aber beendet wurde, wird der Ordner wieder gelöscht. :)


    Zusammenfassung:

    - QTS 5.2.xxx und HBS3 24.1.0529 -> kein Problem :thumbup:

    - QTS 4.5.xxx und HBS3 24.1.0529 -> kein Problem :thumbup:

    - QTS 5.1.7.xxx und HBS3 24.1.0529 -> Fehler tritt auf  :thumbdown:


    Nachtrag 4:

    Die Unterordner im Ordner .VersionRecycle haben alle das gleiche Datum 14.09.2023 :/

    pasted-from-clipboard.png


    Am 01.09.2023 habe ich QTS 5.1.1.2491 installiert. :/


    Nachtrag 5:

    Radikale Lösung für das TS-364 mit QTS 5.1.7.xxx

    Der ext-Datenträger wurde neu formatiert.

    Die Sicherungsaufträge wurden ohne Versionierung neu angelegt. :)

    -> Problem gelöst. ;)

    -> mit einer neuen HBS3-Version oder nach dem Update auf QTS 5.2.xx kann ich dann wieder neue Aufträge mit Versionierung anlegen. :/

    11 Mal editiert, zuletzt von Becker2020 ()

    Das ist ja schlecht!


    Ich will weder auf QTS 4.5.xxx zurueck, noch auf das BETA QTS 5.2.xxx und eine komplette Formatierung das BackUp-Mediums ist fuer mich auch sinnfrei.

    Wer weiss denn schon, wie es in der Hinsicht weitergeht?

    Es kann ja nicht angehen, dass man immer mal wieder sein komplettes BackUp loescht.

    Beim BackUp schreiben werden die Platten extrem belastet.

    Da kann es dann schon einmal zu einem Ausfall kommen.

    Bei RAID5 ist das ein "Tanz auf dem Drahtseil".

    Falls 2 Platten ausfallen, hat sich das Thema BackUp endgueltig erledigt und alle Daten sind im Nirwana.

    Ist nicht das einzige Backup, somit gibt es doch das Löschen kein besonderes Risiko.

    OK, hängt auch von der Datenmenge ab.

    Bei 24 TB wie bei mir sieht das dann schon anders aus …

    Das Problem kommt mit irgendwie bekannt vor. Seit dem Update auf 24.0.0304 war unser Cloud Speicher, in den die Backups laufen (ohne Versionierung) plötzlich voll. Der Hacken "Dateien im Zielordner löschen" war raus, lies sich zwar wieder setzen, aber nicht speichern, auch nicht bei anlegen eines neuen Backupauftrages. Es wurde nur dazu gespeichert und nichts mehr gelöscht. Bei den neuen Aufträgen war Versionierung vorgegeben, man muss sie ausschalten wenn man es nicht wollte. Zurück auf 23.1.1116 und das Problem war gelöst.

    Ich glaube auch, dass die Version 23.1.1116 die letzte fehlerfreie Version für alle Nutzer war. :)


    Das Problem ist, wer überprüft ständig die Backups. :/


    Ohne den Post, hätte ich gar nicht bemerkt, dass die Festplatte langsam "vollläuft". Hätte zwar noch einige Zeit gedauert, aber in einigen Wochen wäre die HDD voll gewesen. Dann hätte ich den Fehler vermutlich erst bemerkt. Bei den "großen" Backups nutzte ich keine Versionierung, sonst wäre mir der Fehler schon eher aufgefallen.


    Diesmal ist es sogar so, dass der Fehler nur bei einem von 3 NAS auftritt. :huh:

    Zitat von Becker2020

    Das Problem ist, wer überprüft ständig die Backups. :/

    Ständig nicht, aber trotzdem mache ich das immer wieder...

    Die Dateien selbst schaue ich mir dabei aber nicht an, sondern

    1. Ob die Jobs auch wirklich starten

    2. Ob die Dauer und übertragene Größe plausibel ist

    3. Ob die Kapa am Ziel noch ausreichend ist

    4. Allgemein ob es Auffälligkeiten gibt


    Bei insgesamt (momentan noch) 6 vollständigen Backups kann ich es mir aber auch erlauben das ein oder andere Backup für einige Wochen mal nicht geprüft zu haben...

    Nein das war HybridBackup_22.1.0717, weil dann Privilegien Eskalation vorgebaut wurde indem man nur noch mit root rechten zugriffe hat.


    Lol, geil, dann brauche ich nix eskalieren und gebe einfach rm -rf /* ein und habe ein sauberes Backupziel...