SAS HDD Kaufempfehlung

[Haithabu84]

Hallo,

ich suche für einen neuen Proxmox Backup Server ein paar neue Platten für einen ZFS Pool. SAS 12Gb/s soll verwendet werden und Kapazitäten ab 16Tb aufwärts. Nur CMR-Platten. Budget liegt bei 400€ pro Stück.

Leider findet man zu den aktuell verfügbaren Modellen keine Testwerte oder Erfahrungsberichte, weshalb es bisschen schwierig ist, dort eine Auswahl zu treffen. Nur zu den HC550 von WD hatte ich gelesen, das die ab und zu wohl leise vor sich hinsterben ohne Vorwarnung.

Erste Wahl wäre derzeit Seagate mit der ST18000NM0272:

Seagate Exos X 2X18 18TB, 24/7, 512e/4Kn / 3.5

✔ Preisvergleich für Seagate Exos X 2X18 18TB, 24/7, 512e/4Kn / 3.5" / SAS 12Gb/s ✔ Produktinfo ⇒ Kapazität: 18TB (entspricht ca. 16763.81GiB bzw. 16.37TiB, weiterführende Informationen ) • Formfaktor: 3… ✔ Hard Disk Drives (HDD) ✔ Testberichte ✔ Günstig kaufen

geizhals.de

Ansonsten fand ich diese noch vom Preis-Leistung her interessant:

Toshiba Cloud-Scale Capacity MG10F SFA 22TB, 24/7 ab € 427,00 (2025) | Preisvergleich Geizhals Deutschland

✔ Preisvergleich für Toshiba Cloud-Scale Capacity MG10F SFA 22TB, 24/7 ✔ Produktinfo ⇒ Kapazität: 22TB (entspricht ca. 20489.1GiB bzw. 20.01TiB, weiterführende Informationen ) • Formfaktor: 3.… ✔ Hard Disk Drives (HDD) ✔ Testberichte ✔ Günstig kaufen

geizhals.de

Mir ist schon klar das man zum Thema Haltbarkeit nur schwer eine Aussage treffen kann, aber eventuell hat schon jemand Einsatzerfahrungen gesammelt und kann vielleicht im Zusammenhang mit ZFS vielleicht eine Aussage treffen ob es damit geht oder nicht.

Jemand eine Empfehlung?

Gruß

 

[Haithabu84]

Hab mich für die Seagate Exos X24 mit 16Tb entschieden. Die 2X18 soll nur ein Refresh der veralteten X18 sein und die X24 soweit das neuste was es in diesem Bereich von Seagate gibt.

 

[mkossmann]

Die 2X18 soll nur ein Refresh der veralteten X18 sein

Nein, das ist die Serie mit zwei Aktuatoren

 

[java4ever]

ich suche für einen neuen Proxmox Backup Server ein paar neue Platten für einen ZFS Pool.

Unter der Annahme dass du die Proxmox Backup Server Software meinst (PBS), möchte ich kurz auf die Hardware Anforderungen hinweisen:

Installation — Proxmox Backup 4.0.11-2 documentation

pbs.proxmox.com

Backup storage:
Prefer fast storage that delivers high IOPS for random IO workloads; use only enterprise SSDs for best results.
If HDDs are used: Using a metadata cache is highly recommended, for example, add a ZFS special device mirror.

Hast du schon entsprechende Metadata SSDs?

SAS 12Gb/s soll verwendet werden

Gibt es da einen spezifischen Grund für, außer dass du eben SAS haben willst? bspw. Multipath bzw. redundanter storage head...

 

[Haithabu84]

Unter der Annahme dass du die Proxmox Backup Server Software meinst (PBS), möchte ich kurz auf die Hardware Anforderungen hinweisen:

Installation — Proxmox Backup 4.0.11-2 documentation

pbs.proxmox.com

Hast du schon entsprechende Metadata SSDs?


Gibt es da einen spezifischen Grund für, außer dass du eben SAS haben willst? bspw. Multipath bzw. redundanter storage head...

Das Board hat noch zwei Mal M.2, da könnte man entsprechend NVMe unterbringen. Allerdings halte ich das nicht für notwendig. L2ARC ist weitestgehend unbrauchbar und macht keinen Unterschied in der Performance. Das hat sich die letzten Jahre leider auch nicht verbessert. Besser ist mehr RAM. Wenn man mehr RAM hat, erübrigt sich der L2ARC.

ZIL/SLOG ist desweiteren maximal eine Option wenn man die Metadaten und Sync Writes beschleunigen will. Da kommt es drauf an, ob man ein Raid-z2 oder Raidz-10 verwendet. Aber selbst da sehe ich jetzt nicht die riesigen Probleme. Ich habe bereits eine ähnliche Konstruktion mit Seagate X18 8Tb Platten am Laufen. 6 Platten mit Raid-z2, das schreiben ist absolut nicht das Problem. Eher das lesen, was dem geschuldet ist das nicht genügend RAM (32GB insgesamt, 16Gb ARC) für den ARC bereit steht.

Für Backup-Server sind eigentlich Random Workloads eher ungewöhnlich.

 

[Steggi]

Für Backup-Server sind eigentlich Random Workloads eher ungewöhnlich.

Das würde ich so nicht unterschreiben!

Üblicherweise werden mehrere VMs gleichzeitig gesichert, deren Daten je nach Backupsoftware in verschiedene Files fließen.
Dann machst du ja nicht jeden Tag ein Fullbackup, sondern differentiell, inkrementell oder Reverse-Inkrementell. Hinzukommt, dass irgendwann Backups zusammengeführt werden, sei es sofort, wenn das neueste Backup immer das Full ist und das jeweilige incremental Backup dort reingemerged wird (Reverse-Incremental) oder nach einer gewissen Zeit.
So entstehen nach und nach Lücken im Dateisystem und es fragmentiert. Windows kann das mit der Block-Cloning Funktion von ReFS übrigens auch ganz gut

Von daher ist die Aussage im Handbuch gar nicht mal so ungerechtfertigt. Hängt halt immer vom Workload ab und wie viel Zeit das Backup in Anspruch nehmen darf.
Da du beides nicht angegeben hast, kann ich nur in die Glaskugel schauen.

 

[Luckysh0t]

Für Backup-Server sind eigentlich Random Workloads eher ungewöhnlich.

Der PBS sichert seine Daten in Chunks und nicht die VMs am Stück, ich weiß nicht, ob die nun wirklich sequenziell geschrieben werden oder doch eher random.

 

[Bccc1]

@Haithabu84: Deine Antwort klingt danach, als hättest du java4evers Hinweis auf Metadata SSDs als Cache -> L2ARC/SLOG verstanden. Es geht hier um was anderes: SPECIAL vdevs sind kein Cache, sondern speichern die Metadaten und optional records kleiner als ein definierter Schwellwert. Klara Systems beschreibt das hier finde ich ganz gut. Mir haben special vdevs bisher immer was gebracht, aber mag auch sein das ich bisher nie genug RAM hatte. Und der Vorteil hängt vom Workload ab, für manche Benchmarks macht es kein Unterschied. Im Zusammenspiel mit PBS hab ich da aber keine Erfahrung, mein PBS läuft auf SSDs.

Durch die Art wie PBS die Daten in Chunks abspeichert und dedupliziert würde ich bei einem Verify schon recht viel random read erwarten. Habs aber nie gemessen.

 

[Luckysh0t]

Deine Antwort klingt danach, als hättest du java4evers Hinweis auf Metadata SSDs als Cache -> L2ARC/SLOG verstanden. Es geht hier um was anderes: SPECIAL vdevs speichern nur die Metadaten und optional records kleiner als ein definierter Schwellwert.

Ist mir bekannt. Ich habe java4evers Kommentar für meine Antwort nicht beachtet. Warum auch? Ich beziehe mich ja auf eine bestimmte Aussage von Haithabu84.

Durch die Art wie PBS die Daten in Chunks abspeichert und dedupliziert würde ich bei einem Verify schon recht viel random read erwarten. Habs aber nie getestet

Ohne jetzt die genaue Infrastruktur und weiteren Einstellungen bei dem (kostenlosen) PBS Angebot von tuxis zu kennen. Hier mal ein paar Zahlen für die "verify jobs".

Tuxis: 23m 36s
lokaler PBS: 3m 56s

Mein lokaler PBS ist ein Sync Ziel vom tuxis, daher ist es die gleiche Basis an Backupdaten. Er ist als Paket mit auf dem PVE Host installiert. Das Storage ist somit ein (verschlüsselter) mirror aus zwei nvme SSDs (auf einer PLX Qnap Karte), mit einer Optane als Slog - sync always.

Da ist dann doch ein Unterschied da, ob das für jemanden relevant ist, oder was man für Schlüsse daraus ziehen mag, bleibt jedem überlassen.

 

[Bccc1]

@Luckysh0t: war nicht auf dich bezogen, wir haben in der gleichen Minute gepostet. Ich meinte Haithabu84. Ich bearbeite mein Post ums klarer zu machen.