Am 28.10.23 um 21:38 schrieb Shinji Ikari:
> Marcel Mueller <
news.5...@spamgourmet.org> schrieb
>> Am 28.10.23 um 14:11 schrieb Shinji Ikari:
>>> Die sehr guenstigen Samsung 4TB und 8TB QVO brechen bei der
>>> sequentiellen Schreibgeschwindigkeit nach dem SLC Bereich auf rund
>>> 150-160MByte/s ein. Das ist weitaus mehr als jede 2,5" SMR HDD mit 4TB
>>> oder 5TB beim Dauerbeschreiben im Endbereich schafft. Selbstz mehr als
>> Ich hatte bei etlichen Modellen Tests gesehen, wo es am Ende einer
>> längeren Schreibphase eher um <50MB/s waren.
>
> Wie gesagt, bei Einzeldateikopien mit vielen kleineren Dateien brechen
> die auch ein, aber nicht so sehr wie 2,5" SMR Festplatten.
> Auch haben die kleineren Modelle, (1TB) um die es hier ja gar nicht
> geht, nur geringere Werte (70-80MByte/s) nach ueberschreiten der SLC
> Grenze, aber ab 2TB bis 8Tb sind 15-160MByte/s normal.
Ich hatte seinerzeit in der 4TB-Klasse gesucht. Ist vllt. ein halbes
Jahr her. Und da hatte ich einige Quellen, wo bei Sustained Write eher
mittlere zweistellige Werte standen. Ich habe mir die genauen Quellen
nicht gemerkt. Könnte Tom's Hardware oder auch c't gewesen sein. Ich
weiß aber auch nicht mehr, welche SSD-Modelle ich genau rausgesucht
hatte, sie waren aber QLC. Ich glaube Samsung war nicht dabei. Da
spielten sicherlich Preis und Verfügbarkeit zu dem Zeitpunkt mit rein.
>> Ich habe kürzlich ein größeres Backup auf IronWolfPro gemacht. Ca. 2 TB
>> und ca. 1 Mio Inodes (Files + Directories). Das hat eigentlich durchweg
>>> 100 MB/s netto geschafft, meist sogar >150 MB/s.
>
>
https://www.file-upload.net/download-15212014/HDDs-14-22TB.ZIP.html
> Hier Screenshots aus meinem Fundus von CMR-Festplatten 14 - 22TB
> Steagate, Toshiba und WD.
> Keine schafft in dem dort erkennbaren hohen Fuellstand sequentiell
>> 130MByte/s.
> Wenn eine halbwegs aktuelle SATA Festplatte mit hoher Kapazitaet mehr
> schafft ist es entweder 10.000PRM, oder ein Cache, der da massiv
> hilft.
Den Füllstand habe ich mit den paar TB, die da drauf sind, natürlich
noch nicht erreicht. Die sind nicht mal halb voll. Kann schon sein, dass
sie bei zukünftigen Backups, nur noch 100 MB/s liefern. Das ist dann
aber nicht mehr so wichtig, da es nur inkrementelle Sicherungen sind
(rsync). Dabei werden passende Dateien aus den alten Backups nur
verlinkt. Das kostet zwar 15 Minuten extra für die Analyse, aber dafür
geht der Rest dann echt fix. Die Restores sind natürlich dann langsam,
weil der Plattenkopf dann wild hin und her springen muss. Ein Desaster
Recovery würde sicherlich einen halben Tag brauchen. Aber die
Beschaffung der neuen Hardware dauert noch länger. ;-)
>> Wenn die wirklich 150MB/s durchhält, ja.
>
> bei mir ja. Und im verbund erhoehen sich die Werte auch.
> 2 Stueck 4TB QVO Raid0 lagen bei mir im hinteren Schreibbereich bei
> rund 240MByte/s (zusammengeschaltet per QNAP-QDA-A2AR mit einem darin
> enthaltenenen JMS562 Chip).
> 3 Stueck im zfs-raid, welcher raid5 entspricht, macht auch rund
> 300MByte/s, aber eben mit einer gewissen Ausfallsicherheit.
RAID ist bei externen USB-Backupplatten irgendwie doof. ;-)
Und alles andere kann man nicht so gut off-site lagern.
>> Im Prinzip kann man es sogar komplett automatisieren, so dass das
>> udev-Event des Ansteckvorgangs das komplette Backup bis hin zum
>> Aushängen automatisiert.
>
> ...solange das Backup/Kopie auf einen ext. Datentareger passt. Beim
> Splitting wird das leider schwierig.
Jein, das hatte ich auch schon mal so ungefähr. Ich habe halt einfach
eine logische Grenze auf Verzeichnisebene eingezogen. Manche
Verzeichnisse landen dann auf Medium 1, andere auf Medium 2. Das geht
natürlich nicht, wenn man noch mehr Datenträger braucht, oder beide bis
zum Limit vollknallen will. Da ich einen Autoloader habe, hätte ich auch
einfach mit Überlauf arbeiten können, aber ich fand es besser, genau zu
wissen, was auf welchem LTO-Tape ist.
In den 90ern, als Backups noch auf MO liefen, hatte ich sogar ein
Programm, dass Backups deterministisch auf beliebig viele Datenträger
verteilen konnte. Es wurde einfach aus dem Dateipfad ein Hash ermittelt
und dem entsprechend der Datenträger gewählt. Wenn man den dann
eingelegt hat, wurden nur die zu diesem passenden Dateien gesichert. Das
Hash-Verfahren war auch schlau genug, dass sich beim Hinzufügen eines
Datenträgers zum Satz keine Daten zwischen den alten Datenträgern
verschoben haben. Dadurch konnte man den (oder die) neuen einfach als
erstes einlegen. Danach wurden bei den anderen Datenträgern die nun dort
nicht mehr benötigten Dateien einfach entfernt, und man hatte zu jeder
Zeit ein vollständiges Backup.
Das Verfahren würde auch automatisiert heute noch funktionieren, wenn
man die Datenträger-ID korrekt berücksichtigt. Man muss halt nur
sicherstellen, dass jeder Datenträger eines Satzes auch wirklich dran
hing und erfolgreich durchgekommen ist. Und wenn man in der Quelle kein
Dateisystem hat, was Snapshots unterstützt, kann das Zeitfenster ein
Problem werden. Wenn man während des Backups eine Datei von einem noch
nicht gelaufenen Datenträger auf einen schon erledigten verschiebt,
fehlt sie am Ende auf beiden. Ähnliche Probleme können einem bei allen
anderen Live-Backups auch passieren, nur ist da das Zeitfenster meist
kleiner.
Glücklicherweise räume ich meine Daten einigermaßen auf, weshalb sie
heute problemlos auf eine Platte passen. Da bleibt sogar noch Platz für
das Backup eines zweiten Haushalts. Wenn man dann die Datenträger
regelmäßig tauscht, hat man auch gleich das Off-Site-Problem gelöst.
Marcel