Western Digital introduceert eerste 14TB-hdd

Western Digital heeft de HGST Ultrastar Hs14 aangekondigd, de eerste 3,5"-hdd met een opslagcapaciteit van 14TB. De met helium gevulde harde schijf draait op 7200rpm en is uitgerust met 512MB cache.

Er komen sata- en sas-uitvoeringen van de Ultrastar Hs14. Volgens de fabrikanten is de maximale schrijfsnelheid 233MB/s. De 14TB-hdd is bedoeld voor de zakelijke markt en is volgens maker Western Digital geschikt voor gebruik in servers. De hoge capaciteit is mogelijk dankzij gebruik van smr-techniek, waarbij de magnetische banen elkaar enigszins overlappen.

Eind vorig jaar kondigde Western Digital al aan dat de 14TB-hdd op komst was. Toen presenteerde het bedrijf een 12TB-hdd onder de HGST-merknaam, die wat hardware betreft vrijwel gelijk is aan het nieuwe 14TB-model. Meer fabrikanten hebben toegezegd met 14TB-hdd's te komen dit jaar, waaronder Toshiba en Seagate.

WD heeft niet bekendgemaakt wat de prijs is van de Ultrastar Hs14. Het bedrijf zegt dat de hdd op dit moment aan een select aantal oem's wordt verstrekt. Wanneer de 14TB-hdd in de winkels komt te liggen, is nog niet bekend. De Ultrastar He12-hdd met 12TB is te koop voor zo'n vijfhonderd euro.

Reacties (126)

[SSDtje]

Ook wel prettig om te weten:
De gemiddelde latency zou 4,16 milliseconde bedragen met een seek time van 7,7 ms bij lezen en 12 ms bij schrijven. De MTFB ligt op 2,5 miljoen uur met een error rate van 1 op de biljard, ofwel een tien met vijftien nullen.
Bron

En alle overige info inmiddels ook gevonden:
Kijk eens aan. = Datasheet

[Reactie gewijzigd door SSDtje op 26 juli 2024 21:35]

[scsirob]

Die latency is misleidend, dat gaat puur over de rotational latency. Die is voor elke 7200rpm schijf 4.16ms. Immers, 7200 rpm = 120 rps, een rondje duurt 1/120 seconde, dus een half rondje (=average rotational latency) is 1/240 seconde. En dat is precies 4.16ms

Voor de average access time moet je die latency optellen bij average seek time (7.7ms) en command overhead (niet gespecificeerd). Dan kom je op dezelfde getallen als je oude 100MB Maxtor uit 1998.

[GekkePrutser]

Wel logisch ook, want aan de fysieke opbouw van een HDD is niet zoveel veranderd in de afgelopen jaren (behalve de 15K enterprise HDD's).

En tegenwoordig is de latency ook niet zo belangrijl meer, meestal gebruik je een SSD om daadwerkelijk vanaf te werken en een HDD puur als massaopslag.

[SSDtje]

"de fysieke opbouw van een HDD is niet zoveel veranderd in de afgelopen jaren (behalve de 15K enterprise HDD's)

Dat klopt.
En om het laatste stukje tussen de aanhalingstekens van je nog even bij te staan, heb ik van dat soort HDD's de datasheet er ook maar weer eens bij gepakt.
Kijk eens aan.

[Reactie gewijzigd door SSDtje op 26 juli 2024 21:35]

[jubeth]

Dat is best hoog en goed voor een 7200 RPM. Petje af hoor, voor die Helium disks van WD. Ik bezit en gebruik zelf al een tijd een aantal HUH728080ALE600, ook HGST, komen bijzonder solide en betrouwbaar over. Bovendien zijn ze superstil!

[scsirob]

Die error rate is nogal verontrustend. Een schijf van 14TB heeft 112.000.000.000.000 bits aan data (plus de nodige overhead) op de schijf. Als je 1.000.000.000.000.000 deelt door 112.000.000.000.000 dan kom je op iets minder dan 9. Ofwel, als je de hele schijf 9 keer leest (of 9 schijven 1 keer) dan heb je een unrecoverable bit error te pakken.

Hmmm...

[Durandal]

ZFS

Ik denk trouwens dat dit soort schijven niet echt in normale desktops gezet gaan worden.

[BottleNext]

14 000 000 MB / 233 MBps = 16,7 uur voor je hem vol of leeg hebt op de theoretische maximum snelheid.

[Snow_King]

SMR, dat is een techniek waar je mee moet oppassen. Met sequentieël schrijven zijn ze wel aardig, maar random writes worden echt een drama.

Deze disks moet je ook niet zo maar in een server gaan plaatsen als het filesystem wat daar boven zit niets snapt van SMR. Dan ga je serieuze performance problemen krijgen.

[Nogne]

Ik heb weinig kennis van filesystems, maar bepaald een filesystem waar er op een disk word geschreven? Hoort een schijf dit niet te doen?

[TD-er]

Een filesysteem heeft best wel veel impact op waar op de schijf het komt te staan.
Dat is namelijk de vertaalslag van directory/file structuren naar logische blokken.

En daar zit 'm nu het het probleem in dit geval. De performance kan nogal uitmaken voor schrijfacties bij dit soort schijven.
Je moet namelijk tot wel 3 sporen opnieuw inlezen en schrijven om een sector te schrijven. (3 is in elk geval de keus bij Seagate, geen idee of HGST hetzelfde aantal overlappende tracks heeft)
Dus als filesysteem kun je dan beter frequent wijzigende data wegschrijven in het 'laatste' spoor van een SMR-track-set en relatief statische data, of hele grote files, kun je kwijt in de overige sporen.
Maar dan moet je dus wel weten hoe de vertaalslag is van logische blokken naar performance.

[Hakker]

Geen enkele filesysteem zal je hierbij helpen ze zullen enkel iets anders bufferen en dat doen de meeste al wat langer dan vandaag maar geen OS zal wat van de Host SMR iets kunnen maken dus ook dit zijn WORM schijven.
Nu zijn Host managed SMR schijven wel wat beter bestand vergeleken met de Seagate Archive SMR schijven die Drive SMR hebben maar het liefst wil je ook een Host Aware SMR hebben en daar ligt het probleem. buiten wat experimenten om is er nog niks. SAFS is een leuk experiment en meer ook niet echt OpenZFS is er nog mee bezig BTRFS wil het gaan implementeren en het volgende probleem is dat zover ik weet ook geen HBA's/Raid Adapters zijn die Host aware ondersteuning hebben.

Maarja hopelijk heeft het een ander voordeel en dat is goedkopere schijven, want ik kijk ook met deze Host aware SMR schijven wel even de kat uit de boom.

[H!GHGuY]

Je moet namelijk tot wel 3 sporen opnieuw inlezen en schrijven om een sector te schrijven. (3 is in elk geval de keus bij Seagate, geen idee of HGST hetzelfde aantal overlappende tracks heeft)

Je moet de zone herschrijven, want als je die 3 sporen wil schrijven, overschrijf je weer 2 andere sporen, die je dan opnieuw moet schrijven, en ... tot je op het einde van de SMR zone komt.

Maw: je hebt een write pointer binnen een zone en enkel daar kan je toevoegen.

Dus als filesysteem kun je dan beter frequent wijzigende data wegschrijven in het 'laatste' spoor van een SMR-track-set

Dit kan niet. Je kan de write pointer niet zomaar willekeurig op een punt in de SMR zone droppen. Er zijn allerhande effecten die spelen waardoor dit niet kan.

Anderzijds hebben veel SMR disks ook enkele PMR zones, waar ze random writes bufferen vooraleer deze weg te schrijven naar SMR zones. Daardoor kun je best wel goede random write throughput halen voor een beperkte periode.

[axelx19]

Als ik me niet vergis bepaald het fs de locatie op de disk. Het het fs stuurt read / write requests de volgorde waarin die worden verwerkt is de taak van ahci dat de brug vormt tussen fs en hdd

Verbeter me als ik mis ben.

[Henk Poley]

Dit zijn inderdaad meer archief-schijven, of voor grotere bestanden (denk: video, foto's). En voornamelijk constant achter elkaar door schrijven zijn ze niet op gemaakt. Eigenlijk hetzelfde euvel als Flash schijven hebben.

Veelal gebruiken deze schijven niet puur SMR opslag, maar hebben ze een stuk van de schijf waar 'ouderwets' naar geschreven wordt. Die wordt dan van tijd tot tijd overgeheveld naar het SMR gebied, dat veel compacter is, maar in grotere blokken aan 1 stuk door geschreven moet worden. Een soortgelijke techniek wordt gebruikt in Flash schijven, omdat dat daar het wissen van ongebruikte blokken ongeveer 250ms in beslag neemt.

Maar het gaat dus pas "mis" als je die tijdelijke tussen-opslag vol hebt geschreven. Dan zal de schrijfsnelheid verminderen.

Nu zijn er natuurlijk betere opslag technieken dan draainde schijven, als de snelheid van op willekeurige positie schrijven belangrijk is. Zoals Flash en 3D-Xpoint. In het top-segment van server opslag systemen heb je gelaagde ('tiered') opslag, die Flash schijven combineert met archief-opslag zoals SMR schijven.

[Reactie gewijzigd door Henk Poley op 26 juli 2024 21:35]

[Macfreak101]

En toch blijven ze iedere keer over de limiet heen gaan die fysiek niet mogelijk zou moeten zijn. Vind het erg knap. Zijn deze schijven echter ook geschikt voor gebruik in een NAS of zijn meerdere kleine schijven dan aan te raden?

[InjecTioN]

Sowieso zijn meerdere kleine(-re) schijven altijd aan te raden. Je kan ze dan gebruiken in een RAID of ZFS opstelling, waardoor je vervolgens geen data kwijt zult raken bij het falen van een schijf.

[Reactie gewijzigd door InjecTioN op 26 juli 2024 21:35]

[MiesvanderLippe]

Als je hetzelfde aantal schijven gebruikt kan je echter net zo goed 14TB schijven gebruiken voor dezelfde redundantie. Resultaat is een hogere data-dichtheid wat veel datacenters willen omdat rackspace duur is. Dan duurt het rebuilden wel een eeuwigheid natuurlijk.

[Croga]

Rebuilden is met dit soort schijven geen optie. Eeen rebuild van dit soort hoeveelheden data gaat gegarandeert een stress op de rebuild-schijven zetten die voor nieuwe errors zorgt.

RAID is heden ten dage simpelweg geen optie meer. Het werkt niet. Alles wat een rebuild nodig heeft zal geen rebuild kunnen doorstaan.

[Junketsu]

Waarom zou deze stress voor errors zorgen? Het is toch gewoon 14 TB volschrijven (wss minder gok ik), en dat is voor zo'n schijf toch peanuts? Een schijf hoort toch jaren mee te gaan en dan kan er vele honderen TB op worden geschreven.

[aadje93]

Schijven hebben een bepaalde UER (Unrecoverable Error Rate) welke in een X aantal bits word vastgesteld; voor de 10TB red (gezien als nu de max NAS schijf, waarvan ik makkeliijk even data kon vinden) is dat <1 in 10^14 gelezen bits. We gaan even uit van "worse case" dus 1 op elke 10^14 bits.

Dat is dus een 1 met 14 nullen voor de komma, of grofweg 12.5TB. Daarmee loop je dus het enorm grote risico dat je een unrecoverable error krijgt wanneer je een raid array moet rebuilden met zulke schijven.. Immers moet elke schijf volledig gelezen worden om de parity data (vergelijk het met de stelling van pythagoras maar dan met bits ipv een driehoek) te lezen, en de "verloren" data op de kapotte schijf te rebuilden.

Ik zou dus zulke schijven niet eens in raid 1 gebruiken voor echt kritische data. Er is dan al een kans dat je bestanden verliest door een 1:1 kopie te laten maken, immers 14TB lezen met een UER van 1:1*10^14 is gedoemd dat er minimaal 1 error voorbij komt bij het lezen van de hele schijf. Ik vermoed dat ze dit toch wel wat hoger gekregen hebben, anders zul je zulke schijven nooit aan de man kunnen krijgen, maar ik blijf er dus huiverig mee.

Elke vorm van ZFS--2/ZFS-3 of Raid 5/Raid6, waarom ZFS uberhaupt nog 2 en 3 model aanbied is mij een raadsel, immers bedoeld als "massive" file systeem (Zetabyte, 1000.000.000 terabyte) zal dus de volledige array kwijtraken als er 1 unrecoverable error optreed bij 1 van de schijven tijdens rebuild. Leuk als je dan groepjes van zfs2/zfs3 hebt in een "raid 0" model (ZFS 20/ZFS30 achtig), dan ben je mooi je zetabyte aan data kwijt

Vandaar geld grofweg vanaf 4TB, gebruik geen eens raid 6 meer, maar doe het in raid 1 of raid 10 (1+0) zodat de rebuild gewoon 1:1 kopien van schijven zijn ipv parity model. De kans op data verlies is dan vele malen kleiner. Al is het nog steeds aanwezig. En de performance van raid 10 is zowieso al stukken beter (write) vergleken met raid 5/6 door het mindere rekenwerk dat nodig is van de CPU/controller.

[Twixie]

Schijven hebben een bepaalde UER (Unrecoverable Error Rate) welke in een X aantal bits word vastgesteld; voor de 10TB red (gezien als nu de max NAS schijf, waarvan ik makkeliijk even data kon vinden) is dat <1 in 10^14 gelezen bits. We gaan even uit van "worse case" dus 1 op elke 10^14 bits.

Ik heb toevallig recent behoorlijk wat research gedaan inzake RAID voor mijn nieuwe Synology, en dan vooral of RAID 5 / SHR al dan niet aan te bevelen is.

Enerzijds heb je het kamp dat elke parity raid (RAID 5, SHR, etc...) ongeschikt vindt omwille van die URE specs. Blijkbaar is de bron van veel van deze claims dit artikel : http://www.zdnet.com/arti...-5-stops-working-in-2009/ .

Je hebt echter ook een kamp die die claims zwaar in twijfel trekken. Daarbij ook veel mensen die beroepsmatig in datacenters werken. Die claimen dat die 1/10^14 een beetje een standaard spec is van HDD fabrikanten maar zeer sterk overdreven is (om zichzelf in te dekken) en de werkelijke betrouwbaarheid van HDDs een pak hoger ligt.

Ook zie ik sommigen nogal een loopje nemen met de wiskunde. Een kans van 1 op 10^14 dat een bit faalt, betekent helemaal geen zekerheid dat je op 12.5TB een slechte bit zult zien. De kans is ong. 75% wat natuurlijk nog enorm hoog is. Met een URE rate van 1 op 10^15 zakt dat al naar 10%.

Ik heb zelf ook wel RAID10, al is het maar omdat ik diskspace genoeg heb... Maar of RAID 5 (en dus ook SHR) echt zo nefast is, durf ik nu toch ook meer en meer te betwijfelen. De real-world claims zijn vooral succesverhalen dat RAID5/SHRs zonder problemen gerebuild zijn, terwijl de negatieve verhalen allemaal berusten op theorie zonder ook daadwerkelijke real-world scenarios.

PS: om het ook on-topic te houden, heb ik eens berekend wat de kans op een URE is bij een RAID-5 rebuild van deze schijven. Error rate is gespect als 1 op 10^15. Dit geeft dan voor een RAID-5 een kans op URE van 31%. Als de werkelijke error rate 1 op 10^16 is, dan zakt dat al naar 4% ! En voor wie benieuwd is naar de berekening : 1- (1- (1/10^16)) ^ (42 * 1024^4 * 8 ) ...

[Reactie gewijzigd door Twixie op 26 juli 2024 21:35]

[TD-er]

Je ziet steeds meer dat er allerlei trucjes uitgehaald worden in de firmware om toch nog RAID te kunnen gebruiken.
Zo weet ik van HGST schijven, dat ze in geval van een unrecoverable read-error, een timeout geven.
Voordeel hiervan is dat de RAID-controller ze niet uit de RAIDset gooit en ook niet faalt bij rebuilds van een set, mits voldoende redundantie over, zoals bij RAID6.

RAID-5 is in elk geval al behoorlijk tricky aan het worden.

Het beste is om Erasure code systemen te gebruiken zoals Ceph, HGST Active Archive, Dell DDP, of vergelijkbare systemen.
En ik vind het erg jammer dat de fabrikanten van RAID-kaarten daar nog niet mee bezig zijn, want het biedt nog veel meer voordelen dan alleen redundantie. Ook de rebuild-overhead is een heel stuk lager. In elk geval bij grotere systemen.

[boolean]

Ik heb zelf een RAID 6 array van 10X 3TB schijven dat als sinds 2010 operationeel is. Van deze 10 schijven zijn er in de afgelopen zes jaar 12 (ja, je leest het goed) stuk gegaan door uiteenlopende oorzaken. Tot vier keer toe is er tijdens de rebuild een tweede schijf uitgevallen. Desalniettemin heb ik tot nu toe nog nooit dataverlies geleden door falen van het array.

[Twixie]

Laat me raden, Seagate Barracuda ST3000DM001 ?

[boolean]

Hahaha, jij mag niet meer raden! Dat zijn echt de slechtste schijven (qua degelijkheid) die ik ooit heb gekocht. Bij introductie werden ze neer gezet als RAID schijven, wat al gouw afgezwakt werd naar Desktop RAID. Tegenwoordig zijn ze daar ook vanaf gestapt en raden ze de schijven alleen nog aan voor mild (niet 24/7) desktop gebruik.

[Sfynx]

Scheelt wel dat ZFS wel zo slim is om alleen de gebruikte ruimte te rebuilden (resilveren). Bij raidz3 mogen er 3 schijven in 1 set (vdev) falen zonder dat er problemen optreden, dus dat kan je best goed opvangen.

[TD-er]

Is nog steeds link omdat je bij grotere sets dus al met 4 defecte schijven data-loss kunt krijgen.
Het probleem zit 'm erin dat je niet willekeurig zoveel %van de schijven kunt laten falen zonder gevolgen, wat bij Erasure-code systemen wel kan.
Dus voor PB-scale opslag (100 schijven of meer) is dat soort RAID-achtige opslag best wel een risico.
Sowieso is het aannemelijk dat bij het falen van meerdere schijven, ze dicht bij elkaar zitten.
Het falen is namelijk niet altijd een random event. Bijvoorbeeld als een voeding *poef* doet, of door overmatige trillingen in 1 kast.

[Sfynx]

Dan zorg je dat schijven op dezelfde vdev fysiek zoveel mogelijk verspreid zijn en niet op dezelfde voeding, etc. Bijvoorbeeld ervoor zorgen dat als een hele backplane met schijven op vakantie gaat, ze allemaal over allerlei vdevs verspreid zitten zodat de pool als geheel nog steeds online is. Verder is het inderdaad niet aan te raden om je vdevs te groot te maken, zowel voor de random I/O performance als voor de redundancy tijdens een resilver. Maar het probleem van een flink aantal kleinere vdevs zie ik niet zo.

[Reactie gewijzigd door Sfynx op 26 juli 2024 21:35]

[TD-er]

Dan nog zit je tegenwoordig al snel aan 60 - 90 drives per 4u of 5u kast.
Dus hooguit 2 voedingen en een beetje afhankelijk van de fabrikant 4 - 8 backplanes.
Het blijft gewoon een risico met RAID, dus wat dat betreft is het mooier wanneer je het risico zo kunt spreiden dat het per node, rack of zelfs locatie gespreid is.

[ASS-Ware]

En de performance van raid 10 is zowieso al stukken beter (write) vergleken met raid 5/6 door het mindere rekenwerk dat nodig is van de CPU/controller.

Dat is geen vergelijking.
Bij RAID 10 raak je sowieso 50% van je totale diskspace kwijt terwijl dat bij RAID 5 slechts 1 disk en bij RAID 6 slechts 2 disken is.

[marcjo]

Je raakt niets kwijt! Je zet de helft van je diskspace in om schijf uitval te kunnen opvangen.
Is een andere benadering ;-)

[boolean]

Daarbij hoeft RAID 6 helemaal niet langzaam te zijn. Met een dedicated RAID controller heb je daar totaal geen last van.

[aadje93]

tja, koop jij even een raidcontroller voor 24 schijven? Ik zit nu met mijn 3 LSI 9211-8i is in IT mode op ZFS heel wat goedkoper, en zie na 5 jaar als het ding faalt maar is een nieuwe te krijgen van exact hetzelfde model. Vandaar dat ik HW raid al lang vaarwel gezegd heb. Software kun je op een disk (niet op diezelfde array uiteraard) nog opslaan en bewaren, een 2e HW controller op voorhand in cold storage leggen "voor het geval dat" is mij veel te duur

Ter vergelijking, een beetje 24 port controller is snel €1000, mijn 3 LSI 9211-8i's hebben slechts 100 euro gekost nieuw (ebay)

[boolean]

Dat ligt er maar net aan. Ik heb één fysieke server die als domain controller/PMS/fileserver en webserver fungeert. Mocht ik ZFS willen gebruiken houdt dat in dat ik er een nieuwe (niet Windows) server naast moet zetten. Dat betekent nieuwe voeding/moederbord/processor/geheugen/etc aanschaffen. Aangezien je ZFS nooit op een systeem zonder ECC geheugen wilt draaien kom ja al automatisch op een kostbare Xeon (doet AMD überhaupt nog mee?) met vergelijkbaar duur geheugen. Daarnaast ontlast een HW RAID controller het volledige systeem en is de performance van het array minder afhankelijk van de systeemresources.

[aadje93]

in de tijd dat ik mijn server bouwde was 128GB DDR4 ecc grappig genoeg goedkoper dan non-ecc geheugen, daarnaast is een xeon maar marginaal duurder dan een vergelijkbare "desktop" cpu. Je hebt wel gelijk een stuk betere veiligheid door datzelfde ECC. Met een desktop cpu die ecc ondersteund zit je ook al goed.

Maar die 24 schijven controller kost je wel tegen de 1000 euro, daar koop je een leuke xeon en wat LSI9211's voor

[Reactie gewijzigd door aadje93 op 22 juli 2024 22:04]

[itlee]

Als dat zo is wat je schrijft dan zou niemand deze disken kopen, zou het niet op een HCL staan van synology, disken die onbetrouwbaar zijn of die op grote schaal raid sets naar het hiernamaals helpen geloof ik helemaal niks van.

kunnen we wel formules op los laten, maar je gaat in je berekening er vanuit dat elk cluster een blokje data bevat (oftewel dat je schijf 100% vol geschreven is.) A; komt dat nooit voor in raid configuraties, B: als er een error in een cluster op treed wordt zover mogelijk de data naar een ander cluster verplaatst en wordt de desbetreffende gemarked als kapot.

ik heb al zoveel disken kapot gehad in raid configs, van groot naar klein, en t kost een hoop tijd (zeker bij synology) om een herstel te draaien maar t gaat altijd goed. en nu met de komst van btfrs op de professionele modellen verwacht ik dat het smooth loopt.

Bij synology en SSD's is het nog mooier, gebruiken ze Raid F1, dus er wordt nooit in dezelfde cell geschreven cross-ssd-heen zeg maar. dus cel a1 op ssd 1, cel b1 op ssd2 enz. dat betekent dat je ssd over je raid set ongelijkmatig slijt en dat niet als bij 1 ssd de ene cell kapot is het ook zo bij de ander is waardoor je raid set overlijdt. https://global.download.s...r/Synology_RAID_F1_WP.pdf

[Reactie gewijzigd door itlee op 26 juli 2024 21:35]

[boolean]

Synology is sowieso software RAID en zo traag als dikke stront door een trechter. Ik heb zelf de TS-859 Pro Plus gehad en was zo zwaar teleurgesteld in de performance dat ik over ben gestapt op hardware RAID. Het enige voordeel van de Synology was dat deze door zijn traagheid geen stress op de schijven uit kon oefenen zodat er ook minder uitvielen.

[RefriedNoodle]

Waarom zou deze stress voor errors zorgen?

De statistieken die de fabrikant geeft, zijn gebaseerd op normaal, gemiddeld gebruik. Bij een rebuild wordt een disk continu belast, omdat het continu data moet lezen, uren achter elkaar, dus continu de koppen moet verplaatsen. Als ondertussen het volume ook nog operationeel is voor clients, komen die requests ook nog eens tussendoor, zodat de koppen nog meer extra bewegingen moeten maken (en bij een degraded RAID5-array geldt dit voor *alle* disks, ook bij de simpelste lees- of schrijfacties). En als de koppen continu in beweging zijn, stijgt de gemiddelde temperatuur ook. Dat laatste hoeft op zich geen killer te zijn, maar helpen doet het zeker niet. Een constante temperatuur van 35 graden is minder erg dan een schommeling van 20 naar 30 graden.

Het enige waarvoor het niet uitmaakt, is de motor die de spindle aandrijft. Maar voor de overige componenten is het zeker geen 'peanuts'

Komt nog bij dat doorgaans de schijven in een array uit dezelfde batch van de fabriek komen, dus waarschijnlijk behoorlijk hetzelfde zijn als de uitgevallen disk, en even lang gedraaid hebben...

[Reactie gewijzigd door RefriedNoodle op 26 juli 2024 21:35]

[SkiFan]

Ik kan dat alleen maar beamen. Raid 5 set, disk overlijdt, vervang de disk en mee dat ik wil gaan rebuilden overlijdt disk 2 door de stress.

[The Zep Man]

RAID is heden ten dage simpelweg geen optie meer. Het werkt niet. Alles wat een rebuild nodig heeft zal geen rebuild kunnen doorstaan.

Heb een RAID6 draaien met 6x4TB. Heeft al verschillende hot rebuilds overleeft. Duurt ongeveer 1,5 dag (inclusief wat lezen en schrijven tussendoor). Met RAID6 is het minder kritisch als een enkele disk uitvalt.

Op dezelfde snelheid zou 14 TB ~5 dagen duren. Ik zou echter verwachten dat 14 TB disken sneller zullen zijn in sequentieel lezen en schrijven door de hogere fysieke datadichtheid, waardoor hier mogelijk een paar dagen vanaf gaan.

Ik denk dat dit soort disken gerust een rebuild kan doorstaan. De vraag is eerder of je het risico wilt lopen dat een andere disk uitvalt over de langere periode die de rebuild nodig heeft ten opzichte van kleine disken. Uit mijn ervaring weet ik dat de meeste disken het heel lang volhouden onder bepaalde voorwaarden:

1.
De temperatuur is stabiel. Stabiel 35'C geniet de voorkeur boven bijvoorbeeld schommelingen tussen 20'C-30'C.

2.
De disken draaien hun gehele levensduur.

[Reactie gewijzigd door The Zep Man op 26 juli 2024 21:35]

[scsirob]

De meeste double disk failures gebeuren doordat je fysiek aan het systeem gaat rommelen. Het schudden aan de kast omdat je de disk ernaast er uit haalt, de veranderde luchtstroom, slecht contact in het backplane, allemaal zaken die een disk 'over het randje' kunnen helpen. Maar de meest gangbare oorzaak is nog dat men niet goed oplet en in plaats van de defecte, een overgebleven goede disk uit de array trekt. Dan is het over en uit, backup uit de kast en uithuilen.

Inmiddels gaan sommige fabrikanten van hele grote arrays al over op drie parity schijven (NetApp RAID-TEC). Met 14TB disks is dat dus 42TB ruimte opofferen aan bescherming tegen defecte disks..

[4nik]

NetApp heeft wel de max raidgroup size verdubbelt voor NLSAS disken met RAID-TEC. Waar je met raid-dp maar 14 disken in een raidgroup mag steken, is dat nu maximum 28. Je wint eigenlijk een parity disk als je naar grote aggregates gaat.

[The Zep Man]

De meeste double disk failures gebeuren doordat je fysiek aan het systeem gaat rommelen. Het schudden aan de kast omdat je de disk ernaast er uit haalt, de veranderde luchtstroom, slecht contact in het backplane, allemaal zaken die een disk 'over het randje' kunnen helpen.

Met goede drive bays heb je hier geen last van. Zeker niet met drive bays met een schuifje/slotje, zodat andere disken waar je niet aan wilt zitten stevig op hun plaats blijven.

[marcjo]

Dat kan ik bevestigen. Vorige week een defecte schijf gehad in mijn Synology. Ook een 4TB, en dan in raid 10. maar er draaien 8 VM's op via iscsi en daar duurde ook ook 1,5 dag.
Maar dat lijkt mij ook echt wel de max, langer moet het niet gaan duren.

[BobJung]

In zekere mate begrijp ik raid wel, echter je bent altijd gebonden aan 5 identieke HD's in geval van een raid 5. Ik verzamel films en die dbase groeit constant, koop veel dvd's en de iso's gaan op de HD in mijn server. Mijn server geeft plek aan 10 schijven. Sinds 7 jaar terug is dat nog steeds afdoende. Door de schijven in JOBD te zetten kan ik willekeurig uitbreiden. Via HAS controleer ik of de backup identiek is.
Op een andere locatie heb ik een backup van de iso dbase. Deze staat alleen aan bij gebruik.
Door het opwaarderen van de schijven, heb ik inmiddels een behoorlijk aantal kleine schijven, die ik als koude backup gebruik.
Tot op heden heb ik 3 overleden HD's gehad en nog geen films kwijt geraakt.
De betrouwbaarheid van NAS schijven is zeer goed.

[beerendlauwers]

Gebruik je UnRaid?

[BobJung]

Ja en dat bevalt me prima. Hiermee is alles transparant en geen versleutelde schijven. Crasht de hardware, opnieuw opbouwen en direct weer aan de gang. Tijdelijk met een Harddisk dock werken rechtstreeks met een HD in een laptop. Dus nauwelijks downtime. De server is gesloten en online bestanden doe ik via OneDrive.

[beerendlauwers]

Leuk, ik heb net een DS4243 op de kop getikt en de UnRaid server is net af

[marcjo]

Raid 5 hoeft niet met 5 schijven, kan ook met 3. En in een Synology kan je zelfs verschillende formaten door elkaar gebruiken zonder verlies

[slaapkopje]

RAID hoeft niet per se over identieke schijven te gaan, dat kan ook met partities. Als je 2x 1TB en 1x 4TB hebt kun je de laatste schijf als losse 3TB partitie gebruiken, dat gaat wel ten koste van je performance en redundancy die je nu toch niet hebt omdat je geen raid gebruikt. De 3x 1TB schijven leveren dan 2TB netto op in RAID5. ... Het voordeel is dat je die 1TB schijven een-voor-een kunt hotswappen en rebuild-en en daarna kunt grow-en. Niet simpel en niet zonder risico, maar het kan wel. Cold backups maak ik alleen van de dingen die ik echt niet kan missen.

Ieder zijn eigen situatie, ervaringen en voorkeuren.

[ASS-Ware]

In zekere mate begrijp ik raid wel, echter je bent altijd gebonden aan 5 identieke HD's in geval van een raid 5.

Nee, voor RAID 5 heb je minimaal 3 schijven nodig, geen 5.

[jubeth]

Kan jullie aanraden eens te gaan spelen met FlexRAID's RAID-F.
Bij grote disks als dit heeft RAID-F enorme voordelen, omdat er niet een complete scan hoeft plaats te vinden na iedere fysieke aanpassing. Ben er zelf uitermate enthousiast over. Geeft een erg prettig veilig gevoel door de real-time parity opties, die je soort-van on the go kunt scalen naarmate je ruimte vrij hebt en disks voor extra redundancy wilt 'vernielen'. Eigenlijk een veel logischer optie bijv. binnen Windows environments, zonder dat eeuwige gehannes van diskformaten die niet kunnen/passen/mogen, onafleesbaar na crashes etc. en hot expandable bovendien. Beetje een betere manier dan wat ze voor die Drobo boxjes gebruiken, en veel minder duur omdat je geen speciale hardware (en nauwelijks software) nodig hebt. Met onze huidige multicore CPUs, en Gigabytes aan RAMspace, voelen de meeste systemen helemaal niets van de 'overhead' van RAID-F.

[stresstak]

Kan jullie aanraden eens te gaan spelen met FlexRAID's RAID-F.

Varianten genoeg om mee te spelen. Zo heb ik Storage Spaces in gebruik bij Windows 8.1.
In mijn geval een combinatie van Raid1 en 'parity'. Met drie schijven, maar uitbreidbaar met wat dan ook, zelfs met usb-sticks. Niet dat men dat doet, want de prestaties rennen achteruit natuurlijk.
Het is zelfredzaam en checkt zelf met regelmaat de schijven. Nog geen problemen gezien sinds augustus 2014.

Dankzij de Raid1 variant ook wat sneller, wat het parity-uitrekenen weer compenseert.

[Macfreak101]

Beide bedankt voor de reacties. Ik ga dan toch maar voor een NAS in raid opstelling. Ik ben mij er overigens van bewust dat het geen backup is . Bedankt voor de hulp mensen.

[CH4OS]

Anno 2017 (en misschien al eerder, eigenlijk) wil je liever ZFS gebruiken dan RAID. RAID is alleen om data-loss bij hardware falen tegen te gaan, terwijl ZFS dat ook heeft, maar ook de integriteit van de bestanden zelf waarborgt, waardoor corruptie in bestanden ook niet tot de mogelijkheden behoort. En met RAID kun je niet direct bij de SMART data komen van een disk.

[borft]

Hoezo kan je met raid niet bij de smart data van een disk komen? Volgens mij heeft dat niets met elkaar te maken ZFS heeft ook zo zijn nadelen, tov een hardware raid controller.

[CH4OS]

De RAID-controller biedt avaak alleen de array aan het OS aan. Je kunt dan dus de SMART-data niet meer bereiken. Je bent dan dus ook niet meer in staat een disk te vervangen voordat de disk stuk gaat, jr kan het dan alleen vervangen als de disk daadwerkelijk stuk is, omdat je het eerder niet weet of kan monitoren.

Dan zul je de array bewust los moeten halen en de disk direct moeten aansluiten. Of de controller in HBA modus zetten, maar dan heb je geen RAID meer en ben je de data op de disks kwijt.

[Reactie gewijzigd door CH4OS op 26 juli 2024 21:35]

[borft]

Nja, dat klopt gewoon niet Raid controllers waar ik ervaring mee heb (HP, DELL, etc), kan je gewoon de individuele disks uitlezen. Daarvoor hoef je de controller niet in HBA mode te zetten.

[CH4OS]

Heb zelf ook HP RAID controllers gehad en ik weet dat de hpcli tool het kan uitlezen inderdaad, of het dan allemaal klopt is een tweede, overigens. En ook daar heb ik helaas ervaringen mee.

Maar wat ik bedoel is dat je niet direct op OS niveau de SMART-data kan uitlezen (en jij wist volgens mij ook dat ik daar op doelde, dus je zit eigenlijk te muggenziften, imo), je moet dan eerst omslachtig naar de meegeleverde tools toe om het te kunnen zien. Je bent dan dus (te) afhankelijk van iets, dat moet je voor dergelijke data niet willen.

Dat maakt monitoring ook gelijk een stuk lastiger. Ongetwijfeld zullen Dell, HP en noem maar op hun oplossingen daarvoor hebben, maar nogmaals, dan wordt je afhankelijk ergens van en krijgt een dergelijke fabrikant alleen maar meer vendor locking, terwijl ik daar eigenlijk niet op zit te wachten.

[Reactie gewijzigd door CH4OS op 26 juli 2024 21:35]

[borft]

Nee, onder linux, kan je gewoon met smartmontools de smart data uitlezen, ook bij HP (smart array) en bij DELL (perc). Dus zonder de meegeleverde tools.

[CH4OS]

Afaik zijn de smartmontools van HP, maar kan het mis hebben. Ik gebruik liever smartctl direct.

[Reactie gewijzigd door CH4OS op 26 juli 2024 21:35]

[borft]

Op Debian/Ubuntu zit smartctl in de smartmontools package Als ik me niet vergis moet je bij HP de cciss driver opgeven. De PERC controllers van DELL zijn veelal rebranded LSI controllers.

[CH4OS]

HP controllers zijn ook rebranded LSI controllers (de HP SMartArray P400 en P420 iig wel), maar HP steekt wel moeite in eigen firmware en Dell niet. De cciss driver is van HP idd, maar volgens mij alleen voor oude controllers. Binnen ESXi is dat in elk geval wel een andere driver. De P400 en P420 hebben binnen ESXi iig een andere driver.

[Reactie gewijzigd door CH4OS op 26 juli 2024 21:35]

[borft]

ah, dat zou goed kunnen. Moet eerlijk bekennen dat ik de laatste tijd minder bare metal en meer cloud doe Lost ook gelijk het hele probleem van over hardware nadenken op.

Thuis heb ik natuurlijk wel JBOD met ZFS

[Sfynx]

Over vendor lock-in gesproken: ik zit persoonlijk ook niet te wachten op proprietary RAID metadata op mijn schijven waardoor de array alleen met bepaalde RAID kaarten is te gebruiken. Ik weet eerlijk gezegd niet hoe het tegenwoordig met moderne hardware RAID controllers gaat, maar ik herinner me persoonlijk best wat gezeik toen eens een 3ware kaart overleed en de array ergens anders geïnstalleerd moest worden.

Met ZFS intalleer je ergens anders dezelfde versie van het OS, je prikt de schijven op iedere willekeurige ondersteunde HBA, en het zaakje importeert wel weer.

Hardware RAID is m.i. nu vooral iets voor Windows servers die geen fatsoenlijke software RAID implementatie hebben, en het argument dat de CPU op een RAID kaart sneller is voor de RAID berekeningen is met de huidige moderne CPU's ook niet meer geldig.

[Reactie gewijzigd door Sfynx op 26 juli 2024 21:35]

[hooibergje]

Maar onthoud: RAID is geen backup. Ik herhaal: RAID is geen back-up.

[j1b2c3]

Sorry to burst your bubble hoe zit dat dan met Raid 1?

[Bas de Bakker]

Raid 1 is ook geen backup. Backups zijn alleen backups als ze offline zijn. Anders kan malware of operator error al je kopieen deleten.

[Aikon]

Een backup kan best online zijn. Alleen niet je volledige backup. 1 online, 1 offline en 1 offsite is een prima strategie voor snelheid, betrouwbaarheid en tegen externe factoren.

[stresstak]

Alleen niet je volledige backup. 1 online, 1 offline en 1 offsite is een prima strategie voor snelheid, betrouwbaarheid en tegen externe factoren.

Wat meteen de ellende is qua kosten. Voor vrijwel elke schijf moet je er dus twee extra kopen voor de backup. Hobbies kosten geld.

[Aikon]

Die offline en offsite kan je combineren als je wilt. Zelf hecht ik niet zoveel waarde aan bijv. films, dus oude, kleinere, schijven voldoen voor mij wel. Die liggen bij iemand anders in een la. Andere data zoals foto's heb ik dan weer op meedere plekken liggen. En bij backblaze kan je voor $50 een jaar lang onbeperkt backuppen.

[CH4OS]

Dat is ook geen backup. Dan zit de schijf alsnog in dezelfde machine ook al heb je dan enkel een mirror van je data lokaal op die ene machine. Backups wil je beschikbaar hebben los van de originele machine (en eigenlijk zelfs buiten het netwerk), anders kun je het nooit meer herstellen (bijvoorbeeld op een andere PC).

Het doel van RAID is dan ook totaal anders dan dat van een backup; RAID voorkomt dataloss door hardware falen, waar backups dataloss voorkomt door bijvoorbeeld user-error en beperkt bij disaster-recovery, bijvoorbeeld na een brand waarbij servers en schijven overleden zijn. Terwijl je dan een RAID1 array waarschijnlijk kwijt bent.

[Reactie gewijzigd door CH4OS op 26 juli 2024 21:35]

[Verwijderd]

Raid had nooit de bedoeling backup te zijn. Het werd ontworpen als redundant array inexpensive disk.
Het had 2 voordelen sneller lezen en 1 grotere disk werd gezien
Nu gebruikt men object storage om bitrot of leesfouten op te lossen.
Los van het feit dat een fout optreed bij het lezen heb je bij RAID ook nog het probleem dat de rebuild alles rebuild en het wel heel lang gaat duren. Als er dan iets gebeurt ben je eraan voor de moeite.
ZFS, BTRFS lossen dit op, maar toch gaat men meer en meer naar Objectstorage.
Belgische uitvinding trouwens :-)

[jubeth]

Hoeft niet over Objectstorage te denken, zo lang je iets als SnapRAID gebruikt. Ook erg handig.

[scsirob]

Lees de entry van hooibergje, lees het nog een keer, en nog een keer, tot het een mantra is. "RAID is *geen* backup"!!

RAID-1 is een mirror. Gooi data weg, het is op beide schijven weg. Daar doet RAID helemaal niets in.

[crazyx]

Ook geen backup. Als je een bestand verwijdert op schijf 1, is deze ook weg op schijf 2.

Dus voor virussen/malware/brand e.d ben je nog steeds even kwetsbaar.

[Roboblock]

Ook RAID1 is geen backup.
Een backup is een momentopname die gemaakt wordt, en die dan los staat van de originele data.
Dat heb je niet met RAID, dit is enkel ter voorkoming van dataverlies door het uitvallen van een schijf.
Als je bijvoorbeeld een cryptolocker of andere malware heb, die je data versleutelt/vernietigd, dan wordt die versleutelde/vernietigde data netjes over al je RAID-schijven verspreid.
In zo'n geval heb je toch echt een backup nodig.

[TheTeek]

iedere vorm van RAID (met uitzondering van RAID 0) is gemaakt voor "desaster avoidance", zo lang mogelijk proberen je data te behouden in operationele vorm.
Daarnaast is Back-up nodig in het geval je data kwijt bent geraakt, een fuck-up, malware... you name it...
RAID 1 gedraagd zich als 1 disk, malware kan al je data encrypten.., RAID 1 kopieerd klakkeloos alle wijzigingen op disk 0 naar disk 1... gevolg weg data. zonder back-up ben je met RAID 1 alleen bestand tegen het uitvallen van een disk.

[Bart©]

hetzelfde

[stresstak]

Sorry to burst your bubble hoe zit dat dan met Raid 1?

Net als andere raid-versies. Het is een 'doorwerkkopie'. En bij Raid1 gebeurt ook de ellende dubbel.
Virus op de een is een virus op de ander. En zo voorts.

[batjes]

Raid is voor continuïteit.

[Sfynx]

Dit dus, ik heb gewoon backups, maar als je d.m.v. RAID ook maar 1 keer het terugzetten hiervan kan vermijden en alles in bedrijf kan houden, dan heb je de kosten van die extra schijven er alweer uit gezien de tijd die je anders kwijt bent, al helemaal als je het e.e.a. bedrijfsmatig gebruikt.

En een rotte schijf kom je best vaak tegen als je iets 24/7 in bedrijf hebt en met veel schijven werkt.

[lordfragger]

Sowieso zou ik zo'n schijf niet als enkele schijf gebruiken als er ook maar iets of wat belangrijke data op staat.

Door de rebuild times en kans op leesfouten is een klassieke raid 5 opstelling ook niet meer interessant. Een meer moderne technologie, ZFS raidZ2 bvb is wel goed bruikbaar. Nadeel is dan wel dat je al minimaal 5 schijven nodig hebt om goedkoper te zijn dan een "simpele" mirror.

[flippy]

Als dat verhaal van leesfouten waar zou zijn (ik weet waar je dat idee vandaan hebt) dan zou je een URE krijgen elke keer als je een 8tb leest van een harde schijf. Dat gebeurt niet. Waneer heb je zelf nu voor het laatst een ure gekregen bij een gezonde schijf en hoeveel tb had je al gelezen in die tijd?

[beerendlauwers]

Er gebeurt heel veel error correction op de schijf, tussen de schijf en de controller, en op de controller

[flippy]

dat veranderd mijn vraag niet.

[Sfynx]

Er gebeurt heel veel error correction op de schijf, tussen de schijf en de controller, en op de controller

Dat zijn geen uncorrectable errors. De fouten die intern gecorrigeerd kunnen worden zijn niet zo interessant, dat gebeurt voortdurend en is onderdeel van de normale werking van schijven met de datadichtheden die we nu hebben.
Het is wel interessant om via S.M.A.R.T. te monitoren of bij dezelfde workload het aantal gecorrigeerde fouten een beetje stabiel blijft, als dat opeens significant stijgt is er wellicht een teken aan de wand, ook al is er nog geen uncorrectable error geweest. Ben je er toch net wat eerder bij met je reserveschijf.

Ik beschouw het als een leesfout als de schijf om gegevens gevraagd wordt en deze niet aan dit verzoek kan voldoen.

[Reactie gewijzigd door Sfynx op 26 juli 2024 21:35]

[lordfragger]

Die URE is inderdaad puur statistiek, maar als je gemiddeld gezien een of meer leesfouten krijgt per disk in je array bij een rebuild kan je daar toch gewoon niet op vertrouwen voor iets of wat belangrijke data?

Verder is de rebuild tijd van een array met laat ons zeggen 4 schijven van 12TB zo waanzinnig lang dat de kans relatief groot is dat, onder andere door de extra stress van een rebuild, een tweede schijf in je array de geest geeft. Dan is je data weg.

Je kan dit doemdenken noemen, maar als je al de moeite neemt om raid op te zetten ga ik ervan uit dat je data toch iets waard is. Als je goeie backups hebt EN de tijd om alles terug te herstellen van die backup is geen issue doe je maar, als dat wel uitmaakt gebruik je beter een technologie die beter geschikt is voor de huidige volumes.

[flippy]

leesfouten zelfs op grote arrays zijn zeldzaam. en als je een beetje array hebt draai je ook raid 6 met een hotspare. dus als er een drive uitvalt gaat de array direct rebuilden, heb je nog steeds 1 schijf "over" en hoef je alleen de kapotte schijf te vervangen voor een nieuwe hotspare. het risico dat je de hele array kwijtraakt is zeer klein en niet relevant in dagelijks gebruik. immers draai je ook backups en zoals nog altijd geld: raid is geen backup.

[Reactie gewijzigd door flippy op 26 juli 2024 21:35]

[ThinkPad]

Je zou inderdaad verwachten dat de koek een keer op is. De formfactor is na al die jaren nog steeds 3.5" dus ze moeten in dezelfde ruimte, meer data proppen. De kans op bitrot e.d. neemt dan enorm toe heb ik wel eens gelezen.

[jongetje]

Wat mij betreft niet. Een goede backup is veel belangrijker, zeker in een thuis situatie. Dan maakt het niet uit als je een paar dagen bezig bent een backup terug te halen. Als je een bedrijf bent ligt dit natuurlijk anders, dan is een Raid configuratie aan te raden, maar die kan ook niet zonder goede back-up!

[Clemens123]

Best meerdere kleine in Raid5 of Raid6 (of raido/volledige backup) als je wat redundantie wilt. En als er 1 kapot gaat is het minder kostelijk.

[Reactie gewijzigd door Clemens123 op 26 juli 2024 21:35]

[Tranquility]

Ik zou voor een NAS toch altijd voor Raid 1 (mirroring) of vergelijkbaar kiezen. Dan ben je niet meteen al je data kwijt als er één schijf dood gaat.

[stresstak]

Maar dat is nog steeds geen backup. Ook van een NAS moet je een backup maken, dus hoef je voor de veiligheid niet per se Raid te gebruiken.

[Tranquility]

Natuurlijk moet je altijd (zo veel als mogelijk is) een backup maken, maar met een mirroring systeem vang je al het grootste risico van dataverlies bij een defecte schijf af, want de kans dat beide schijven tegelijkertijd dood gaan is vrij klein.

[DropjesLover]

Zit er nog (veel) toekomst in dergelijke schijven? De verhouding lees/schrijf snelheid en capaciteit begint behoorlijk uit de pas te lopen. Eigenlijk beginnen traditionele HDD's de kant op te gaan van tape. Wordt nog wel gebruikt voor bulk-backups, maar dat is het dan ook wel...

Natuurlijk is flash-geheugen is nog steeds slecht beschikbaar, maar dat is tijdelijk van aard terwijl je dergelijke schijven (en systemen) toch voor meerdere jaren in investeert.

[Caayn]

Zolang rackspace duur blijft en HDDs voor hetzelfde bedrag vele malen meer opslagcapaciteit bieden zullen HDDs nog wel hun bestaansrecht behouden.

SSDs zijn nog steeds schreeuwend duur als je naar de opslagcapaciteit kijkt. Dit zal uiteraard verbeteren in de toekomst (en wordt al jaren geroepen) maar ik gok dat het nog wel even duurt voordat SSDs een soort gelijke €/GB verhouding kunnen bieden als HDDs.

[Tranquility]

Inderdaad, de prijzen van SSD's zijn de afgelopen twee jaar zelfs gestegen en zijn op dit moment stabiel en worden op het moment zeker niet goedkoper.

[Tweddy]

Als ik even naar de prijs kijk dan is vanaf 2TB een SSD te koop vanaf €0,26/GB terwijl een conventionele harddisk vanaf €0,025/GB te koop is. Een factor 10 verschil dus nog.
Dan kan ik me voorstellen dat voor bulkdata het investeren in 'oude' technologie nog te rechtvaardigen is. Pas wanneer die factor drastisch naar beneden gaat, is het afgelopen met de harddisk. Het einde is in zicht maar het kan nog wel even duren voor het echt zo ver is.

[Verwijderd]

Er zijn nog meer factoren dat alleen aan aanschafprijs die je mee moet nemen. Wat ik zie is dat DC's toch in vrij rap tempo de overstap naar SSD's maken (in mijn branche tenminste).

[Tweddy]

Als de prijs van SSD's snel gaat dalen, dan helemaal. Eenvoudiger productie, meer concurrentie.
De vraag is alleen of er nog steeds zo'n vraag blijft aan geheugen.

[Aikon]

Gelukkig is daar de SSD om e.e.a. op te vangen. Die gebruik je voor je actieve data en een hdd voor de data waar je niet vaak bij hoeft. Daarnaast blijven de schijven absoluut gezien wel sneller worden dus op zich prima bruikbaar.

[Fate_Neo]

Grappig feitje, als je de specifications op de website bekijkt en je kijkt naar capacity zie je het volgende:
Capacity (GB) 14

Dat is dan wel een hele kleine HDD niet waar?

[Gopher]

20 jaar geleden was dat een hele dikke schijf!

[stresstak]

.. en nu maak je van die 14 GB een backup op een usb-stick of een SD-kaartje..

[Verwijderd]

Deze schijf is perfect voor je minder belangrijke data of voor je minder belangrijke data naar de back-uppen.

[MD_DeeBee]

Mijn angst...als zo'n schijf de geest geeft, ben je in één klap best veel data kwijt.

[jongetje]

Ja, daarom moeten we nog steeds werken met diskettes...

Belangrijke gegevens moet je altijd backuppen of het nu een grote of kleine schijf is...

[Tranquility]

Als je mirroring (Raid 1 of vergelijkbaar) gebruikt hoef je daarvoor geen angst te hebben. De kans dat beide schijven tegelijkertijd dood gaan is heel erg klein, tenzij de bliksem o.i.d. bij je inslaat..

[Tweddy]

Of je nou veel of weinig kwijt bent maakt niet uit. Je moet natuurlijk nooit één schijf hebben maar een 2e (externe) als back-up.

[SuperDre]

Wordt als consument wel een beetje duur om verschillende drives aan te schaffen om in raid te zetten (vind zelf bv de 12TB voor 500 euro die vermeldt wordt best een consumenten prijs, maar niet om er meerdere tegelijk te hebben).

[DropjesLover]

Dit is geen consumenten-product
Er zullen er niet veel consumenten zijn die zo veel data op willen slaan en dat bewust niet in een RAID opstelling zouden doen. Dan maar 2 (of meer) kleinere schijfjes van bijv. 6TB à €240, met de zekerheid dat je je data nog hebt.

[jubeth]

Ooit van RAID over File System (RAID-F) gehoord? Aanrader, o.m. vanwege dat 'meerdere dezelfde disks tegelijk' argument. Of Tranparent RAID, ook leuk; http://wiki.flexraid.com/about/what-is-transparent-raid/

[ari2asem]

wat dacht je van snapraid?

http://www.snapraid.it/compare

dan zie ik dat snapraid veel beter is dan flexraid....gratis en silent error recovery....1 nadeel....je kunt er niet vanaf booten. je hebt altijd een draaiende windows of linux nodig. je kunt complete disk image van je OS erop zetten, maar als je OS-disk kaputt is, moet je windows opnieuw op kale hard disk installeren en daarna image copy van je vorige OS-disk benaderen

[jubeth]

Ik gebruikte snapraid voordat ik flexraid kende. Inderdaad prima spul hoor, maar ik had real-time nodig, en kreeg flexraid via werk cadeau, dus dat was op zich handig. Ze ontlopen elkaar verder weinig, flexraid is iets snappier in bediening, naar mijn mening. En het mergen van bestaande data op toegevoegde storage gaat wat overzichtelijker.

[ari2asem]

enig idee hoe het nu zit met silent error recovery in flexraid? hebben ze dat al inmiddels toegevoegd? want ik heb met beide geen enkel ervaring, nooit mee gewerkt. ik ga alleen af op wat snapraid zegt.

[Verwijderd]

Wanneer ik deze schijf gebruik voor audio opnamen, zal het geluid van de stemmen dan vervormd worden?

[Primuszoon]

daarna gewoon even door een stikstof filter halen en dan klinken ze weer normaal

[Tranquility]

Wel als je Donald Duck heet...

[Ravefiend]

Voor wat meer achtergrond informatie over de gebruikte techniek, zie deze white paper:

HGST Shingled Magnetic Recording + HelioSeal

[born2rule]

Waar ik dan wel benieuwd naar ben, zit die helium er naar 20 jaar ook nog in? Mijn ballonnetjes zijn namelijk na een paar weken 'leeg'