Seagate Archive HDD 8 TB brauchbar?

  • Mein Serienfestplatte ist mal wieder fast voll. Eine größere muss her...
    Nun bin ich auf die "Seagate Archive HDD 8 TB" gestoßen. Bisher habe ich eine 3tb WD red genutzt und sie bei nichtgebrauch schlafen gelegt.
    Da sie nur drei, vier mal pro Woche benötigt wird, hat sie das auch gut verarbeitet.
    Kann ich das mit der Seagate auch machen?
    Hat sie jemand im Einsatz?
    Ich schreibe eigentlich nur immer ganze Staffeln auf die Serienfestplatte. Dafür sollte die Archive hdd doch ausgelegt sein?


    Gruß Jan

    1:Dell PoweEdge T20; Xeon E3-1225 v3; 32GB RAM; Proxmox 5.4; MLD 5.4 als VDR-Server; 2 x Cine S2;
    2:Intel NUC i3 Passiv; 4GB RAM; 120GB SSD; easyvdr 3.5 als client; Harmony Hub

    2:Intel NUC i5 Passiv; 4GB RAM; 120GB SSD; easyvdr 3.5 als client; Harmony Hub
    3:Raspberry Pi 3B; MLD

  • Nun bin ich auf die "Seagate Archive HDD 8 TB" gestoßen. Bisher habe ich eine 3tb WD red genutzt und sie bei nichtgebrauch schlafen gelegt.
    Da sie nur drei, vier mal pro Woche benötigt wird, hat sie das auch gut verarbeitet.

    Bei drei, vier mal pro Woche würde ich mir keine Gedanken machen.
    Bei drei, vier mal pro Tag auch noch nicht.


    Bei drei, vier mal pro Stunde aber schon :schiel .

    Gruss
    SHF


  • Client 1 Hardware : MSI Z87-G43, I5-4570, 4 GB Ram (oversized aber war über :) ),Zotac NVidia GT630 (25 Watt),Thermaltake DH202 mit iMon-LCD ( 0038 ) und vdr-plugin-imon
    Software : yaVDR 0.6,sofhhddevice @ 1920x1080@50Hz
    Server Hardware : MSI Z87-G43, I7-4790, 16 GB RAM, 5x3 TB WD Red, Digibit-R1 (2 Devices)
    Software : Ubuntu 16.04 LTS mit yavdr-Paketen,virtualbox,diverse VM's


    Yoda: Dunkel die andere Seite ist...sehr dunkel!
    Obi-Wan: Mecker nicht, sondern iss endlich dein Toast ...

  • Nachdem ich google mal zu der Platte befragt habe, habe ich mich dagegen entschieden.
    Man findet viele ungeklärte Ausfälle und auch, wenn die Platten anstandslos ausgetauscht werden, ist mir meine Zeit dafür zu schade. Mal eben 4 oder 5 TB an Daten zu übertragen dauert seine Zeit.
    Ich werde erst mal noch ne 4 TB WD red dazupacken.
    Gruß Jan

    1:Dell PoweEdge T20; Xeon E3-1225 v3; 32GB RAM; Proxmox 5.4; MLD 5.4 als VDR-Server; 2 x Cine S2;
    2:Intel NUC i3 Passiv; 4GB RAM; 120GB SSD; easyvdr 3.5 als client; Harmony Hub

    2:Intel NUC i5 Passiv; 4GB RAM; 120GB SSD; easyvdr 3.5 als client; Harmony Hub
    3:Raspberry Pi 3B; MLD

  • Oder 70 Euro für ne richtige Platte draufpacken...
    Aber ich sehs auch so wie du: wenn die Platte im Eimer ist sind erstmal 8 TB weg...


    Gruß


    G3joker

    Client 1 Hardware : MSI Z87-G43, I5-4570, 4 GB Ram (oversized aber war über :) ),Zotac NVidia GT630 (25 Watt),Thermaltake DH202 mit iMon-LCD ( 0038 ) und vdr-plugin-imon
    Software : yaVDR 0.6,sofhhddevice @ 1920x1080@50Hz
    Server Hardware : MSI Z87-G43, I7-4790, 16 GB RAM, 5x3 TB WD Red, Digibit-R1 (2 Devices)
    Software : Ubuntu 16.04 LTS mit yavdr-Paketen,virtualbox,diverse VM's


    Yoda: Dunkel die andere Seite ist...sehr dunkel!
    Obi-Wan: Mecker nicht, sondern iss endlich dein Toast ...

  • Man findet viele ungeklärte Ausfälle


    Dem kann ich nur beipflichten,von meinen 2 Exemplaren hat eine schon beim ersten Kopiervorgang die Flügel gestreckt. Austausch bekommen und bei der kurze Zeit später das gleiche Problem...
    Die erste ist voll und hält hoffentlich auch durch :angst

    Asus H170 PRO GAMING, Intel Core i7-6700T, 16GB RAM, GeForce GTX 1050 2GB, Samsung SSD 860 EVO 1TB SSD + 3TB WD Red, Mystique SaTiX-S2 Dual, Archlinux -> VDR4Arch


    "Freunde sind Menschen, die dich mögen obwohl sie dich kennen"

  • An diejenigen, die die Platte haben und mit Ausfällen etc. zu kämpfen haben: Könntet ihr eure Kernel-Version dazuschreiben und ggf. ein bisschen Kernel-Log schreiben und ob ihr NCQ ein- oder ausgeschaltet hattet?


    Könnte mir vorstellen, dass die Ausfälle nicht einfach nur hardwarebedingt sind (siehe anderer Thread)...

  • An diejenigen, die die Platte haben und mit Ausfällen etc. zu kämpfen haben: Könntet ihr eure Kernel-Version dazuschreiben und ggf. ein bisschen Kernel-Log schreiben und ob ihr NCQ ein- oder ausgeschaltet hattet?


    Könnte mir vorstellen, dass die Ausfälle nicht einfach nur hardwarebedingt sind (siehe anderer Thread)...



    Aua - wenn zum fehlerfreien Betrieb eines so elementaren Teils eines Systems (Harddisk) es auf eine Kernelversion ankommt, dann setzte ich so eine Platte nicht ein. Auch die Geschichte mit raidtauglichkeit lässt mich frieren

  • Gut, wenn man ein RAID will, muss man etwas anderes nehmen. Wenn man sich verallgegenwärtigt wie SMR funktioniert aber kein Wunder, dass die Technik nicht RAID-geeignet ist. Das heißt ja nicht, dass die Platte deswegen kurzlebiger etc. ist.
    Und zu der Kernel-Geschichte... Andere (neue) Hardware brauch auch Kernel-Support, so etwas hat man ja immer mal, nur schade, dass es noch nicht gefixt ist. Wenn man einmal einen passenden Kernel hat, wird man ja später eher nicht mehr auf einen älteren wechseln.
    Aber stimmt schon, erfreulich ist das alles nicht. Um ehrlich zu sein habe ich mit Helium aber mehr Bedenken bzgl. Langlebigkeit (>8 Jahre) als mit SMR und eine Helium-Platte ist dann ja die einzige Alternative.



    Edit: BTW -> http://www.heise.de/newsticker…atten-besser-3238450.html :D

  • Ich hab ja Verständnis, wenn ein SATA-Controller einen neuen Kernel bedingt - aber ein Gerät an einem SATA-Controller -von denen es haufenweise unterschiedliche gibt) sollte mit dem Kernel selbst ja nun wirklich nichts zu tun haben (finde ich).

  • machtnix: Wenn ich das richtig verstehe, werden die Probleme erst kommen, wenn du mal ein gesamtes Rebuild machen musst.
    An deiner Stelle würde ich mal ein Backup der Daten machen, den ganzen Verbund mit Testdaten komplett voll machen, eine einzelne Platte aus dem Verbund nehmen (oder müssen es bei RAID50 bei 8 Platten gar zwei sein?), diese eine Festplatte löschen und dann dem Verbund wieder hinzufügen und somit ein echtes Rebuild erzwingen.
    Wenn du mit dem Ergebnis nicht zufrieden bist: umbauen, hast ja noch das Backup ;)

  • Wenn ich da richtig rechne bleibt bei einem RAID 50 von 8*8 TB Platten 2*(4-1)*8TB übrig - also rund 48TB. Viel Spaß beim Backup (wohin?) - klar - hängt vom Füllgrad mit "wichtigen" Daten ab aber dennoc - aber das wird jetzt OT

  • AUWEIA - 8x8TB und dann noch als Raid5X = Datenverlust vorprogrammiert beim nächsten Rebuild. Ich finde den Link gerade nicht wieder aber ich versuche es einmal sinngemäß wiederzugeben.


    Bei den Consumer Platten tritt alle 12TB ein defektes Bit auf, im schlimmsten Fall ist gleich das erste Bit im besten das letzte : d.h. im Falle von 8 TB Platten, ( sofern die Fehlerkorrektur der Platte wie bei highend HDD nicht um den faktor 10 gesteigert wurde, der preis für die HD allerdings auch ;/ ) ist die Wahrscheinlichkeit, dass eine einzige Platte nur ein fehlerhaftes Bit aufweist im Gegensatz zu kleineren Platten wie z.b. 4 TB um den Faktor 2 größer. Bei einem Raid 50 dürfen es schon 2 Platten sein. Dennoch ist die Wahrscheinlichkeit sehr groß und bei einem Rebuild werden die gesamten Daten/Bits ALLER Platten abgefragt und wenn da nur Bit nicht mehr gelesen werden kann ist der gesamte Rebuild und damit die Daten ALLER Platten verloren.


    Ich war lange Jahre ein Verfechter von Raid 5 und co, musste allerdings feststellen, dass es bei den heutigen Plattengrößen keinen Sinn mehr macht. Einziger Ausweg sind Enterpriseplatten dessen Fehlerkorrektur um ein vielfaches höher ist als die der Consumerplatten, nur ob ein fast 3-4x so hoher Preis das ganze noch wirtschaftlich erscheinen lässt sei dahingestellt - Im Highendsektor mit Hochverfügbarkeit der Daten macht es vllt grad noch Sinn. Unter "normalen" Bedingungen allerdings nicht mehr da das Risiko eines Totalverlustes den der Datensicherheit aus dem o.g. Problem weit übersteigt.


    bei einer 12TB HD ist garantiert 1Bit defekt und kann nicht mehr ausgelesen werden ( bei aktuellen consumer HDD stand ) Wie gesagt kann es bei 8TB nochmal gut gehen, aber das Risiko wäre mir pers. zu groß.


    Ich las vor Monaten mal, das die 8TB HDs mit Helium gefüllt sind ( warum weis ich grad nicht mehr ) und das das Helium auf Dauer selbst durchs Metall diffundiert und die HDD damit neben der Parkanzahl der Leseköpfe eine weitere "Hardwareausfallkomponente" dazugekommen ist was den möglichen Plattenausfall angeht.


    Ich bin daher bei 6 TB HDD von HGST geblieben und die laufen nun schon knapp 1 Jahr sauber im Server ohne Ausfälle - insgesamt habe ich bis dato 6 HGST 6TB HDDs bei mir und Bekannten verbaut, alle HDDs laufen seit knapp einem Jahr 24/7 ohne Probleme


    Ausfallraten div. Platten : https://www.backblaze.com/blog…rive-reliability-q3-2015/


    doch noch gefunden : http://www.hardwareluxx.de/com…laufen-lassen-871425.html


    [...]
    die Chance für Datenverlust durch einen einzigen Sektor-Fehlers im raid-5 array mit n Platten nach einem Plattenausfall liegt bei
    (n - 1) * Diskkapazität[in Bit] / Bit Error Rate [der verwendeten Platten]


    sei ein raid-5 array aus 10 Platten á 1TB mit einer BER von 10^14, mit welcher Wahrscheinlichkeit tritt dann ein Lesefehler während eines Rebuild (nach dem Ausfall einer ersten Platte) ein?
    1TB = 8 * 2^40 bits, ausgedrückt in Potenzen zur Basis 10 sind das 8,79 * 10^12 bits
    da für einen Rebuild sämtliche Sektoren aller verbliebenen 9 Platten gelesen werden müssen, ergibt das eine Menge von 79,16*10^12 oder 7,9*10^13 zu lesenden Bits
    beträgt nun die Lesefehlerrate (wie bei low end platten üblich) 10^14, dann ergibt sich 7,9*10^13/10^14 also 79% Chance, dass während des raid-5 rebuild durch Lesefehler Daten oder das ganze array verloren gehen


    für 2TB Consumer Platten mit 10^14 BER sieht es wie folgt aus
    2TB in 10er Potenzen ausgedrückt sind 17,59*10^12
    10^14/17,59*10^12 = 5,7; i.e. bei Verwendung von 5,7 Platten dieses Typs tritt nahezu zwingend ein Lesefehler während des Rebuilds ein


    bei Nearline Platten á 2TB mit 10^15 BER tritt, wie man nun leicht selbst überprüfen kann, mit an Sicherheit grenzender Wahrscheinlichkeit erst bei Verwendung von 56 Platten dieses Typs ein Fehler dieser Art ein


    was also kann man tun, 4 Dinge, würde ich sagen:
    * für aktuelle Backups sorgen
    * anständige Festplatten verwenden mit besseren BER, bei grösseren Platten im Sata-Bereich sind das die sog. Nearline Platten, zb. Constellation ES
    * in der Formel oben an dem Parameter n drehen, um die Wahrscheinlichkeit für nicht korrigierbare Fehler während des rebuild eines raid-5 zu reduzieren;
    das ist es nämlich, was raid-50 tut, und dennoch grössere Datenmengen handeln kann als ein raid-5 allein
    für raid-50 bleibt allerdings immer noch das Problem eines möglichen zweiten Plattenausfalls, besonders bei low end platten
    die Gesamt-Verlässlichkeit, bzw. umgekehrt die Chance auf Datenverlust eines solchen Arrays bestimmt sich bekanntlich aus den drei Grössen MTTR, MTBF und BER
    für die Verlässlichkeit eines raid-5 gilt: MTBF^2 / (n * (n - 1) * MTTR), wobei n Anzahl der Platten
    eine seriöse, und insoweit vorsichtige rechnerische Annäherung an die Problematik berücksichtigt aber natürlich die in der Praxis zu beobachtende Neigung von arrays nach einem ersten Plattenausfall im Rebuild gleich noch einen zweiten Ausfall nachzuschieben; ein raid-5 und ein raid-50 sind dann tot. Solche sogenannten korrelierten, nämlich von den Umständen abhängigen Plattenausfälle, deren Eintrittswahrscheinlichkeit eben nicht mehr entlang der statistischen Ausfallwahrscheinlichkeit der einzelnen Platte verläuft, werden dergestalt berücksichtigt, dass für eine weitere (zweite) eine 10mal höhere Wahrscheinlichkeit und für eine weitere (dritte) Platte eine 100mal höhere Ausfallwahrscheinlichkeit zugrunde gelegt wird
    es ergibt sich so folgendes:
    -raid-5 = MTBF * MTBF/10 / n * (n - 1) * MTTR
    -raid-6 = MTBF * MTBF/10 * MTBF/100 / n * (n - 1) * (n - 2) * MTTR^2


    * raid-6 verwenden, damit erschlägt man gleich mehrere Probleme,
    ein Lesefehler im Rebuild macht nämlich einem raid-6 gar nichts, die Daten sind wegen der zweiten Paritätsschicht allemal rekonstruierbar
    und auch ein zweiter Plattenausfall führt nicht zu irgendeinem Datenverlust
    [...]


    Server : Debian 10 + VDR 2.4.0 on | HP Gen8 Microserver X1265L | 16 GB EEC DDR 1600 | 1 x EVO 860 Pro 500 GB, 2x6TB HGST, 1x10 TB HGST | TBS 6981
    Client : Debian 11 + Kodi 19 (deb.multimedia Quellen) on | Intel DH77EB | i3 2100T | 16 GB 1600 DDR3 | GF GT 520 | 1 x 850 EVO 500 GB | BQ 300W L7 | X10 Remote | in Zalman HD 160 | Sedu Ambilight |
    Client : Debian 10 + Kodi 19 (deb.multimedia Quellen) on | Asus Z87 Pro | I5 4660 | 16 GB 1600 DDR3 | GF GTX770 | 1 x 850 EVO 500 GB | BQ 450 W L8 | in Chieftech CS 601 |
    Client : Debian 10 + Kodi 19 (deb.multimedia Quellen) on | Lenovo T430 |


    Websites | speefak.spdns.de | www.itoss.org | cc-trade.info | www.bike2change.de | www.x-woodart.de |

    3 Mal editiert, zuletzt von speefak ()

  • [...] Ich las vor Monaten mal, das die 8TB HDs mit Helium gefüllt sind ( warum weis ich grad nicht mehr ) ...


    Die Platten sind mit Helium gefüllt, weil sie sonst, wenn man sie mit 8TB an Daten befüllt hat, viel zu schwer für die meisten Plattenhalter in den Standardgehäusen wären.
    Deshalb muss man übrigens auch beim Einbau, solange noch keine Daten darauf sind aufpassen, damit sie nicht davonfliegen. :)

  • ich dachte immer das wäre für user mit bass bariton stimme :rolleyes:


    Server : Debian 10 + VDR 2.4.0 on | HP Gen8 Microserver X1265L | 16 GB EEC DDR 1600 | 1 x EVO 860 Pro 500 GB, 2x6TB HGST, 1x10 TB HGST | TBS 6981
    Client : Debian 11 + Kodi 19 (deb.multimedia Quellen) on | Intel DH77EB | i3 2100T | 16 GB 1600 DDR3 | GF GT 520 | 1 x 850 EVO 500 GB | BQ 300W L7 | X10 Remote | in Zalman HD 160 | Sedu Ambilight |
    Client : Debian 10 + Kodi 19 (deb.multimedia Quellen) on | Asus Z87 Pro | I5 4660 | 16 GB 1600 DDR3 | GF GTX770 | 1 x 850 EVO 500 GB | BQ 450 W L8 | in Chieftech CS 601 |
    Client : Debian 10 + Kodi 19 (deb.multimedia Quellen) on | Lenovo T430 |


    Websites | speefak.spdns.de | www.itoss.org | cc-trade.info | www.bike2change.de | www.x-woodart.de |

  • OK, nachdem dieses verbuggte Forum mir jetzt zum dritten mal den gesamten Post kaputt gemacht hat und meinen eigenen Text in Quotes reinkopiert hat habe ich keine Lust mehr.
    Dann muss der Schwachsinn von speefak halt unkorrigiert so stehenbleiben.

  • Ich denke mal jeder, der über diesen Thread stolpert hat dieselbe Frage: Welche große Festplatte kaufe ich mir?


    Ich fasse nochmal zusammen:


    - 8TB Archive: ohne Helium, aber mit SMR, ggf. Performance-Einschränkungen und Kernel-Abhängigkeiten
    - 8TB (unabhängig vom Hersteller und ob Desktop- oder NAS-Version): recht teuer und immer mit Helium
    - 6TB: vielleicht der beste Kompromiss, wenn man kein Helium und kein SMR haben will, aber unverlässliche Daten welche Modelle mit/ohne SMR/Helium sind


    Daher die Frage: Welche 6TB-Platten haben denn tatsächlich KEIN Helium und KEINE SMR-Technologie? Diese Preis-Vergleichsseiten und auch die ein oder andere Vermutung in Foren und bei sog. Hardwaretests sind die Angaben nicht gerade zuverlässig.


    Edit: Ich beantworte mir die letzte Frage selbst - vielleicht hilft es ja jemand anderem: 6TB WD Red, 6TB HGST NAS und 6TB Seagate NAS sind alle relativ gleichwertig bzgl. Preis-/Leistung, Ausfallraten, haben TLER, kein SMR, kein Helium. In meinen Augen die konservastivste Möglichkeit in vertraute Technik mit helbwegs Kapazität zu investieren. Die anderen 6TB-Platten (Toshiba, Intensio, ...) sind ggf. auch zu empfehlen, haben aber kein TLER und sind allgemein eher mit den Desktop-Varianten der o.g. Hersteller zu vergleichen (sprich ständiges Lese-Kopf-Parken und damit nicht 24/7 geeignet usw.).

  • anybody, zu blöd zu posten und dann trozig wien kleinkind :rolleyes:


    ich habe 2 von denen im Einsatz : http://www.heise.de/preisvergleich/hgst-deskstar-nas-6tb-h3iknas600012872se-0s03840-a1188260.html?hloc=at&hloc=de


    super Datenrate konstant 100 MB übers Netzwerk bei 3 TB kopierten Daten, SMR und Helium hat die HD noch nicht.


    Server : Debian 10 + VDR 2.4.0 on | HP Gen8 Microserver X1265L | 16 GB EEC DDR 1600 | 1 x EVO 860 Pro 500 GB, 2x6TB HGST, 1x10 TB HGST | TBS 6981
    Client : Debian 11 + Kodi 19 (deb.multimedia Quellen) on | Intel DH77EB | i3 2100T | 16 GB 1600 DDR3 | GF GT 520 | 1 x 850 EVO 500 GB | BQ 300W L7 | X10 Remote | in Zalman HD 160 | Sedu Ambilight |
    Client : Debian 10 + Kodi 19 (deb.multimedia Quellen) on | Asus Z87 Pro | I5 4660 | 16 GB 1600 DDR3 | GF GTX770 | 1 x 850 EVO 500 GB | BQ 450 W L8 | in Chieftech CS 601 |
    Client : Debian 10 + Kodi 19 (deb.multimedia Quellen) on | Lenovo T430 |


    Websites | speefak.spdns.de | www.itoss.org | cc-trade.info | www.bike2change.de | www.x-woodart.de |

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!