Geschwindigkeit zwischen 2 HDD

[linuxnutzer]

vermute ich einfach mal, dass es sich hier nicht um ein Windows-System handelt.

Bingo. Ubuntu 24.04 mit XFS-Dateisystem.

Es wurde auch nie defragmentiert.

Die 16TB-Ziel-HDD ist neu und daher nicht fragmentiert.

Die 12TB-HDD ist wohl auch eher wenig fragmentiert. Das sind alles rysnc-Backups. und Defragmentierung würde nur doch Veränderungen wie Löschen entstehen. Gesichert wird meisten nur das, das auch bleibt.

 

[CountSero]

Die 12TB-HDD ist wohl auch eher wenig fragmentiert. Das sind alles rysnc-Backups. und Defragmentierung würde nur doch Veränderungen wie Löschen entstehen. Gesichert wird meisten nur das, das auch bleibt.

Dann gehe vom Overhead von rsync aus und die schiere Masse an Dateien. Würde ich dennoch als normal ansehen, an die 12 TB sind schließlich auch eine Hausnummer.

 

[linuxnutzer]

ssd rein und dann geht die post ab

Und ich darf dir die Rechung für 28TB senden?

Es geht um Dateien, die gesichert werden und nie mehr verändert, zB ein Urlaubsvideo.

Die Migration auf einen neuen PC ist nun zeitaufwendig.

Keine Ahnung, ob cp statt rsync schneller wäre. Mir ist aber wichtig das Dateidatum beizubehalten und das ist mit "rysnc -t" gewährleistet.

Wie viele Jahre sollte eine HDD die Files sicher speichern, wenn sie nicht verändert wird? Insofern ist Umkopieren von Zeit zu Zeit sowieso eine gute Idee.

Dann gehe vom Overhead von rsync aus

Das ist die Frage, ob sich der bemerkbar macht.

top - 19:15:05 up 19:02,  3 users,  load average: 2.12, 2.08, 2.05
Tasks: 512 gesamt,   1 laufend, 511 schlafend,   0 gestoppt,   0 Zombie

%CPU(s):  0.1 us,  0.2 sy,  0.0 ni, 92.2 id,  7.5 wa,  0.0 hi,  0.0 si,  0.0 st

Der PC läuft jetzt 19h mit rsync.

%CPU(s): 0.1
Die CPU langweilt sich.

Ich habe in den 19h ca 6TB übertragen. Da sind natürlich sehr viele kleine Dateien dabei.

 

[CountSero]

%CPU(s): 0.1
Die CPU langweilt sich.

Ich habe in den 19h ca 6TB übertragen. Da sind natürlich sehr viele kleine Dateien dabei.

rsync verarbeitet jede Datei einzeln. Dabei wird zusätzlich ein Abgleich der Metadaten durchgeführt, was jeden Kopiervorgang etwas verlangsamt. Bei vielen kleinen Dateien fällt dieser Overhead besonders stark ins Gewicht.

Außerdem verarbeitet rsync die Dateien rekursiv, also Verzeichnis für Verzeichnis, in der Reihenfolge, wie sie vom Dateisystem übergeben wird. Diese Reihenfolge ist nicht unbedingt alphabetisch oder chronologisch, sondern hängt von der internen Struktur des Dateisystems ab.

Ein Beispiel:

Stell dir vor, du hast ein Verzeichnis, das regelmäßig mit neuen Dateien erweitert wird, und du synchronisierst es immer wieder mit rsync. Die einzelnen Dateien sind zwar nicht fragmentiert, aber die Gesamtheit der Dateien ist es sehr wohl, einfach deshalb, weil sie über längere Zeiträume hinweg auf die Festplatte geschrieben wurden.

Da sich eine Festplatte von außen nach innen füllt, liegen ältere Dateien tendenziell auf den äußeren, schnelleren Spuren, während neuere Dateien weiter innen – also auf langsameren Spuren – gespeichert werden.

Wenn rsync nun Dateien in einer Reihenfolge verarbeitet, bei der ständig zwischen alten (außen) und neuen (innen) Dateien gewechselt wird, führt das zu vielen fragmentierten Zugriffen. Der Lesekopf der Festplatte muss ständig hin- und herbewegt werden > was als „Seek Time“ bezeichnet wird.

In diesem Fall ist also nicht die Rechenleistung der limitierende Faktor, sondern die fragmentierten Dateizugriffe auf der Festplatte. Das ständige Springen zwischen schnellen und langsamen Bereichen der Platte bremst den gesamten Kopiervorgang erheblich aus.

 

[linuxnutzer]

Dabei wird zusätzlich ein Abgleich der Metadaten durchgeführt,

Habe es möglichst gering gehalten:

time rsync -ruvLt --size-only --modify-window=2 --stats --delete --progress --chmod=u=rwX /bak_tmp/bla /bak_intern/

Vortei. von rsync ist ja auch, dass man nicht von vorne anfangen muss, wenn man unterbrechen muss.

Wenn rsync nun Dateien in einer Reihenfolge verarbeitet, bei der ständig zwischen alten (außen) und neuen (innen) Dateien gewechselt wird, führt das zu vielen fragmentierten Zugriffen

Klar, aber ich glaube bei mir hält sich das in Grenzen. Für eine Sicherung ist letztlich alles egal, dauert eben einmalig seine Zeit.

Wie viele Jahre sollte eine HDD die Files sicher speichern, wenn sie nicht verändert wird?

Kann wer dazu was sagen? Alle wieviele Jahre sollte man umkopieren um sicher zu sein?

BTW, bin bei der 16TB jetzt zu 45% voll und die Geschwindigkeit ist gestiegen, bin bei ca. 220 bei den letzten Dateien. Das wird trotzdem noch lange dauern bis ich vom alten PC alles an den richtigen Platz geschoben habe. Lustig wird es dann via Ethernet die Differenz zur Sicherung abzugleichen, ist nicht viel, aber es muss ja erst abgeglichen werden, was nicht verändert ist.

 

[Langi1]

Kann wer dazu was sagen? Alle wieviele Jahre sollte man umkopieren um sicher zu sein?

Würde mich auch interessieren. Aktuell macht das meine DS1522+ alle 3 Monate. Belastet dann die Festplatten und dauert bei meinen 50TB auch schon sehr lange.

 

[linuxnutzer]

Also meine Dateien haben bis zu 5 Jahre überlebt.

 

[Langi1]

@linuxnutzer Was war dann?

 

[linuxnutzer]

Nichts, ich habe einen neuen PC und kopiere alles um. Es gibt auch noch einen Teil der Dateien am PC davor. Ich habe noch nie festgestellt, dass eine Datei nicht lesbar war. Es ist aber schwierig, das zu beurteilen, nur die Datei sehen bedeutet nicht, dass sie ok und unverändert ist.

 

[CountSero]

Klar, aber ich glaube bei mir hält sich das in Grenzen. Für eine Sicherung ist letztlich alles egal, dauert eben einmalig seine

Naja, wenn du regelmäßig dort Backups machst, dann werden vermutlich auch neue Dateien hinzugefügt oder bestehende durch Änderungen ersetzt. Dadurch liegen die Dateien in einem Verzeichnis nicht mehr direkt hintereinander auf der Festplatte.

Das wäre nur dann der Fall, wenn du jedes Mal ein vollständiges Backup machst und dabei alles neu auf die Platte schreibst, dann würden die Dateien wieder physikalisch hintereinander gespeichert.

Aber sobald du in ein bestehendes Verzeichnis neue Dateien hinzufügst, werden diese einfach an freien Stellen auf der Platte geschrieben. Das Dateisystem sortiert die bestehenden Dateien dabei nicht neu oder legt sie zusammenhängend ab. Die Folge: Die Dateien eines Verzeichnisses liegen physikalisch verstreut, was bei Zugriffen zu vielen Kopfbewegungen und damit zu langsamerer Performance führt. Das ist aber normal.

 

[linuxnutzer]

Die Dateien eines Verzeichnisses liegen physikalisch verstreut, was bei Zugriffen zu vielen Kopfbewegungen und damit zu langsamerer Performance führt.

Hast schon recht, aber das sind nur ein paar Prozent, wenn überhaupt. Die Masse ist "nebeneinander".

Wenn ich jetzt gerade von der 12T auf die 16T übertrage, dann läuft das geordnet. Ungeordnet sind zB die Fotos die dazu kommen, aber mit der nächsten HDD wird das wieder geordnet.

Was ich mich gerade frage, die 16TB zeigt geringfügig mehr an vebrauchten Platz an als die 12TB. Da sind aber nur Syncs von der 12TB darauf.

Ausschnitt:

lsblk -o NAME,PHY-SeC

sdb             4096
└─sdb1          4096
sdc             4096
└─sdc1          4096

Beide haben also die gleiche blocksize

 

[Banned]

Also meine Dateien haben bis zu 5 Jahre überlebt.

Überlebt ist relativ. Ob die Daten aber wirklich noch genauso sind wie sie ursprünglich mal auf den Datenträger gekommen sind, weißt du nur, wenn du Prüfsummen (bzw. ein Dateisystem, das damit arbeitet) hast, um gegen zu prüfen.

Ich habe noch nie festgestellt, dass eine Datei nicht lesbar war. Es ist aber schwierig, das zu beurteilen, nur die Datei sehen bedeutet nicht, dass sie ok und unverändert ist.

Genau so sieht es aus.

Alle wieviele Jahre sollte man umkopieren um sicher zu sein?

Da kann man keine generelle Angabe zu machen. Je länger sich die Daten auf dem Medium befinden, desto größer wird die Wahrscheinlichkeit für Bitrot. Aber theoretisch kann das jederzeit passieren. Da spielen neben der Dauer auch Umwelteinflüsse sowie eventuelle Vorschäden der Oberfläche eine Rolle.

Wenn du schon Linux nutzt, warum nutzt du dann nicht einfach ZFS und machst ab und an einen Scrub? So kannst du sehen, wenn sich was verändert hat und dann ein Backup nutzen.

Einfach blind umkopieren in einem gewissen Intervall würde ich nicht empfehlen, weil natürlich auch das wieder nicht risikofrei ist.

 

[linuxnutzer]

Wenn du schon Linux nutzt, warum nutzt du dann nicht einfach ZFS und machst ab und an einen Scrub?

Jetzt hast du mir eine Floh ins Ohr gesetzt ;-) Bis jetzt dachte ich, mein PC ist dazu zu wenig performant und mit Flash-Speicher las ich von Problemen, aber vielleicht ein Versuch mit dem alten PC dann in 2026.04?

Bei ZFS sollte man schon wissen wie man das konfiguriert, da muss ich mich einlesen.

Mit XFS bin ich nach Stromausfällen ganz gut gefahren, besser als mit Ext4. Das ist aber rein gefühlsmäßig und individuell zu sehen. Ich bin jetzt bei /boot und / wieder bei Ext4. In Spezialsituationen kann das besser sein.

Bei ZFS ist das Copyright auch probelmatisch. OpenZFS weiß ich nicht, wie weit das ist.

Einfach blind umkopieren in einem gewissen Intervall würde ich nicht empfehlen, weil natürlich auch das wieder nicht risikofrei ist.

Ja, das sehe ich auch als Problem. Das Problem ist, dass inkrementelle Sicherungen viel Speicher kosten. Ich habe bereits 1 Datei verloren, die nicht mehr lesbar war und defekt gesichert wurde. Gemerkt habe ich das nur zufällig. Uraltes Backup hatte ich rein zufällig, aber man kann ja nie sagen, wenn / wann eine Datei defekt wird, die nur umkopiert wird.

 

[tollertyp]

Also den Effekt verstreuter Dateien würde ich nicht überbewerten...

 

[lazsniper]

@lazsniper Voll am Thema vorbei.

finde ich nicht, der te frägt warum hdd's so langsam sind, hat eine antwort drauf bekommen.

Ergänzung (8. Juli 2025)

Und ich darf dir die Rechung für 28TB senden?

niemand hat behauptet dass ssd's in der größenordnung günstig sind. für langzeit storage sind sie auch nicht empfehlenswert.

 

[Banned]

Bis jetzt dachte ich, mein PC ist dazu zu wenig performant

Du brauchst eigentlich nur einigermaßen RAM. Solange du 16GB hast und deine Gesamtkapazität nicht an die 100TB geht, wird das gut laufen. Okay, bei nem Desktop-PC, wo auch noch andere Dinge mit gemacht werden, würde ich zu 32GB raten.

und mit Flash-Speicher las ich von Problemen,

Davon habe ich wirklich noch nie etwas gehört und das macht auch logisch für mich nicht ansatzweise Sinn.

Mit XFS bin ich nach Stromausfällen ganz gut gefahren, besser als mit Ext4. Das ist aber rein gefühlsmäßig und individuell zu sehen. Ich bin jetzt bei /boot und / wieder bei Ext4. In Spezialsituationen kann das besser sein.

ZFS sichert dir alles bis einschließlich Root (also den kompletten Verzeichnisbaum) mit Prüfsummen ab und diese wiederum nochmals mit Prüfsummen.

Bei ZFS ist das Copyright auch probelmatisch. OpenZFS weiß ich nicht, wie weit das ist.

M.E. ziemlich ausgereift. Das NAS-Betriebssystem TrueNAS Scale verwendet es z.B.

Ergänzung (8. Juli 2025)

Das Problem ist, dass inkrementelle Sicherungen viel Speicher kosten.

Im Vergleich zu einer Gesamtsicherung (welche die bisherige ersetzt), ja. Mit ZFS kann man komfortabel mit Snapshots arbeiten; siehe z.B.:
https://foolcontrol.org/?p=4781

Je nachdem, wie oft du Änderungen vornimmst, könnte man sagen, man macht jedes Jahr oder jedes zweite Jahr ein neues Vollbackup und zwischendurch nutzt man Snapshots.

PS: ZFS reserviert sich immer quasi alles an RAM, was es kriegen kann. Das ist aber kein Problem, weil der auch wieder freigegeben wird für andere Dinge, wenn benötigt. Also nicht wundern, wenn ZFS deinen RAM frisst - das ist normal.

 

[linuxnutzer]

Du brauchst eigentlich nur einigermaßen RAM. Solange du 16GB hast und deine Gesamtkapazität nicht an die 100TB geht, wird das gut laufen.

Jetzt habe ich 64GB RAM und einen Ryzen 9 9900X,

Ich habe mir die Ubuntu-Installation angesehen, da ist (noch) kein ZFS dabei.

 

[Banned]

Ich habe mir die Ubuntu-Installation angesehen, da ist (noch) kein ZFS dabei.

Das ist normal. Torvalds wollte nicht, dass es in den Kernel kommt, weil er wohl Angst hatte vor einer Einflussnahme von Oracle oder so. Bei der Installation von Ubuntu kann man es aber auswählen, soweit ich mich erinnere.

 

[linuxnutzer]

Bei der Installation von Ubuntu kann man es aber auswählen, soweit ich mich erinnere.

Hmmh, kann man ZFS für eine einzelne Partition definieren? Ich habe gelesen, es ist mit Autoinstall möglich. Ich würde mal gerne damit ein wenig spielen, muss nicht alles ZFS sein.

Also ich fand da kein ZFS, wenn ich eine neue Partition bei der Installation anlege.

Zu den Problemen ist https://discourse.ubuntu.com/t/zfs-root-in-24-04/42274 ganz interessant. Da gibt es doch noch rechtliche Probleme.

https://medo64.com/posts/manually-installing-encrypted-zfs-on-ubuntu-24-04/
As before, if you are beginner with ZFS, you might want to use Ubuntu’s built-in ZFS installatiion method. It will result in similar enough setup but without all these manual steps.

Ich finde da nichts.

 

[andy_m4]

Hmmh, kann man ZFS für eine einzelne Partition definieren?

Generell natürlich schon.
Du musst ja einfach nur die ZFS-Tools wie zpool und zfs nutzen.

Da gibt es doch noch rechtliche Probleme.

Ja. Die sind aber anders, als in Diskussionen manchmal dargestellt.
Die CDDL unter der OpenZFS steht ist nämlich eigentlich liberaler als die GPL unter dem im wesentlichen der Linux-Kernel steht.
Die Sorge also, das das böse Oracle (der Rechtsnachfolger des ZFS-Entwicklers Sun Microsystems) kommen und "Linux" verklagen könnte ist aus lizenztechnischer Sicht vollkommen blödsinnig. Wenn dann könnten höchstens die "Linux-Leute" dagegen klagen, wenn jemand OpenZFS und Linux-Code mischt.

Dann wird immer noch geraunt, das OpenZFS möglicherweise Patente enthält, die sozusagen dann im Fall des Falles Probleme bereiten könnte. Ohne aber mal die Patente zu nennen. Mal abgesehen, das man das potentielle Problem bei jedem Code der beigetragen wird, hat.

Insgesamt wirkt das ein bisschen so, als ob paar Linux-Leute ZFS partout nicht im Kernel haben wollen und sich dann fadenscheinige Gründe verbreiten, warum das nicht geht.