HBS 3 - Synchronisation mit sehr vielen kleinen Dateien

    • Neu

    Hallo,


    ich habe hier 5 Ordner, die zwischen zwei TS-873A synchronisiert werden.
    Das ganze läuft über Glasfaser und Kabel und ist eigentlich von der Netzwerkgeschwindigkeit vollkommen in Ordnung.
    Problem ist nur, dass ich tausende von extrem kleinen Dateien sichern muss, manche nur wenige Bytes groß, und das ganze sich dann über mehrere Tage hinzieht.
    Es sind insgesamt tatsächlich 14 TB an Daten, aber die meisten ändern sich nicht und sollten daher auch nicht das Problem sein.

    Mir kommt es aber so vor, dass das Abprüfen, ob die Datei gesichert werden muss oder nicht, bei allen Dateien gleich lange dauert.
    Also auch bei einer winzigen Datei dauert das mehrere Sekunden.
    Große Dateien schaufelt er sehr fix rüber, aber der ganze Kleinkram ist echt schwierig.
    Ich habe schon mit Snapshot oder ohne probiert, und auch Komprimierung, aber es gibt da keinen großen Unterschied.
    Wäre ich eventuell mit einem Backup besser dran? Ich brauche eigentlich keine Instanzen, eine aktuelle Kopie der Ordner reicht mir aus.

    Ciao

    AS-N

    • Neu

    Wie sind denn die Job Einstellungen?

    Und wie viele Dateien sind es genau?

  • dr_mike

    Hat den Titel des Themas von „HBS 3 - Synchronisation mit sehr veilen klinen Dateien“ zu „HBS 3 - Synchronisation mit sehr vielen kleinen Dateien“ geändert.
    • Neu

    Vermutlich sind das dann nicht nur tausende kleiner Dateien, sondern millionen. Und das kann dann dauern. Viele Netzwerkprotokolle haben bei einer großen Anzahl von Dateien Performanceprobleme.


    Oftmals ist es deutlich schneller, wenn man nicht viele kleine Dateien einzeln überträgt, sondern diese in ein Zip-File verpackt, das Zip überträgt und auf dem Zielsystem entpackt. Ob das bei dir eine Alternative ist, hängt davon ab, wie deine Dateien organisiert sind (z. B. ob die vielen kleinen Dateien in anderen Verzeichnissen als die Großen sind). Du brauchst dann Skripte zum automatischen Packen und Entpacken. Außerdem wird dann der Speicherplatz doppelt belegt - das willst du bei den großen Dateien lieber nicht haben.


    Eine Alternative ist, zumindest ein Versuch, auf deinem Quell-NAS keinen HBS-Job laufen zu lassen, sondern das Verzeichnis mit den Dateien wird freigegeben. Das Ziel-NAS mountet sich diese Freigabe, und dort läuft dann ein lokaler Backup-Job, der von der gemounteten Freigabe auf eine lokale Platte kopiert. Dann müssen die vielen kleinen Dateien über das Netzwerk nicht geschrieben sondern nur gelesen werden. Ob es etwas bringt, weiß ich nicht.


    Ach ja, noch was, sollte eigentlich vor allen anderen Versuchen gemacht werden: Schau mal nach, ob beim Synchronisierungsauftrag unter Regeln "Dateiinhalte prüfen" angeklickt ist oder nicht. Die Auswirkungen auf die Permormance sind drastisch.

    • Neu

    Also insgesamt sind es tatsächlich ca. 1.500.000 Dateien.
    Das ganze läuft über RTRR.

    Ich probier mal die Version, die Synchronisation vom Ziel-NAS aus zu starten.

    "Dateinhalte prüfen" finde ich im HBS-Job gar nicht, wo soll das stehen?

    Also wenn ich den Quellordner im Ziel-NAS mittels Hybrid-Mount einbinde, kann ich den dann aber im HBS nicht als lokalen Quellordner auswählen.
    Dort gibt es nur die "realen" Ordner zur Auswahl.

    Habe das ganze jetzt aber trotzdem mal probiert, halt von NAS zu NAS, aber eben auf dem Ziel-NAS.

    Einmal editiert, zuletzt von AS-N () aus folgendem Grund: Ein Beitrag von AS-N mit diesem Beitrag zusammengefügt.

    • Neu
    Zitat von AS-N

    Also wenn ich den Quellordner im Ziel-NAS mittels Hybrid-Mount einbinde, kann ich den dann aber im HBS nicht als lokalen Quellordner auswählen.

    Versuch mal, auf dem Ziel-NAS in der Shell mit mount die Freigabe vom Quell-NAS zu mounten, und als Mountpoint nimmst du entweder einen leeren "realen" Ordner (welchen du in HBS zur Auswahl hast) oder einen Unterordner eines solchen "realen" Ordners. Funktioniert es dann?

    • Neu

    Ich habe hier auch 400k die ich mit HBS3 über einen VPN Tunnel mit rund 40ms Antwortzeit übertrage.

    Wird nichts geändert sind das ca. 30 Min für den Durchlauf.


    Aber es hängt halt stark von den Jobeinstellungen ab. Prüfst du hier alle Inhalte, dann wird es extrem lange dauern, da er jedes Bit abgleicht und nicht nur den Datei HASH.

    • Neu

    mount bekomme ich nicht hin, cifs ist nicht auf dem System und per nfs findet er den Ordner nicht in fstab.


    Code
    mount -t nfs 192.168.10.93/cloudberry /share/cloudberrymkn
mount.nfs: permission denied: no match for /share/cloudberrymkn found in /etc/fstab

    den gibt es aber

    Code
    [Administrator@NAS-BE share]$ ls -l
total 4
lrwxrwxrwx  1 admin         administrators   22 2025-02-03 19:16 Backups -> CACHEDEV1_DATA/Backups/
drwxrwxrwx 42 admin         administrators 4096 2025-03-14 12:20 CACHEDEV1_DATA/
lrwxrwxrwx  1 admin         administrators   25 2025-02-03 19:16 cloudberry -> CACHEDEV1_DATA/cloudberry/
drwxr-xr-x  2 Administrator everyone         40 2025-03-14 12:40 cloudberrymkn/

    Ich denke, da muss ich erstmal einen Linuxkurs machen, das ist schon zu lange her.....

    Nun, die Idee, dass der Backupjob auf dem Ziel-NAS läuft, sieht aber gar nicht mal so schlecht aus.

    Er rödelt jetzt seit geraumer Zeit und lädt auch fleißig große Dateien herunter.

    Das ganze aber nur mit 9 MB/s. Eigentlich habe ich 500 MBit im Upload beim Quell-NAS und 1000 MBit bei Ziel-NAS.
    Vielleicht arbeitet er auch die Dateien einfach in einer anderen Reihenfolge ab, dass er hier erst die großen macht, und dann später über den Kleinkram stolpert.
    Jetzt muss ich nur noch herausfinden, warum er so langsam ist.

    Einmal editiert, zuletzt von AS-N () aus folgendem Grund: Ein Beitrag von AS-N mit diesem Beitrag zusammengefügt.

    • Neu
    Zitat von AS-N

    und per nfs findet er den Ordner nicht in fstab.

    Für nfs ist die Syntax anders als für smb. Korrekt ist

    Code
    NAS-Name:/Freigabename /Pfad/zu/Mountpoint nfs  Optionen  0  0

    Beim Mount musst du den Pfad zum Mountpoint als Parameter angeben.

    • Neu

    Ja, das hatte ich schon so probiert:


    Code
    [Administrator@NAS-BE share]$ mount.nfs 192.168.10.93:/share/CACHEDEV1_DATA/cloudberry /share/cloudberrymkn -o rw,soft,intr
mount.nfs: permission denied: no match for /share/cloudberrymkn found in /etc/fstab


    Code
    /share/cloudberrymkn

    hatte ich aber angelegt

    So, er läuft jetzt 15 Stunden, die großen Dateien sind übertragen.

    Das Geschwindigkeitsproblem habe ich auch behoben, irgendeiner meiner Mitarbeiter hat einen switch gebraucht und dann hier ans NAS einen 100 MBit switch gehängt. :(
    Dann lief alles mit ca. 40 MByte/s.

    Jetzt kommen aber die kleinen Dateien und es ist ähnlich wie bisher, eine 70B Datei benötigt ca. 14 Sekunden.
    Die durchschnittliche Gesamtgeschwindigkeit ist nun auf 13 MByte/s gefallen und derzeit werden die kleinen Dateien mit wenigen kB/s geladen.
    Und es sind noch 13.000 Dateien.

    Einmal editiert, zuletzt von AS-N () aus folgendem Grund: Ein Beitrag von AS-N mit diesem Beitrag zusammengefügt.

    • Neu

    Ich sichere auf ein anderes QNAP, da kümmert sich auf der Gegenseite der Serverdienst um das einlesen der HASH Werte der Datein.


    Hängst du eine Netzwerkfreigabe direkt ein, habe ich mit 2 remote FritzBoxen, läuft es wie von dir beschrieben.

    Dort ist kein RTRR oder RSYN Dienst aktiv und mein NAS muss über die WAN Strecke mit Latenz jede Datei selber einlese.

    Das dauert und ist super lahm.


    Du brauchst also entweder dauerhaft Geduld oder aber einen Serverdienst auf der anderen Seite der RSYNC kann.

    • Neu

    Es sind ja bei mir auch zwei QNAP, auch über zwei FritzBoxen und mittels RTRR.

    Was meinst du genau mit "aber einen Serverdienst auf der anderen Seite der RSYNC kann."?
    Meinst du auf den beiden QNAPS ?

    Heureka, es sieht so aus, als wenn es mit RSYNC geht.
    Ich habe jetzt RTRR deaktiviert und das ganze über RSYNC eingerichtet.

    Immer noch vom Ziel-NAS aus und das läuft jetzt wesentlich fixer.

    Ob es einen Unterschied macht, wer den Job ausführt, also das Quell-NAS oder das Ziel-NAS?

    Backup läuft jetzt genau 41 Minuten!
    Ich bin zufrieden. :)

    2 Mal editiert, zuletzt von AS-N () aus folgendem Grund: Ein Beitrag von AS-N mit diesem Beitrag zusammengefügt.