Seagate brengt 14TB-hdd's uit voor consumenten

Seagate heeft verschillende 3,5"-hdd's met een capaciteit van 14TB toegevoegd aan zijn assortiment. Het gaat onder andere om de BarraCuda Pro-uitvoering voor desktop-pc's en twee IronWolf-varianten, die bedoeld zijn voor in nassystemen.

De Seagate BarraCuda Pro 14TB heeft een toerental van 7200rpm en is voorzien van 256MB-cache. De sata-hdd haalt volgens de fabrikant snelheden tot 250MB/s. Volgens een review van AnandTech bestaat de nieuwe hdd net als de 12TB-variant uit acht pmr-platters in een met helium gevulde behuizing. De specificaties zijn in andere opzichten ook gelijk aan die van de 12TB-variant die een jaar geleden uitkwam.

Webwinkels bieden de BarraCuda Pro 14TB-hdd aan voor prijzen vanaf 540 euro. De prijs per gigabyte is daarmee ongeveer gelijk aan die van de 12TB-uitvoering, die momenteel te koop is voor ongeveer 458 euro.

Seagate komt ook met IronWolf- en IronWolf Pro-uitvoeringen met een capaciteit van 14TB. Deze 3,5"-hdd's bedoeld voor in nassystemen waren voorheen met een opslagcapaciteit van maximaal 12TB verkrijgbaar. De IronWolf-uitvoeringen zijn voorzien van aangepaste firmware voor gebruik in raid. De Pro-uitvoering heeft vijf jaar garantie, bij de reguliere uitvoering is dat drie jaar. Het IronWolf 14TB-model staat in de Pricewatch voor ongeveer 491 euro.

Naast de consumenten-hdd's introduceert Seagate een 14TB-hdd in de SkyHawk-serie die gericht is op videobewaking en de Exos X14 voor datacenters.

Reacties (167)

[Verwijderd]

Mooi dat er nog ontwikkeling zit in harde schijven. Blijft voor archief en opslag het beste medium. Hoewel als SSD's ook zo groot zijn en voor die prijs te koop zijn dan ga ik de voor en nadelen overwegen.


Zelf heb ik een NAS met 4 bays. Op websites stond destijds dat de maximale capaciteit 40TB was. Nu heb je harde schijven die groter zijn. Past dat gewoon in bestaande hardware of heeft het echt die limiet?

[Verwijderd]

Weet je zeker dat je dat wil? Als RAID een fout moet gaan oplossen kan je zo maar vele dagen aan het rebuilden zijn, waarbij er een groter kans op op problemen, waardoor je weet moet rebuilden, waarbij er weer een grotere..... zie je waar dat heen gaat? Daarom gebruiken data centra nooit van die grote schijven.

Er is maar een zeer beperkte markt voor dit soort drives.

[sdk1985]

Achterhaald concept. Tegenwoordig heb je self healing file systems en eventueel ook andere oplossingen als SHR en snapraid.

Snapraid werkt op filesystem level en elke schijf functioneert dus net als normaal. Je kunt hierdoor ook snel nieuwe schijven inbrengen en ook schijven (tijdelijk) aan andere systemen hangen. Repairs (bitrot) is een kwestie van enkele minuten. Systeem werkt op basis van een snapshot (sync) wat voor en nadelen heeft. Het nadeel is dat niet gesyncte data niet beschermd is. Het voordeel is dat bij een verwijdering/aanpassing van je bestanden je dit terug kunt zetten, zo lang er nog niet gesynced was. Bij een traditionele raid implementatie ben je dan al lang de klos. Extra voordeel van snapraid is dat het kosten efficient is. Met 1 parity disk kun je 3 a 4 schijven beschermen. Met twee parity disk nog veel meer. Bovendien kun je ook prima verschillende schijven inbrengen. Zo heb ik naast 8 TB drives ook nog enkele 3 TB drives onder de bescherming van snapraid geplaatst. Het is niet zo dat je dan 5 TB verliest op de grotere schijven. Qua security kun je het zo gek maken als je zelf wilt, double, triple, quad parity, enz.

http://www.snapraid.it/

Het SHR van Synology lijkt hier verder veel op. Ook die oplossing ondersteund het mixen van schijven van verschillende groottes. https://www.synology.com/..._Synology_Hybrid_RAID_SHR

[Reactie gewijzigd door sdk1985 op 25 juli 2024 01:50]

[D0phoofd]

Zo heb je ook ZFS. ZFS is een Software matige RAID die gebruikt maak van de RAM (ECC) als cache. Zelf heb ik er ook veel over gelezen, nooit gebruikt echter. Hoor hier wel veel lof over bij de mensen van /r/datahoarder .

Ook kun je ZFS weer 'uitbreiden' met Gluster (spreiden over meerere hosts). Zo zijn er nog een tal andere oplossingen zoals CEPH, wat ook gebruikt word door CERN (Op PetaByte-schaal!). Ceph is wel meer gericht op grotete clusters en werkt beter met óf (paar) hele snelle hosts (snelle disks en netwerk (20Gbit)), óf heel veel hosts met (dan maakt je set up ook niet zo heel veel meer uit). Ceph vond ik persoonlijk dan weer interessant gezien het data opslaat alsof iedere server één disk is. Een soort fysieke RAID + onderliggende host zijn eigen redunancy.

Enfin, ik dwaal af. Persoonlijk denk ik dat het de hardware RAID een beetje aan het verouderen is. RAID (Redundant Array of Inexpensive Disks), wordt grappig genoeg, helemaal niet gebruikt icm goedkope disken. (Thanks Knightwolf!)
Het schaalt moeilijk (je kan niet zomaar je array even aanpassen). En zijn inderdaad de rebuilds, Battery backups en/of flash backups het niet waard.

Microsoft heeft ook al Storage Spaces op Windows geïntegreerd. En heb je ook Storage Spaces Direct voor de Server (datacenter), wat lijkt op CEPH. Dit werkt allemaal zonder hardware raid. Directe pass-through. En snel jongûh!

[Reactie gewijzigd door D0phoofd op 25 juli 2024 01:50]

[Jacco011]

ZFS kent veel problemen. Zo is het niet mogelijk om een pool te vergroten. ZFS is leuk voor bedrijven, maar voor thuis te duur tegenover snapraid en raid 5-6. Daarbij moeten alle drives in ZFS draaien waarbij dit met snapraid niet het geval is. Verlies je in ZFS alle parity dan is alle data weg, bij snapraid verlies je dan alleen de data die op die ene disk stond en de rest wat draait draait rustig verder. Snapraid versprijd de data niet over alle disks waardoor je je minder plek kwijt bent maar als die ene parity disk weg is, dan loop je op hete kolen. Daarom gebruiken de meeste 2 parity HDD op de gehele NAS. Met snapraid kun je ook verschillende HDD capaciteiten samenvoegen (parity HDD's moet gelijk aan de grootste disk zijn)

edit: alle parity, aanvulling parity snapraid

[Reactie gewijzigd door Jacco011 op 25 juli 2024 01:50]

[Rolfie]

Dat is geen probleem, maar een eigenschap.

[Xander2]

Mmm. Maar waarom wil je thuis iets anders dan JBOD/striping? Bewerk je video's?

[wild_dog]

Zoals je al zij, video bewerking.
Wat meer algemeen nuttig: genetwerkte back-up drive voor alle apparaten in huis. Gooi em in RAID 5/6, wijs alle computers in huis naar een map in die array, klaar.
Lange rebuild tijd vanwege RAID 5/6? Geen probleem, is maar een paar keer per week nodig.

Maar waarom wil je thuis iets anders dan JBOD/striping?

In dit geval omdat je met JBOD niet optimaal gebruik kan maken van je schijven. Stel in JBOD doet PC1 backup naar schijf 1, PC2 naar schijf 2, en laptop naar schijf 3. PC1 is een enorme backup en schijf 1 is vol. schijf 2 beetje vol en schijf 3 bijna niet gebruikt. PC1 kan geen gebruik maken van overruimte op schijf 3.
Waarom niet striping? Dit is je back-up, je wilt absoluut zeker weten dat hij werkt ook als hij niet vaak nodig is. Striping + schijf crash tijdens herstellen vanaf back-up = table flip.

[Reactie gewijzigd door wild_dog op 25 juli 2024 01:50]

[dcm360]

Hoe verlies je data als je alleen de parity kwijtraakt dan? Want de parity is er juist voor om er voor te zorgen dat er één (of meer) schijven kunnen wegvallen zonder dataverlies.

[Tuxwielder]

"ZFS kent veel problemen. Zo is het niet mogelijk om een pool te vergroten."

Dat is onjuist. Je kunt een ZFS pool op twee manieren vergroten:

• Het vervangen van alle disks door grotere disks
• Het toevoegen van een set disks (VDEV) aan de bestaande sets in de pool

Het laatste lijkt op het "aan elkaar plakken van meerdere RAID sets".

Verwijderen van disks uit een pool was tot voor kort niet mogelijk. In Solaris 11.4 ZFS kan dat tegenwoordig ook (volgens mij nog niet in OpenZFS).

[Knightwolf]

RAID staat voor Redundant Array of Independent Disks. Niet 'goedkope' schijven maar 'onafhankelijke'. Dat kunnen goedkope maar ook dure zijn.

[D0phoofd]

Wow!
Dan heb ik ooit ergens een grapje van iemand nooit ge-fact-checked.
Of er heeft een bit-flip in m'n hoofd plaatsgevonden

[Jaco69]

Oorspronkelijk was het Redundant Array of Inexpensive Disks.

Array of Independend disks slaat ook nergens op maar dat was om het toch RAID te houden i.p.v. RAD

[theblindman]

Eigenlijk hebben jullie allebei gelijk Zie ook Wikipedia: https://en.wikipedia.org/wiki/RAID

[dasiro]

volgens SNIA:

RAID

[Storage System] Acronym for Redundant Array of Independent Disks.

The phrase Redundant Array of Independent Disks is adapted from the 1988 SIGMOD paper A Case for Redundant Arrays of Inexpensive Disks. In modern systems, RAID techniques are often applied to storage devices or technologies other than disk.

dus officieel is het enkel independent, aangezien zij de standaard hebben opgesteld

[sympa]

Block-level RAID is inderdaad niet zo slim. Een systeem met gedistribueerde parity en ook gedistribueerde spare is veel handiger.
Stel je hebt 8 disks van 1 GB elk. Je hebt 6 GB data.
In klassiek RAID4 heb je 6 disks met data, 1 disk met parity, en 1 disk spare. Als een data of parity disk kapot gaat dan gaat het systeem alle disks lezen en de gereconstrueerde data schrijven op de spare disk. Nadelen: elke write naar de RAID gaat naar 1 van de disks - maar moet ook naar de parity disk. De parity disk wordt druk met writes. En: een kapotte disk herstellen duurt lang, want alle writes moeten naar de spare disk.
In klassiek RAID5 heb je 7 disks, met data en parity gemengd. Writes komen op 1 disk met data en 1 andere disk met parity, en worden zo goed verdeeld over de disks. Een kapotte disk herstellen betekent nog steeds dat alle data naar 1 disk wordt geschreven.
Een systeem met distributed spare (EMC2 Isilon bijvoorbeeld) werkt op filesystemniveau. Voor een file worden datablokken, parityblokken en spareblokken toegewezen. Als er nu een disk stukgaat leest het systeem voor elke file de data- en paritydisken en schrijft het spare block van die file. Omdat elke file de spare blocks op een andere disk heeft worden de writes van het herstellen van alle disks over de overgebleven 7 disks verdeeld.
Als je met RAID5 1 leesfout hebt tijdens de reconstructie is de array corrupt. chkdsk time. Met RAID6 wordt dat vermeden: dubbele parity maakt het systeem beter: als er 1 disk kapot is, is er nog een tweede parity aanwezig.
Maar bijvoorbeeld dat Isilon is nog robuuster: metadata wordt beter beschermd dan data (bijvoorbeeld 4 keer opgeslagen) en als het herstellen van een bestand mislukt is alleen dat bestand defect. Overigens laat dat systeem toe om vrij te kiezen hoeveel data, parity en spare blocks er zijn per file terwijl het aantal disks 'eronder' live kan worden uitgebreid.

[GekkePrutser]

ZFS is wel heel iets anders.

Bij Raid-Z moet je namelijk wel dezelfde grootte HD's hebben, bij Snapraid niet. Ook heb je bij ZFS geen mogelijkheid om een Raid-Z pool uit te breiden wanneer je deze hebt gemaakt.

ZFS is wel een stuk veiliger dan Snapraid (al komt het in de buurt als je btrfs onder Snapraid gebruikt), maar Snapraid is veel flexibeler.

Ik heb beiden gebruikt maar ik had me met ZFS al heel snel in een hoek geverfd waardoor ik 6x schijven had moeten vervangen om mijn capaciteit te vergroten, wat neer kwam op een hele nieuwe array kopen. Met Snapraid kan ik er eentje bijkopen (van de op dat moment meest gunstige capaciteit voor prijs/GB) als ik meer ruimte nodig heb en toch redelijk veilig zijn.

Nadeel is wel dat syncen ja, maar dat is ook wel handig op zich, de meeste bestanden op mijn NAS zijn toch in rust. Dan is het gelijk een backup voor per ongeluk verwijderen van een bestand (niet van alles natuurlijk!)

[Reactie gewijzigd door GekkePrutser op 25 juli 2024 01:50]

[Tuxwielder]

"Ook heb je bij ZFS geen mogelijkheid om een Raid-Z pool uit te breiden wanneer je deze hebt gemaakt."

Wederom onjuist, zie (als je wilt) mijn reactie boven (@Jacco011 • 12 september 2018 12:53)

[GekkePrutser]

Wat je daar noemt is geen uitbreiding van de pool.

Het toevoegen van een vdev is geen uitbreiding van de pool, en geen goede oplossing want die heeft zelf zijn aparte redundantie disk nodig. Het vervangen van alle drives maakt de pool qua bytes groter maar aantal drives niet, en het is bovendien een enorm dure manier om dit te doen omdat je alle drives moet vervangen voordat je van de nieuwe capaciteit gebruik wil maken. Dat was precies het voorbeeld dat ik al aanhaalde hierboven.

Mijn punt blijft dat je geen drive toe kan voegen aan een zpool en dat is heel onhandig als je flexibel wil zijn.

[Tuxwielder]

<code>
# zpool status
...
pool: tank
state: ONLINE
...
config:

NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz3-0 ONLINE 0 0 0
c0t5000C500564B0893d0 ONLINE 0 0 0
c0t5000C5005649A917d0 ONLINE 0 0 0
c0t5000C5007F41DA77d0 ONLINE 0 0 0
c0t5000C5005649AA7Fd0 ONLINE 0 0 0
c0t5000C5005649CDEBd0 ONLINE 0 0 0
c0t5000C5005649F55Fd0 ONLINE 0 0 0
c0t5000C500564A110Bd0 ONLINE 0 0 0
raidz3-1 ONLINE 0 0 0
c0t5000C500564A14CBd0 ONLINE 0 0 0
c0t5000C500564A1BCFd0 ONLINE 0 0 0
c0t5000C500564A490Bd0 ONLINE 0 0 0
c0t5000C500564A85F7d0 ONLINE 0 0 0
c0t5000C500564A8DEFd0 ONLINE 0 0 0
c0t5000C500564A9347d0 ONLINE 0 0 0
c0t5000C500564A94CBd0 ONLINE 0 0 0
raidz3-2 ONLINE 0 0 0
c0t5000C50062FA41DBd0 ONLINE 0 0 0
c0t5000C500564AA36Bd0 ONLINE 0 0 0
c0t5000C500564AD5AFd0 ONLINE 0 0 0
c0t5000C500564AE73Bd0 ONLINE 0 0 0
c0t5000C500564AF367d0 ONLINE 0 0 0
c0t5000C5008DC54B6Bd0 ONLINE 0 0 0
c0t5000C500638ACBDFd0 ONLINE 0 0 0
raidz3-3 ONLINE 0 0 0
c0t5000C5005673E773d0 ONLINE 0 0 0
c0t5000C5008DA6F423d0 ONLINE 0 0 0
c0t5000C50056A2E1EBd0 ONLINE 0 0 0
c0t5000C5008DA6E7A7d0 ONLINE 0 0 0
c0t5000C50056A2FA0Fd0 ONLINE 0 0 0
c0t5000C50056A2FAAFd0 ONLINE 0 0 0
c0t5000C50056A302AFd0 ONLINE 0 0 0
raidz3-4 ONLINE 0 0 0
c0t5000C50056A3134Bd0 ONLINE 0 0 0
c0t5000C50056A337DBd0 ONLINE 0 0 0
c0t5000C50056A5B027d0 ONLINE 0 0 0
c0t5000C50056AEF7ABd0 ONLINE 0 0 0
c0t5000C50056B53B2Bd0 ONLINE 0 0 0
c0t5000C50056BADFBFd0 ONLINE 0 0 0
c0t5000C50056BC75B3d0 ONLINE 0 0 0
logs
c9t5000A72A30077587d0 ONLINE 0 0 0
</code>

Als je de disks hebt, kun je dit prima uitbreiden met een "raidz3-5". Ik denk dat het handig kan zijn als je de docs er even bijpakt...

[GekkePrutser]

Ja, maar dat is een hele pool erbij maken. Dat bedoel ik dus niet. Ik bedoel het uitbreiden van een (1) disk aan een bestaande pool. Bijvoorbeeld in dit geval een enkele disk toevoegen aan raidz3-0.

Voor zover ik weet kan dat nog steeds niet. Zou ook lastig zijn omdat de hele parity opnieuw berekend moet worden, maar het zit er gewoon niet in.

Maar dit is dus de reden waarom ik van ZFS naar Snapraid/mhddfs ben gegaan. Dan kan ik er gewoon een schijf bij drukken.

[Tuxwielder]

Aha, je vindt dat een VDEV een pool is. In ZFS terminologie is de pool samengesteld uit VDEVs, wat je inderdaad in oude termen zou kunnen vergelijken met een individuele RAID-set. De pool zou je dan (in de verte) kunnen zien als een aggregatie van VDEVs (dus een soort RAID0 van RAIDs).

Binnen een VDEV kun je inderdaad niet eenvoudig uitbreiden, maar dat is ook niet heel zinnig. Als je kiest voor 2-weg mirror sets, kun je echter wel per 2 disks uitbreiden (een zinnige keuze als je voor IOPS wilt optimaliseren).

ZFS is inderdaad niet per se ontworpen voor kleiner gebruik, hoewel het prima kan werken in je thuisomgeving, zolang je maar bereid bent om in sets van disks uit te breiden (ik heb zelf nooit anders gedaan ).

Voor grotere systemen is het redelijk ideaal, totdat je over (veel) meerdere servers wilt uitbreiden (dan wordt CEPH interessant of iets als pNFS of (op hoger abstractieniveau) iRODS.

[GekkePrutser]

Okee, ja het is alweer een paar jaar geleden dus ik had inderdaad de vdev en zpool door elkaar gehaald.

Maar inderdaad, ik zou aan een RAID set een disk toe willen voegen. Dat kan met Snapraid dus wel, al raak je dan wel je parity helemaal kwijt, maar dat is niet zo erg, die kan je opnieuw opbouwen.

Niettemin is ZFS een pro oplossing en Snapraid redelijk houtje-touwtje, maar de flexibiliteit heb ik gewoon nodig.

Ik heb nu 8 schijven (2x HP Microserver G8 met Fibre Channel ertussen om het tot 1 filesystem te maken), elke keer als ik extra ruimte nodig had dan kocht ik een schijf erbij. De laatste tijd vervang ik de eerste schijven (zijn nog 3/4TB exemplaren) door die van 8 of 10TB. De oude schijven gaan dan in mijn backup doos (ik gebruik meerdere schijven als een soort sequentiele backup tapes). Op die manier kan ik heel goed schalen zonder in 1x een enorme uitgave te hoeven doen. De nieuwe schijven gooi ik in 1x vol met de data van de oudere omdat dat meestal shingled schijven zijn en dus niet zo geschikt voor random R/W dus die gebruik ik vooral voor de oude statische data.

[Reactie gewijzigd door GekkePrutser op 25 juli 2024 01:50]

[Q]

Ceph is zeer interessant als storage platform. Ik heb een introductie geschreven over Ceph op mijn persoonlijke blog (geen spam) voor wie meer wil weten.

http://louwrentius.com/un...rce-scalable-storage.html

Ceph is echter niet echt voor thuis, maar meer voor datacenters. die 14 TB schijven zijn ideaal voor ceph want in grote clusters is het geen enkel probleem dat zo'n schijf er uit gaat. Die kan daar veel beter tegen dan reguliere RAID.

[Reactie gewijzigd door Q op 25 juli 2024 01:50]

[D0phoofd]

Ik weet er alles (nou ja... redelijk wat) van af. Thuis heb ik op een 10gbit netwerk eens lopen klooien met Ceph. 3 servers. Ssd journals (dat was Pre- bluestore of hoe het ook heet), en 6 osd’s per host. Dat ging toch met 2GB/s seq lezen. Het was wet klooien en testen maar stak een veel van op.

Je ziet inderdaad grotere hosting providers block-storage opzetten (OVH, DigitalOcean) dat is gegarandeerd op Basis van Ceph. Er interessant inderdaad. Beetje schijven uit je server trekken. Data was instant doorgeschoven. VM’s bleven online etc.

[Reactie gewijzigd door D0phoofd op 25 juli 2024 01:50]

[Q]

Leuk om te horen, Ik heb zelf alleen in mijn speeltuin met Ceph gespeeld. Met HDD only was het zelfs met 16 disks (oude 1 TB disks) niet super snel. Waarschijnlijk moet je veel meer HDD disks hebben om lekkere performance te krijgen vanwege de replicatie op je I/O performance.

Throughput komt wel goed, maar random I/O op HDD is niet altijd lekker.

[D0phoofd]

SSD Journals deden de truc bij mij. De 6 OSD´s per host bij mij waren ook HDD´s (10k sas tho). Dan nog, Random opdrachten waren wat trager. Desalniettemin was ik behoorlijk impressed.

[Verwijderd]

Er hoeft maar 1 fout in het rebuilden zitten vn de database en GG. beter een backup buiten de NAS om op aparte HD's.

[Marcelvdsteen]

Waarom zal een data centrum deze grote niet gebruiken, wij hebben in ons de enkele synology’s met 10 TB disken voor backup’s van klanten. Deze worden via bijv arc serve Udp van hun eigen Nas naar die van ons gerepliceerd . Deze zijn ook weer gespiegeld aan elkaar

[MrHarry]

ik ben op dit moment mijn 4x3tb aan het upgraden naar 4x10 tb. En de NAS is per disk ongeveer 4 dagen bezig... Dus zoals Falconhunter zegt...als het groter wordt dan duurt het ook stukken langer!

[hooibergje]

Zo snel gaan harde schijven nou ook weer niet stuk. De kans dat er tijdens het rebuilden precies een schijf stuk gaat is niet zo groot. Je moet alleen in het achterhoofd houden dat RAID geen backup is. Want je RAID controller kan ook stuk gaan...

[bantoo]

Bij 2TB was ooit een daadwerkelijk limiet waar veel hardware niet overheel kon. Zelfde voor SD toen de SDHC voor SDXC overgang was op 32GB. Het lijkt me sterk dat je NAS een limiet heeft.

[raschaoot]

De NAS zal echt wel een limiet hebben, maar het is onwaarschijnlijk dat hij het ooit zal bereiken. Die NAS is tegen die tijd vast al vervangen.

Harde limieten zitten meestal in de gebruikte methode voor adressering van de data. In oude 32-bit systemen zat daardoor vaak een limiet op de hoeveelheid adresseerbaar geheugen (4GB) en opslag (512 bytes per sector geeft 2,2TB).

Zelfs als de gebruikte protocollen eindeloos rekbaar zijn, loop je op een gegeven moment tegen de limieten van de hardware aan. Maar je zal al veel sneller de impact op je snelheid merken. Dat is een reden voor de overstap naar 64-bits.

SDXC is ook weer gelimiteerd op 2TB, het gaat alleen wel even duren tot we dat limiet gaan voelen. Al gaat het de afgelopen tijd wel ineens erg hard

Wat betreft HDD's hoef je pas weer te letten op de limieten wanneer we in de EB's gaan werken. Windows 10 ondersteund bijvoorbeeld maximaal 94EB.

[Reactie gewijzigd door raschaoot op 25 juli 2024 01:50]

[stresstak]

Bij 2TB was ooit een daadwerkelijk limiet waar veel hardware niet overheel kon.

Niet alleen hardware, mijn XP doet ook niet groter.

Met 14 TB hebben de makers er kennelijk nog vertrouwen en is er een markt voor.

[Durandal]

Mooi dat er nog ontwikkeling zit in harde schijven. Blijft voor archief en opslag het beste medium.

Ik weet het niet hoor. Disks die je niet gebruikt slijten ook. Ik ben toevallig al mijn disks aan het testen en bijna alle disks ouder dan een jaar of 5 die op de plank lagen zijn kapot, of kapot aan het gaan.
Ik zou het niet als archief gebruiken, tenzij actief online in een NAS/Server met ZFS en monitor software.

Je kan beter iets met flash gebruiken, of DVDs oid.

[Pure_evil]

Dan weet ik niet wat jij met je disks uitvreet hoor. Heb hier persoonlijk nog een hele reeks hdd's liggen en +- jaartje geleden ging zelfs de oudste (1.2gig van rond de eeuwwisseling ergens) nog steeds.

edit: lees net je laatste regel, meen je dat nou of ben je aan het trollen?!

[Reactie gewijzigd door Pure_evil op 25 juli 2024 01:50]

[Crim]

Wat voor NAS heb je? Misschien waren de grootste HDD's toen 10TB.

[Verwijderd]

Ik heb een Synology Ds918+, van dit jaar.

[Crim]

Daar kan je inderdaad probleemloos 14TB schijven in gebruiken. De productinformatie is ook al bijgewerkt naar 12TB HDD's https://www.synology.com/nl-nl/products/DS918+#specs

[Verwijderd]

Bedankt voor je reactie. Jammer dat ik je geen plus vote kan geven. Maar ik waardeer het in ieder geval wel.

[Verwijderd]

Flashgeheugen is gebaseerd op het vasthouden van een lading in een condensator. De condensator loopt langzaam leeg. Hoe snel het leeglopen gaat weet ik niet maar voor lange termijn opslag lijkt een hardeschijf me beter.

Wikipedia zegt het volgende
https://en.wikipedia.org/...ival_or_long-term_storage

"Archival or long-term storage
It is unclear how long flash memory will persist under archival conditions – i.e., benign temperature and humidity with infrequent access with or without prophylactic rewrite. Anecdotal evidence[specify] suggests that the technology is reasonably robust on the scale of years.[citation needed] Datasheets of Atmel's flash-based "ATmega" microcontrollers typically promise retention times of 20 years at 85 °C (185 °F) and 100 years at 25 °C (77 °F).[82]

An article from CMU in 2015 writes that "Today's flash devices, which do not require flash refresh, have a typical retention age of 1 year at room temperature." And that temperature can lower the retention time exponentially. The phenomenon can be modeled by Arrhenius law.[83]"

[Verwijderd]

Hier nog een interessant artikel m.b.t. de retentie van ssd's:

https://www.anandtech.com...-about-ssd-data-retention

[Reactie gewijzigd door Verwijderd op 25 juli 2024 01:50]

[Verwijderd]

Ik ben een SSD aan het overwegen. Wat zijn de grootste nadelen van een SSD?

[Verwijderd]

Vooral de prijs per gigabyte. Ze zijn nog steeds duurder dan normale harde schijven.

[DropjesLover]

SSD is duur maar erg snel, dus starten OS en spellen laden.
HDD is goedkoop maar langzaam (maar zat snel genoeg voor 4k films overigens), dus voor goedkope opslagruimte (foto's, films, etc).

[Verwijderd]

Voornamelijk de hogere prijs dus. Verder geen andere nadelen? Ik heb wel eens gelozen over de levensduur van SSD's, dat deze korter zou zijn of zo?

[DropjesLover]

De eerste generaties ja. Tegenwoordig absoluut geen issue meer.

Hogere prijs is een fors hogere prijs, kijk maar in de pricewatch (en sorteren op €/Mb).

[Verwijderd]

Thanks voor de info!

[Verwijderd]

Zover ik weet niet, heb ook een "oude" nas van 4 x 6TB max.
Onderhand zit daar in 2 x 6TB, 1x 8TB en 1x 10TB .

[Verwijderd]

Zelf heb ik een NAS met 4 bays. Op websites stond destijds dat de maximale capaciteit 40TB was. Nu heb je harde schijven die groter zijn. Past dat gewoon in bestaande hardware of heeft het echt die limiet?

Ik zou eens beginnen met het zoeken op fora op basis van jouw typenummer. Of gooi het op Tweakers eens in de groep en wacht op reacties.
Mocht daar niets uitkomen dan kun je altijd nog 'gewoon proberen'; niet alleen disks er in stoppen maar ook vol pompen.

Bij mij draait een inmiddels toch wel antieke Readynas (ooit een 10 in de review gekregen). Oorspronkelijke specs spraken voor zover ik me kan herinneren van een max van 2TB per disk. Draait inmiddels al wel een paar jaar zonder problemen met 4TB disks.
Niet supported, wel werkend.

Meer on topic:
Ik zit wel een beetje dubbel in de reactie op nieuws als dit. Natuurlijk is het prachtig dat de technische mogelijkheden verder opgerekt blijven worden, maar de vraag is wat mij betreft hoe ver je moet willen blijven gaan, nu er toch wel duidelijk bewezen betere technieken zijn waar voor zover ik weet geen nadelen aan zitten, anders dan de prijs. Ergens moet een snijpunt komen waarbij mechanische disks qua prijs/bit niet meer kunnen concurreren met SSD's, en dan is het toch echt wel klaar met deze ontwikkeling denk ik zo?
Ik kan me zo voorstellen dat als iedereen zich op SSD's zou storten en mechanische schijven laat voor wat het is dat de prijs voor SSD's ook sneller (nog verder) zal dalen. Maar misschien is dat ook wel het enige wat de huidige markt in stand houdt: behoud van investering in productie-faciliteiten.

[Christoxz]

Zou je niet liever dan 2x7tb(of welke aantal dan ook) willen gebruiken? Als er een uitklapt heb je in iedere geval nog de helft van je data?

[Durandal]

Zou je niet liever dan 2x7tb(of welke aantal dan ook) willen gebruiken? Als er een uitklapt heb je in iedere geval nog de helft van je data?

Maar de kans dat er iets klapt is ook twee keer zo groot. En dat is als je losse disks gebruikt.
Als je ze in RAID-0 aan elkaar striped gaat het twee keer zo vaak fout maar ben je wel alles kwijt als het dan fout gaat.

Je moet wat redundantie inbouwen.

[Xander2]

.

[...]

Maar de kans dat er iets klapt is ook twee keer zo groot. En dat is als je losse disks gebruikt.
Als je ze in RAID-0 aan elkaar striped gaat het twee keer zo vaak fout maar ben je wel alles kwijt als het dan fout gaat.

Je moet wat redundantie inbouwen.

JBOD

Als disk A 1% kans heeft op falen en disk B 1% kans, is de kans dat een disk uitvalt 1%. Niet 2%.
De kans dat beide disks gelijktijdig falen is dan 1% x 1% = 0,01% en daarmee vele malen kleiner dan dat 1 disk faalt.

[Durandal]

Ik zei RAID-0, niet? Ik zei geen JBOD.

Overigens gaat dat JBOD verhaal van je ook niet op want dat doe je alleen als je er een volume van maakt;

JBOD (abbreviated from "just a bunch of disks/drives") is an architecture using multiple hard drives exposed as individual devices. Hard drives may be treated independently or may be combined into one or more logical volumes using a volume manager like LVM or mdadm; such volumes are usually called "spanned" or "linear | SPAN | BIG".[2][3][4] A spanned volume provides no redundancy, so failure of a single hard drive amounts to failure of the whole logical volume.

[Xander2]

Je reageerde op christiix die het had over 2 losse drives.
Geen notie van een RAID oplossing, maar JBOD in klassieke definitie (zonder spanning).

[ajolla]

Ik heb een keer m'n (Maxtor) HD gecrashed gezien. Gelukkig had ik een backup op een andere HD gemaakt.
Helaas was dat ook een Maxtor die kapot ging toen ik probeerde m'n data te herstellen...

[bantoo]

Nee en ik snap ook niet waarom iedere keer iedereen met dit soort logica aan komt zetten bij een nieuwe grote HDD introductie.
Als iemand uberhaupt iets om zijn data geeft moet er een backup zijn. Het percentage van je data die je verliest doet er niet echt toe, ieder doel anders dan 0% is onpraktisch. Twee drives in een systeem is ook niets meer dan een uptime verhoging in het beste geval. Er is nog steeds geen enkele backup zolang de data op het systeem blijft.

[psychodude]

Het ligt er uiteraard maar net aan wat voor een data het betreft. Voor het installeren van mijn gehele steam catalogus heb ik bijvoorbeeld echt geen eigen backup nodig. Maar is het wel zo fijn dat bij een hdd failure ik niet alles in één klap 'kwijt' ben. Hier kwijt uiteraard als een relatief begrip, op niets anders neerkomend dan opnieuw te moeten downloaden.

Voor wat betreft mijn eigen bluray rips vind ik het dan wel weer zo fijn om dit op een raid configuratie opgeslagen te hebben. De helft kwijt is namelijk aanzienlijk wat werk in het opnieuw rippen. Toch vind ik het niet nodig om verder te gaan dan dat. De bron heb ik tenslotte nog.

Vakantiefoto's en anderszins privéfoto's daarentegen, die staan niet alleen op de NAS in een raid configuratie, maar ook nog eens op een tweetal desktops in huis en daarbovenop in de cloud opgeslagen. Bij verlies zijn deze namelijk onvervangbaar.

Zo blijft het bij dataopslag voor consumenten doeleinden altijd de vraag, ben je bereid de data kwijt te raken, dan wel met wat voor een moeite of gemak kun je deze data weer terug krijgen.

Verder vind ik qua hdd grootte keuze vanuit consumenten perspectief het persoonlijk in ieder geval nog wel handig om schijven een doel te geven. Dit formaat schijven belandt namelijk toch al snel binnen een NAS. En gezien de leessnelheid van HDD's toch een beperkende factor is probeer ik hierin zelf toch snel te voorkomen dat te veel systemen in huis aanspraak maken op één HDD tegelijk.

[sdk1985]

Kijk eens naar https://www.snapraid.it/ . Met 1 parity disk kun je al je data beschermen.

[SuperDre]

Maarja, ga even 14TB backuppen.....

[dcm360]

Dat is nu toch ook niet wezenlijk anders dan 2TB backuppen in 2008?

[ASS-Ware]

Maarja, ga even 14TB backuppen.....

Je backupt toch alleen de verschillen en niet elke dag 14TB?

[Xander2]

Twee drives in een systeem is ook niets meer dan een uptime verhoging in het beste geval.

Twee drives in RAID-1 is betrouwbaarder dan een single disk. Backup heeft een hogere latency.

[ajolla]

tarsnap(.com) is een goede backup, je moet alleen je keys niet verliezen.

[g0tanks]

Of je gebruikt 2x14TB

[CriticalHit_NL]

Dat, maar het kost natuurlijk wel wat.

[Megalodon86]

Je weet dat ze dit al roepen sinds de 20MB harde schijf?

[CriticalHit_NL]

Inderdaad, elke keer hetzelfde excuus.

Natuurlijk kan je er veel meer op kwijt en dus netto meer kwijtraken, maar aan de andere kant sommige dingen worden dezer dagen zo ruimte verslindend dat het ook wel weer redelijk meevalt.
Ligt ook compleet aan wat je er allemaal op wilt zetten.

Ga je een 20MB schijf vullen met ~2.000.000 tekstbestandjes of een 14TB schijf vullen met video's van 10-50GB per stuk wat dus neerkomt op 280 tot 1400 video's.

Spellen hedendaags willen soms al de 100GB overschrijden, ik meen dat FFXIV zelfs al 140GB kan verbruiken met 4K texture pack.
Veel meer spellen willen overigens al de 50-70GB overschrijden, de stap naar 100GB per stuk zal dus niet erg lang meer op zich laten wachten, ga je daar installatie back-ups van maken omdat je internet te traag is en vanaf de DVD ook urenwerk is om te installeren dan is zo'n beetje opslag wel wenselijk.

[Lip]

Ik heb daarvoor de oplossing, nooit meer spelletjes spelen.

[WarriorXK]

Voor dezelfde reden dat je geen 4x 500GB koopt ipv een 2TB hdd, het is niet praktisch, als jij je data veilig wilt houden moet je sowiso een backup maken van je harde schijven.

[Jaco69]

Zou je niet liever dan 2x7tb(of welke aantal dan ook) willen gebruiken? Als er een uitklapt heb je in iedere geval nog de helft van je data?

Ja en dan deze 14TB schijf voor de backup.

[Locke_]

Mijn NAS is nu al een eeuwigheid bezig met een rebuild als er een disk wordt vervangen. Dat wordt met deze grootte alleen maar erger.

Desondanks natuurlijk een mooie ontwikkeling, professioneel zie je ook al dat fabrikanten de 10k en 15k SAS disken laten vallen voor een combinatie van SSD en grote SATA (NL) disken.

[Blokker_1999]

Rebuilden wordt daarom vaak al niet meer gedaan. Een wipe en een cleane array. Daarna gewoon backup terugzetten. De RAID heeft dan als voordaal dat je niet direct alle functionaliteit verliest maar de heropbouw kunt inplannen.

[CaptainCapslock]

Zou het terug kopiëren van de data in het beste geval niet minimaal even lang duren?

[supersnathan94]

Langer. In principe heb je met een back-up terugplaatsen ook nog eens dat je überhaupt niet bij de data kan omdat je er helemaal niets meer hebt staan. Daarnaast ben je een factor x meer data aan het verplaatsen.

Hot spare disks of redundantie van het gehel systeem is dan dus ook vele malen sneller, maar wel significant duurder.

[blinchik]

Uh? Waarom zou je een wipe doen als er een disk faalt ? Op dat moment is je storage nog online (werken er dus misschien ook gebruikers op), en op dat moment kan je de situatie "herstellen". Het eventueel terugcopieren of terugzetten van backup zal even lang duren dan een rebuild, en dan heb je bovendien nog eens downtime ook.

[Verwijderd]

Wij hebben wat backup systemen met 8TB schijven er in. Een rebuild kan maar zo een dag duren. Gedurende die tijd mag er nog een schijf stuk gaan, maar de kans is ook groter dat er iets stuk gaat door de rebuild. Ofwel: niet geschikt voor live productie systemen.

Daarvoor heb je systemen met softraid en hw redundancy voor een complete unit (mirror).

Waarom je een wipe en een restoren zou doen in plaats van een rebuild snap ik niet. Dat zal altijd trager zijn, tenzij je een systeem hebt met heel veel opslag waar bijna niets op staat

[sympa]

Daar hebben ze dubbele parity (RAID6) voor bedacht. Omdat 'normale' disks nogal eens een read error produceren als je ze 'helemaal doorleest'.

[The Third Man]

Dat is eigenlijk net zo onhandig en lost het probleem niet op (degrading tijdens rebuild) . Een beetje als twee reservewielen meenemen. Vandaar dat men tegenwoordig redundantie op FS niveau doet en eventueel over meerdere hosts.

[sympa]

Inderdaad, de spare-ruimte is al verdeeld over alle data-disks en bij het rebuilden wordt er dus van alle disks gelezen en ook geschreven. En per bestand, dus als het misgaat is er maar 1 bestand geraakt. Metadata is beter beschermd dan gewone data, zodat die nog robuuster is.

[blinchik]

Ik heb eerlijk gezegd nog nooit meegemaakt dat er iets kapot is gegaan tijdens een rebuild. Ik spreek wel over enterprise SAN en disken die onder warranty zijn. Maar goed, zelf op mijn NAS thuis is het eigenlijk nog nooit fout gegaan. Als er echt nog andere disken kapot gaan tijdens een rebuild, is de kans groot dat je over out of support cycles spreekt. Bij disk monitoring op enterprise niveau wordt een disk ook faulty gemarkeerd als er ook maar 1 sector kapot gaat of zelfs als de disk trager begint te performen (pre-alert)

[flippy]

met raid verlies je geen data, alleen de access times worden wat hoger tijdens een rebuild. en met een hotspare hoef je als IT'er niks te doen behalve de kapotte schijf eruit halen en een nieuwe hotspare erin duwen. stuk minder gezeik dan overnieuw beginnen.

[Snow_King]

Met ZFS kan het prima. Wel zorgen dat je mininaal Z3 draait en dat ke vdevs niet te groot zijn.

Zo kan je ineens prima 24 van deze disks in een array zetten.

Combineer dat met veel RAM en wat SSDs en je hebt veel en snelle opslag.

[Locke_]

Zoals de meesten al zeggen, een wipe and restore is nog niet bepaald een "normale" actie.
Stel je even voor dat je alles repliceert naar een off-site locatie of nog erger, naar "de cloud".
Je restore is geheel afhankelijk van je bandbreedte geworden. Zelfs een rebuild is in 9 van de 10 gevallen sneller dan dat.

@Verwijderd dit soort disken gebruiken in een andere setup dan RAID6 is eigenlijk nooit aan te raden, voor thuis is RAID5 leuk omdat je dan een paar TB extra krijgt, maar als er tijdens een rebuild iets fout gaat, dan ben je echt in de aap gelogeerd. Enterprise grade kun je in sommige gevallen zelfs alleen maar "best effort"-ondersteuning krijgen als je dit soort disken (SATA/SAS-MDL/NL) in iets anders dan RAID6 plaatst.

<quote>Daarvoor heb je systemen met softraid en hw redundancy voor een complete unit (mirror).</quote>

ook softraid moet rebuilden, dat veranderd niet. In sommige gevallen is dat (HW afhankelijk) zelfs nog trager omdat er geen offloading plaats kan vinden en de CPU zelf hiervoor belast wordt. HW redundancy is de RAID vorm in dit geval en weinig consument-gebruikers zullen volledige hw redundancy in de vorm van een mirror array thuis hebben staan. Dat is wel echt een tweakers en/of zakelijk ding.

@blinchik Eens, ik zelf ook niet, ik heb heel veel met 3PAR en soortgelijke SAN systemen gewerkt en heb thuis meerdere Synologies staan waarbij ik nog nooit problemen met een rebuild anders dan de doorlooptijd heb gehad. 3PAR heeft daarbij ook directe spare disken, zodra een disk geflagged wordt als damaged wordt de data welke nog leesbaar is en aan de parity check voldoet direct naar en spare gekopieerd en de resterende data wordt rebuild. Dat bespaart wel aardig tijd in de rebuild, maar kost aan de andere kant wel flink wat extra disken.

[sdk1985]

Raid5 is al jaren met pensioen. Tegenwoordig heb je andere systemen die je disk vlot kunnen vullen. Denk aan snapraid, SHR, enz.

[Locke_]

Al die systemen zijn in de basis nog steeds gebouwd op RAID #, maar met de fabrikant zijn eigen optimalisaties. In de consumentenmarkt zal de term RAID # ook maar weinig zeggen en is het daarom ook niet zo relevant hoe het genoemd wordt, maar zakelijk wordt de term nog veel gebruikt.

Technisch is in de zakelijke markt de term RAID # ook niet meer hetzelfde als dat het origineel was, ook daar hebben de verschillende fabrikanten hun eigen optimalisaties toegevoegd, maar ze blijven het wel bij veelal bij de oude termen houden, wat het in mijn optiek ook voor de beginnende storage beheerders veel duidelijker houdt.

[Verwijderd]

Hoe gaat zo'n HDD om met een bad sector. Als je zoveel ruimte nodig zou hebben, heb ik toch liever kleinere HDD's met een raid oplossing

[Verwijderd]

Slechte sectors worden toch al jaren gemapt en gemerkt zodat die gewoon niet meer gebruikt worden? Meeste HD's hebben zelfs een buffer hiervoor dacht ik

[StefanTs]

Hetzelfde als de kleinere modellen in dezelfde serie.

[Mic2000]

Wauw, 14TB is veel... en persoonlijk als consument vind ik het teveel geld om dan maar één schijf voor 14TB te gebruiken. Ofwel dan op zijn minst twee in raid, en dat maakt het toch wel weer zo’n €1080,-

[steven2992]

Als je 14 TB hebt op te slaan dan zijn deze schijven niet bijzonder interessant. Dan kan je beter wat kleinere schijven in een array naar keuze zetten en een fatsoenlijke backup maken. Deze schijven zijn pas echt interessant als je enkele honderden TB hebt op te slaan, zeg als je veel 4K videomateriaal schiet met een hoge bit rate. Natuurlijk zullen er niet heel veel consumenten zijn met dit soort behoeftes, maar aan de prosumer kant kan het wel al een handige oplossing zijn.

[sumac]

Stel je hebt als foto/videograaf, zzp-er zonder IT-afdeling of serverrack, zo'n 10TB aan materiaal in hoge resolutie. Dan zijn twee of zelfs drie van deze schijven toch ideaal. Eén als bron, twee als backup, een altijd offsite. Het blijft compact. Als je eenmaal alles heb ingericht, dus alle data 3x hebt overgezet, wat een hele tijd gaat duren, dan zijn de incrementele backups niet meer zo'n probleem. Ik denk dat er genoeg mensen zijn die het niet met je eens zijn.

[Reactie gewijzigd door sumac op 25 juli 2024 01:50]

[Xander2]

Een 6bay nas met 2Tb disks in JBOD en cloud account als backup is goedkoper en veiliger.

[sumac]

Een 12TB cloud account? Wat gaat dat kosten? Hoe snel is de upload- dan wel download-snelheid? Als ik maanden online moet zijn om zo'n backup online te krijgen, wat is het dan waard?

[Blokker_1999]

En dan heb je er twee in RAID en heb je voor hetzelfde geld maar de helft van de capaciteit en nog altijd geen backup.

[MrFax]

Maar met deze schijven kan je wel praktisch ongelimiteerde opslag(voor een consument/power user) hebben in een compact kastje.

[Mic2000]

Uh in RAID 1 heb je toch ze parallel lopen zodat het een backup is?

Raid is geen backup...
Nou dan gewoon een tweede HDD voor softwarematig backuppen.

[Reactie gewijzigd door Mic2000 op 25 juli 2024 01:50]

[Xander2]

Uh in RAID 1 heb je toch ze parallel lopen zodat het een backup is?

Raid is geen backup...
Nou dan gewoon een tweede HDD voor softwarematig backuppen.

In een ander systeem anders doe je moeilijk wat RAID-1 beter kan

[scenix_]

Raid is GEEN backup, les 1 in de IT-Storage wereld.
Als mijn data op schijf 1 in raid 1 defekt is, is het zeker weten op de tweede ook defekt.

Raid 1 kan alleen het uitvallen van een harde schijf opvangen. Maar als mijn Volume Crashed of de NAS kapot gaat, kan het gewoon gebeuren dat je NIET meer aan de data komt omdat de konfiguratie niet meer te lezen is. Soms helpt het zelfs niks meer die HDDs in een andere NAS te installeren.

Dan kan jeje hdds naar een bedrijf sturen om je data weer te krijgen. Dan wens je dat je een backup had

[jaenster]

Hoi, een idioot hier.

Ik draai RAID 0, striped. 2 SSD's, gewoon omdat ik er een over bleek te hebben. Ik maak netjes een backup van de disk array, in huis en buitenhuis. Waarom raid 0? Voor de snelheid. Raid is geen backup.

[PostHEX]

Prima dat je het gevoel hebt dat je jouw keuze moet verdedigen, maar daar hadden we het niet over. De context was HDD opslag. Was duidelijk, toch? Met RAID 0 verdubbel je de wear voor dezelfde opslag. Wat is daar niet idioot aan? SSDs is een ander verhaal.

[sdk1985]

Raid 0 verdeelt de writes, dus dat klopt niet. Wanneer een bestand te klein is komt hij zelfs maar op 1 disk terecht.

Ik heb decennia lang raid 0 gebruikt. Mijn eerste consumenten raid 0 was op basis van twee IBM 40 GB drives in 2001. Voor de SSD bestond kon je weinig anders dan raid 0 gebruiken om je opslag te versnellen. Door de jaren heen ben ik gebruik blijven maken van een 2 disk raid 0 voor OS+software+games.

Zeker met installatie van games merk je dan gigantische verschillen. De laatste raid 0 die ik had op basis van Seagate Barracuda's 2x 1 TB deed 450 MB/s sequentieel. In 2015 heb ik voor het laatst alles getest: https://www.gameplayinsid...-or-raid-0-which-is-best/ Je ziet daar bijna 2 minuten installatie tijd voor de harde schijven, 46 seconde voor de raid 0 array en 42 seconde voor de SSD. Met dat soort verschillen was eerder idioot als je geen raid 0 gebruikte toen de ssd nog bestond . Backuppen moet je toch dus betrouwbaarheid kan nooit een reden zijn om raid 0 af te raden.

In 2017 ben ik mijn mijn raid 0 gestopt. Toen was er eindelijk een betrouwbare caching techniek waarbij ik de laatst gebruikte data automatisch naar een SSD kon krijgen. De 1100GB aan games lopen nu netjes via 150 GB aan SSD caching. Momenteel heb ik nog 65 GB vrij in de cache. Maar in alle jaren daarvoor had ik het niet willen missen.

[_Erikje_]

14TB zonder RAID

[stresstak]

Maar wel een backup, uiteraard.

[Verwijderd]

Ik moet zeggen dat ik eerlijk gezegd niet meer weet _hoe_ ik een backup van mijn data kan maken. Half dozijn computers, plus tablets, mobieltjes en een wacom mobile studio pro, tien, twinting terabyte aan data verspreid over dat alles. Ik denk dat ik maar weer kaarsjes ga opsteken, zondag morgen vroeg.

[rfmeijboom]

Ik heb een NAS gebouwd om alles op op te slaan.
Alle laptops en PCs werken op de netwerk share.
Alle telefoons en tablets syncen elke nacht via de app foldersync pro naar de NAS.
Dan heb ik de data in ieder geval op 1 plek bij elkaar.
Die NAS heeft ook nog een incremental backup van alle data en een nachtelijke off-site backup naar een externe schijf aan een computer die via een VPN tunnel naar huis beschikbaar is.

Kost wat geld, tijd en moeite om alles in te richten, maar alles wat ik nu op een laptop, tablet of telefoon maak, download of bewerk staat de volgende dag veilig op meerdere plekken.

[Tassadar32]

Crashplan doet dit prima, unlimited backup als dienst. Ik sync eerst alle data naar de fileserver (lokale kopie dus) en die doet een backup naar crashplan met versioning.

[Verwijderd]

CrashPlan stopt met back-up voor consumenten
nieuws: CrashPlan stopt met back-up voor consumenten

[Tassadar32]

Ja, dus ben ik overgeschakeld naar de MKB versie. Werkt net zo goed

[stresstak]

Ik moet zeggen dat ik eerlijk gezegd niet meer weet _hoe_ ik een backup van mijn data kan maken.

En dat is dan allen nog maar data. Van de rest van de inboedel heb ik ook geen kopie.
Die kaarsjes steek je dan beter op in de kerk en niet thuis. Als het afbrandt heb je noppes.

[Verwijderd]

Ja... Maar ik woon _boven_ een kerk...

[stresstak]

Sterkte dan maar.

[supersnathan94]

Daarom heb ik ook niet een backup van alles op dezelfde plek. Belangrijke documenten in de cloud, net als fotos en videos. Daarnaast nog zelf backup on site. Programmas en andere meuk kan mij gestolen worden. Kan ik wel weer opnieuw binnen hengelen.

[Bamboozled]

Flickr voor al je foto's dan heb je al 1 TB te pakken en een app op je telefoon waarmee je alles tot je vroegste foto's terug kan kijken.

[xAn52]

Tapes. Kost een beetje, bewaart een boel. Ok, de drive is wat duurder. een licentie is ook niet gratis en een goed schema uitdenken kost ook wat tijd. Maar dan heb je ook wat. Kwestie van (-kosten+baten)*risico.

[Tazzios]

Tuurlijk wel! RAID 0

[Cilph]

Nee joh. Veel te traag nog steeds. Je moet 28x 512GB SSDs in RAID0 zetten.

[Verwijderd]

512GB SSD cache er bovenop en vlammen

[Pas_PC]

Seagate en betrouwbaarheid.., Ik betaal liever wat meer voor een ander merk.

[shadowrune]

Ja, uit ervaring doe ik dat ook, mits de statistieken aangeven dat deze wel beter zijn. Nog even wat reviews gelezen van de IronWolf serie, maar daar werd ik ook niet vrolijk van.

[RoestVrijStaal]

Hangt het niet af van of de ene batch uit China komt en de andere uit Thailand?

Een paar jaar terug was dat een dingetje in zoverre ik me kan herinneren.

[sympa]

Als je betrouwbaar wilt dan meng je batches en merken. Ik kreeg ooit een storage array van een goede leverancier en toen ik keek waren er disks van allerlei datum en merk. Ik dacht: wat een prutslevering. Later zag ik in dat het heel verstandig is, RAID kan zijn werk doen omdat niet alles dan in 1 keer kapot gaat.

[sdk1985]

Laatst bekende cijfers uit 2016:

quote: https://www.hardware.fr/articles/962-6/disques-durs.html

HGST 0,82% (contre 1,13%)
Seagate 0,93% (contre 0,72%)
Toshiba 1,06% (contre 0,80%)
Western 1,26% (contre 1,04%)

Zit allemaal dicht bij elkaar. De verhalen rond Seagate komen van Blackblaze vandaan die desktop schijven met een maximaal gebruik van 8 x 5 uur vervolgens in een 24/7 opstelling plaatsen. Voor consumenten gebruik heb je weinig aan die data omdat niemand zijn schijf op die manier gaat gebruiken.

[Reactie gewijzigd door sdk1985 op 25 juli 2024 01:50]

[HanslH]

Zit juist de denken in termen van scheduled backup van mijn nas maken ipv er in te stoppen.

[Tassadar32]

Van het geld wat 1 zo'n schijf kost kan je met een dienst zoals crashplan jaren offsite backup doen met versioning. Offsite is altijd een beter plan dan je backup naast (of in ) je NAS te hebben.

[Mastermind]

Mooie schijf.
Mijn eerste PC, een 386DX 40 had een harde schijf van 105MB. Kostte toen een fortuin

[jpsch]

Zo'n duizend gulden. Die van mij ging stuk, gelukkig garantie. Iedereen met een 20MB schijf zei dat die van mij nooit vol zou komen.

[Mr-E]

Ik moet hier stiekem toch wel even om lachen. Ik vond t belachelijk dat games op 3 floppy's stonden, Dat je zoveel mb kwijt was op de HDD, omdat dat ik ze niet direct van floppy kon spelen

[ignitem]

Hoe lang gaat zo'n met helium gevulde harddisk eigenlijk mee? Haalt zo'n schijf bijvoorbeeld 10 jaar bij niet te intensief gebruik?