[Sammelthread] 10Gbit Homenetzwerk

[Zeitmangel]

Das sind tp-link Module und die zeigen weniger als das AOC?

 

[butcher1de]

?

 

[Zeitmangel]

ja schon gut

 

[Dwayne_Johnson]

Gibt es eine Standalone-App, in das man viele, winzige Files schiebt, die von der App automatisch gepackt werden, bevor ich die Pakete übers Netzwerk schicke? Oder ist selbstprogrammieren angesagt?

Und ab welcher Filegröße habt ihr noch 10G? (kann es gerade nicht testen)

 

[Rarity]

rsync mit schalter -z (für compress transfer) , gab es unter Linux denke ich schon seit 1998.
ab rsync 3.1 (2014 ?) kam dann der schalter compress-choice=(...) hinzu mit options: lz4 , zstd , zlibx

z.B: rsync -a --compress --compress-choice=zstd source/ user@host:/destination/

(Solche Tools sind u.a. der Grund warum Linux ein so gutes Arbeitspferd ist ... und es unter Win seit einiger Zeit sogar ein WSL gibt.)

 

[Weltherrscher]

tar.

 

[pwnbert]

Ja, .tar / Tarball könnte sein, was du suchst.

Beim Compress ist meiner bescheidenen Meinung nach LZ4 mit Abstand das beste/sinnvollste hinsichtlich Rechenleistungsbelastung. Gut komprimierbares Zeug wird damit annähernd so gut komprimiert wie mit zstd, schlecht komprimierbares Zeug wird mit zstd auch nicht wirklich besser. zstd tät ich nur nehmen, wenn die Leitung echt lahm ist und die Rechenleistung nicht das Thema ist.
Im Heimnetz oder mit einem zeitgemäßen Internetanschluss (nunja, wer hat das schon in AT/DE) dann eher LZ4.

Und ja, ich hab Folder mit viel Kleinscheiß drin fürs Langzeitbackup auch geTARt, weil SMB sonst eeeewig und 3 Tage gebraucht hätte.

 

[Weltherrscher]

@Dwayne_Johnson:
Eventuell brauchen wir mehr Randbedingungen.
Willst du die Datentransfers lokal machen (NAS<>Desktop), über welches Protokoll??
Da wüsste ich nix automatisches außer rsync.
smb und nfs weiß ich nicht und iscsi ist ja eh blockorientiert.

Normale Kopieraktionen von den Filemanagern komprimieren da auch nix, müsste ja auf der Gegenseite was geben, welches das wieder entpackt...

 

[Dwayne_Johnson]

Von PC zu NAS über smb
Noch schlimmer sind viele, winzige Files vom NAS zur Cloud (dauert ewig)

 

[Weltherrscher]

Pro-Tipp: für ne CI/CD Pipe solltest du dir was sinnvolleres als die Wolke und SMB suchen.

Ansonsten:
SMB kann doch multi-path, eventuell gehts da bissi fixer, aber da glaube ich nicht dran.
Jedoch bin ich nicht so der SMB-Crack...

NFS ist keine Option?
Ansonsten hilft bei Source-Code wirklich nur ein manuelles tar.{b|g|x}z, dann wirds auch relativ fix beim übertragen.

Ich persönlich versuche viele kleine Dateien zu meiden wie die Pest, z.B. Replays, Configs oder Session Backups von den Browsern, die packe ich immer manuell in ein 7z...
Für Quellcode hab ich ne Forgejo-Instanz mit dem Runner, git packt ja vor der Übertragung auch alles in ein Archiv, das lüppt prima.

 

[Dwayne_Johnson]

Normale Kopieraktionen von den Filemanagern komprimieren da auch nix, müsste ja auf der Gegenseite was geben, welches das wieder entpackt...

In manchen Fällen bräuchte ich etwas, dass viele, winzige Files automatisch packt und im Ziel gepackt bleibt (zb für die Cloud

Pro-Tipp: für ne CI/CD Pipe solltest du dir was sinnvolleres als die Wolke und SMB suchen.

K.A. was damit gemeint ist - bin kein Network-Pro

Ich persönlich versuche viele kleine Dateien zu meiden wie die Pest, z.B. Replays, Configs oder Session Backups von den Browsern, die packe ich immer manuell in ein 7z...

Lässt sich bei lokalen iTunes-Backups nicht vermeiden. Das hier ist nur ein kleiner Bruchteil von iTunes-Backups

 

[bowman68]

Lässt sich bei lokalen iTunes-Backups nicht vermeiden. Das hier ist nur ein kleiner Bruchteil von iTunes-Backups

...ich würde mir sowas ja nicht antun: NAS bauen, Jellyfin drauf und dann BorgBackup auf eine reingemountete grosse USB-Platte, feddich. Selbst auf Cloudspeicher (z.B.Hetzner Strorage Box) gehen Backups von Volumes mit hunderten Gigabytes innerhalb von wenigen Sekunden, wenn nur die täglichen Änderungen übertragen werden. Ansonsten gibt es auch tolle Skripte für inkrementelle Backups per rsync: Meine ca. 4 TB grosse Mediensammlung braucht damit ca. 20 Minuten für das inkrementelle Backup auf eine USB-Platte...

 

[Dwayne_Johnson]

Inkrementelle iTunes-Backups habe ich auch...
Ich muss mir noch angewöhnen, in engeren Zyklen zu sichern, damit sich Änderungen zu keinem großen Batzen von 100G und mehr anstauen

 

[Weltherrscher]

In manchen Fällen bräuchte ich etwas, dass viele, winzige Files automatisch packt und im Ziel gepackt bleibt (zb für die Cloud
K.A. was damit gemeint ist - bin kein Network-Pro
Lässt sich bei lokalen iTunes-Backups nicht vermeiden. Das hier ist nur ein kleiner Bruchteil von iTunes-Backups

Ich fühle mit dir.
Aber da ich seit Jahren nur inkrementelle Backups einmal die Woche mache, sind das immer nur so 10..15 GB an Änderungen...
Früher(tm) mit Duplicati und DejaDup, heuer mit der eingebauten KDE Sicherung...

CI/CD: Continuous Integration / Continuous Deployment -> Wenn ich eins meiner Git-Repos aktualisiere, rödelt die Pipeline den ganzen Kram einmal durch und am Ende habe ich das Ergebnis auf dem Server.
Da fliegen auch Millionen klitzekleiner Files durch die Gegend...

 

[Rarity]

Ich kenne leider itunes-backup zuwenig, anhand Deiner Angaben vermute ich, das es einen Korpus aus vielen, vorkomprimierten Dateien hat (zumeist 1 Datei in 1 Datei komprimiert).
Weiters vermute ich, dass Du primär ein schnelles, komfortables Backup möchtest, wobei benötigter Speicherplatz eher sekundäre Rolle spielt.

Mit Archivern (tar, zip, rar, ...) hätte man zwar eine nette Verwaltungsgröße von 1 Datei (alles in 1 Datei zusammengerollt), jedoch müsste dadurch jedes mal die gesamte Datenmenge komplett neu übertragen und gelagert werden (= Zeit+Platz intensiv).
Etaige NAS Dateisystem-Features wie de-duplikation laufen hier ins leere (Daten nur um >= 1 Byte verschoben --> Filesystem-Datenblock hat andere CRC-Checksum)

(Gedankenspiel)
Riesige Dateianzahl akzeptieren und beibehalten, NAS Filesystem wäre ein ZFS dataset mit ausgeschalteter komprimierung, recordsize=16k (niedriger Wert bzw. optimierter Wert anhand Korpus) , User macht inkrementelle Spiegelungen (rsync oder Programm mit ähnlichen Funktionen) aufs NAS in 1 Verzeichnis, Dateien gleichen Namens,Dateigröße,Änderungsdatum werden als ident angesehen und für Übertragung übersprungen, mit ZFS-Snapshots (für Versionsverwaltung).
Dann würde beim Backup aufs NAS nur mehr die Differenz (=geänderte Dateien) übertragen, und ab ZFS-Snapshot auch nur mehr die (neuen) Änderungen ggü. Vorversion gespeichert. De-Deplizierung wäre sogar auch noch möglich (ich persönlich verwende de-dup nicht, da zu RAM-intensiv, dafür aber immer zfs-dataset mit eingeschalteter Kompression.)

z.B: rsync -a --dry-run --delete --info=progress2 /sourcepfad/zum/iTunesBackup/ /mnt/nas/iTunesBackup/
der Schalter "--dry-run" macht dies zum Test-Lauf, ohne Daten zu verändern (nur zum austesten verwenden).

 

[gea]

Tools die auf Dateivergleich basieren, sind im Terabyte Bereich mit sehr vielen kleinen Dateien suboptimal.
Für das Backup sind eigentlich nur zwei Optionen schnell:

1. ZFS Replikation. Das arbeitet nicht mit Dateien sondern einem Datenstrom geänderter ZFS Datenblöcke seit dem letzten Snap. Damit läßt sich sogar der Maílserver einer großen Universität mit 10k User unter Volllast alle 10 Min mit einem Backup syncronisieren, inkl. offener Dateien im letzten Stand, z.B. mein gepuffertes napp-it cs-stream

2. Eventgesteuertes Sync. Das überwacht einen Ordner mit Unterordnern auf Änderungen und kopiert neue/geänderte Dateien in Echzeit auf ein Backup, z.B. Syncthing oder mein einfacheres napp-it cs-sync. Bei extrem vielen Dateien/Ordnern muss man testen ob der RAM dafür reicht.

3. Für reines file sync sind rsync, rclone oder robocopy da. Für rclone + Puffer für bessere Performance auch bei kleinen Dateien kann man mein cs-stream für rclone nehmen.

Die cs-tools sind Teil meiner web-gui, laufen aber auch standalone auf 8 OS Varianten inkl. Free-BSD, Linux, MacOS, Solaris und Windows.

CS-Tools & Scripts — napp-it

 

[pwnbert]

Welchen Kernel hast du den da am Start?

Linux 7.2 To Support Realtek RTL8159 10GbE USB Ethernet - Phoronix

www.phoronix.com

"The RTL8159 requires firmware for the PHY in order to achieve a 10GBit link speed. Without firmware, only 5GBit were achieved. The firmware can be extracted from the out-of-tree r8152 driver-code where it is stored in the ram17 u8-array. Code is added to use the existing firmware upload mechanism of the driver for the RTL8157/9 PHY firmware code. The firmware will be submitted separately to linux-firmware."

Meh, hab jetzt mal einige Stunden damit verbracht, offenbar geht das erst mit Kernel 7.2 ... wann Porxmox den wohl bekommen wird?
Könnte die NIC natürlich auch der TrueNAS VM geben, dort hätte ich dann überhaupt noch Kernel 6.. lol.

 

[Weltherrscher]

Nehm lieber gleich den DKMS-Treiber.
7.2 macht seit 7.2.3 Stress bei iSCSI unter Arch-Kerneln (getestet mit Cachy znver4 und Manjaro)...
Auf beiden Karten (8125 RJ45 und 8127a SFP+).

 

[pwnbert]

Nehm lieber gleich den DKMS-Treiber.

Geht aber trotzdem nicht, ober ich hab was falsch gemacht...

 

[Weltherrscher]

Du nimmst DEN Treiber?

Realtek

www.realtek.com

Welchen Treiber nutzt die Karte jetzt?
Eventuell musst du den blacklisten, damit der Kernel den OOT-Treiber nutzt...

 

[pwnbert]

Eigentlich schon.
Hast dus selbst laufen oder ist das Vermutung?
Ich glaube irgendwie, dass das trotz dem Treiber erst mit Kernel 7.2 auf 10G läuft.. aber vllt. irre ich mich?
Der Phy läuft auf 10G, allerdings der USB nicht, der verbindet nur mit 5G USB. Kabel und Port ist auszuschließen, theoretisch kann er 10G, aber beim Verhandeln der Verbindung kommt 5G raus.