TransIP Stack-opslagdienst is door twee defecte schijven deel van data kwijt

Enkele tientallen tot honderden TransIP Stack-klanten zijn een deel van hun data kwijt doordat twee schijven in één server binnen een week defect gingen. TransIP probeert de data nu te herstellen, maar zegt dat een deel onherstelbaar is. Het euvel treft alleen de gratis accounts.

Op 17 september merkte TransIP dat een van de Stack-servers onbereikbaar was, zegt een woordvoerder tegen Tweakers. Na een herstart van de server bleek bepaalde data onbereikbaar te zijn door een defecte schijf. Dit gebeurt volgens het bedrijf wel vaker, maar doordat Stack de RAID-Z-configuratie gebruikt, is dit normaliter geen probleem. Bij RAID-Z wordt data zodanig verdeeld over verschillende schijven, dat de verloren data bij uitval van een schijf kan worden teruggebracht.

TransIP verving daarom de defecte schijf en moest de data opnieuw verdelen over alle schijven binnen de server. Dit proces duurt volgens het bedrijf meestal anderhalve week. Tijdens het herverdelen ging echter een tweede schijf stuk. Omdat het herverdelingsproces nog niet klaar was, is de integriteit van de data volgens TransIP aangetast. TransIP benadrukt dat het nooit eerder is voorgekomen dat een tweede schijf tijdens het herverdelingsproces is stukgegaan.

De tweede defecte schijf is naar een 'gespecialiseerd herstelbedrijf' gestuurd, maar dit bedrijf kon de schijfdata niet geheel terughalen. Inmiddels probeert TransIP zelf de data van de defecte schijf te herstellen, om zo een gedeelte van de verloren data terug te krijgen. Het bedrijf zegt echter wel dat een gedeelte van de data niet meer hersteld kan worden.

Alle klanten die op de server waren aangesloten, zijn volgens de woordvoerder per mail benaderd en worden via een incidentmeldingspagina op de hoogte gehouden. TransIP bericht deze getroffen klanten in de komende weken over welke data kan worden hersteld. Deze data wordt automatisch in het Stack-account van de gebruiker geplaatst. Omdat TransIP nog bezig is met het herstelproces, is het volgens de woordvoerder lastig om te zeggen hoeveel klanten door het defect getroffen zijn. Het is eveneens onduidelijk hoe groot de server was en hoeveel klanten erop aangesloten waren. "Dat aantal ligt niet in de duizenden, maar in de tientallen of honderden klanten", zegt de woordvoerder.

Onder de klanten zijn er in elk geval twintig met een betaald Stack-abo. TransIP back-upt de Stack-data van betalende gebruikers, volgens de woordvoerder is bij deze klanten dan ook geen data verloren gegaan. Voor gratis accounts worden echter geen back-ups gemaakt.

TransIP Stack is een online opslagdienst die van 2015 tot 2018 accounts met gratis 1TB opslag aanbood. Hier zat een maximum aan van 250.000 invitecodes. Hoeveel klanten Stack nu heeft, is niet bekend. Stack biedt momenteel drie betaalde abonnementen aan: 250GB voor 3,03 euro per maand, 2TB voor 12,10 euro per maand en 10TB voor 60,50 euro per maand.

Reacties (415)

[jjkester]

Verbaast me dat ze RAID-Z1 met maar één disk redundancy gebruiken. Het is algemeen bekend dat tijdens het herstellen van een degraded array de kans dat een andere schijf faalt vrij groot is. Dit omdat het herstelproces veel van de andere schijven vraagt, maar ook omdat er vaak schijven met vergelijkbare leeftijd en gebruik in zitten.

Voor de geïnteresseerden heeft Level1 een goede video over ZFS: https://youtu.be/lsFDp-W1Ks0

[mauritsl20]

Inderdaad, Z1 of RAID 5 is een no go in 2020 gezien gezien de dataopslag per platter. Tuurlijk kan het als kostenoverweging of backup van een betere pool etc. Maar als hoofd pool zou ik het niet meer adviseren.
Het is wel fijn dat er tegenwoordig enterprise schijven zijn met een error rate van 110tb tegen de 11 tb van bijvoorbeeld een WD Red. Dat maakt het risico wat lager maar blijft hoog risico Z1/Raid 5 welke schijven je ook hebt. Daarom adviseer ik altijd een WD ultrastar of een Toshiba MG07 vanwege de MTBF/MTTF van 2.5 miljoen uren tegenover de 1 miljoen uren van een WD red. Maar nog belangrijker de kans op lees fouten van 1 fout per 11tb tegenover 110tb. 180 TB per jaar work load vs 550 tb. Ofwel meer kans op overleven.

Deze schijven zijn maar een fractie duurder maar ja ze hebben niet de marketing van een WD red / ironwolf dus zie je dat een WD red schijf als warme broodjes verkoopt terwijl het eigenlijk geen “top”schijf is.....

[Reactie gewijzigd door mauritsl20 op 23 juli 2024 17:13]

[Tozz]

Er zijn wel wat mitigerende maatregelen die je kunt nemen om toch RAID5 toe te kunnen passen. Zoals Consistency Checks en Patrol Reads. Die 2 zorgen er samen voor dat alle data periodiek van alle disken wordt gelezen, en je op die manier disk fouten al vroegtijdig kunt opmerken.

Wij hebben door met name patrol reads eigenlijk nooit meer degraded arrays, omdat de controller al vroegtijdig iets zegt als 'Op deze disk heb ik een read error gehad', en dan vervangen wij 'm al.

[SSH]

Dit dus. In de regel gaat een disk nooit stuk zonder vooraf voldoende waarschuwingen te geven. Als je dat negeert, is dat volgens mij het probleem.

[mauritsl20]

Kan er toch zomaar mee stoppen zonder waarschuwingen.......

[Reactie gewijzigd door mauritsl20 op 23 juli 2024 17:13]

[sfranken]

Ik heb dat nog nooit meegemaakt. Elke schijf die ik tot nu toe heb gehad die dood was/aan het gaan was kwam via smartctl genoeg fouten naar boven, dus genoeg waarschuwingen (ruim) van te voren gehad.

[Ocram]

hmmm ik heb, wel wat jaren geleden, PB's aan storage in beheer gehad. Veel disken werden preventief vervangen om rebuilds (risico) te voorkomen. Maar zo af en toe gaan er toch ook gewoon disken spontaan stuk.
Nu de disken steeds groter worden is de rebuild tijd ook steed langer. De kans op een tweede defecte disk in de zelfde raid neemt dus gewoon toe.

De raidsets werden automatisch tussen, ik geloof minimaal 6 en maximaal 7 gehouden. Dit schijnt het optimale aantal te zijn in ik geloof een raid 5. Of dit nog steeds zo is, met de huidige sizes en specificaties???

Maar zo als meestal, elke risico verlaging komt gewoonlijk met een prijs. Wat is het risico en wat heb je er voor over om het te verlagen. Nou is het verliezen van klanten / gezicht wel wat moeilijker van te voren in te schatten als kosten, dus dat wordt nogal eens achterwegen gelaten in de analyse ;-)

[d3burt]

Onder de zes disken is de overhead van RAID te groot (bij een RAID5 van vier disken gebruik je een derde van de disk capaciteit weg voor parity). Boven de 7 wordt de tijd voor het herstellen van een kapotte disk te lang, waardoor je resilver tijden in weken krijgt.

Om de resilver performance goed te houden in een 18disk ZFS raidz1 volume moet je 'm opbouwen als een RAID0 van drie RAID5's, elk bestaande uit vijf disken plus één parity. Als je goedkope disken gebruikt of heel belangrijke data hebt wil je liever raidz2 (met twee parity disks). In dat geval gebruik je dus zes van de 18 disks voor parity... maar je slaapt wel beter in de wetenschap dat het redelijk snel (ongeveer een dag) kan resilveren als er een disk gaat hemelen...

Hoe grote de capaciteit, hoe langer de resilver tijd, maar dat is alleen met kleinere RAID6 arrays op te vangen en de meeste mensen vinden het nettoverlies van een 6 disk array met twee parity al pijn doen.

Ik heb wel rotte batches disks gezien, die binnen een paar dagen met vijf van de 18 kapot gingen, zonder SMART errors die tijd genoeg lieten om de resilver te kunnen doen. Gelukkig kwam dit tijdens het proefdraaien naar boven. De disks hadden daarvoor een paar weken stil gestaan, kennelijk vonden ze dat niet fijn.

[The Van]

ZFS sucks sowieso, maar ieder weldenkend mens gebruikt ZFS-2, en geen ZFS-1. Gewoon vanwege dit soort rampscenario's.
Oracle propageert overigens al tijden SAME, Stripe And Mirror Everything. Dat (Oracle) zijn BTW de uitvinders van ZFS

[mkools24]

Jij hebt het nooit meegemaakt dus gebeurt het gelukkig ook nooit.

We hebben het over serveromgevingen met honderden disk, niet over een thuispc-tje met 1 of 2 schijven.

[sfranken]

Ik heb het ook over serveromgevingen met honderden disks. Dan krijg je vanuit je monitoring pakket ver van te voren een warning hoor ;-)

[tERRiON]

Het lullige is alleen dat je die disk er vroeg of laat toch uit zult moeten trekken en er een rebuild wordt gestart. Omdat dat proces een flinke aanslag op je disken is, kan het zomaar zijn dat je daarmee andere disken ook over de rand trekt als ze al tegen hun kritiekpunt zaten. Zo'n grap heb ik nog niet zo lang geleden gehad met een diskcabinet waarin kapotte 1 disk een kettingreactie veroorzaakte waardoor er binnen anderhalve dag nog 5 disken het loodje legden. Dankzij de snelle levering vervangende schijven en wat ingebouwde intelligentie zijn we door het oog van de naald gegaan maar is er geen data verloren gegaan.

[Reactie gewijzigd door tERRiON op 23 juli 2024 17:13]

[sfranken]

En daarom bouw je nooit een serie disks in uit dezelfde batch, want dan is de tijd dat ze meegaan ook vrij dicht op elkaar af te stemmen..

[tERRiON]

Als je de vrijheid hebt om dat zelf te doen: Ja. Ik vraag me alleen wel af in welke enterprise omgeving op die manier storage oplossingen worden gebouwd. In de omgevingen waarin ik een kijkje in de keuken heb gehad, staan vooral oplossingen van de alom bekende fabrikanten en dan ben je vooral overgeleverd aan wat zij uiteindelijk voor je in elkaar schroeven. In een kabinetje met een paar disken zal het vast nog wel lukken maar het wordt waarschijnlijk lastiger naar mate het aantal disken oploopt.

[The Van]

Vanuit ZFS zelf al, hoor

[Xfade]

Tis maar hoe je het bekijkt. De meeste consumenten controleren niet dagelijks de smartwaardes. Een bedrijf als Transip zou dit automatisch moeten doen. Ik geloof daarom ook niet zoveel van hun verhaal.

[sfranken]

De gratis versie van Stack is gebouwd op oude schijven die ze nog hadden liggen geloof ik, dus garantie tot aan de voordeur. Ik heb trouwens mail gehad dat het ging om minder dan 0.3% van de data in totaal..

[jordynegen11]

Als er wat stuk gaat op de PCB van de HDD dan gaat hij zonder waarschuwen offline hoor

[ijdod]

Yeah... no. Het probleem is niet het vervangen van de disks per se, dat is minutenwerk; het probleem is dat het herstellen van een array lang duurt, en gedurende die tijd alle disks zwaar belast.

Hoewel ik het met je eens ben dat veel schijven errors geven voordat ze echt stuk gaan, is dat zeker niet allemaal. Je stelling houdt alleen stand als je al lang tegen een defecte disk aan hebt zitten kijken. Als je tegelijk tegen twee van dat soort fouten aanloopt, of als de tweede fout ontstaat tijdens het weer opbouwen van de array... kan je alleen maar hopen dat de disk de einstreep haalt.

Uiteraard is dat in de context van een RAID5 (of vergelijkbaar) oplossing. De oplossing voor bovenstaande, als dat voor je use case onacceptabel is, is iets anders te doen .

[--Andre--]

Oh dat had ik vorig jaar wel meegemaakt.

[sfranken]

Durf je daar vergif op in te nemen? Dat als je in je logs kijkt en/of smartctl napluist dat er niks naar voren komt? Ik twijfel.

[--Andre--]

Die logs stonden dus op die defecte schijf... any evidence has been destroyed.

[mauritsl20]

Vaak wel gelukkig.

[fastbikkel]

Zeker weten.
Collega's van mij hebben door een afgaand alarm in het datacenter tientallen defecte schijven "gekregen".
Resonantie zorgde voor een stortvloed aan defecte schijven.

Dit was wel extreem natuurlijk.
Maar terugkomend op je eerste punt, ja schijven kunnen zeker plots kapot gaan. Dit heb ik zelf vaak meegemaakt.

[mkools24]

RAID5 voor bedrijfsomgevingen is gewoon not done, hoeveel patrol reads je ook doet. Ik heb CephFS draaien waar alles driedubbel wordt opgeslagen en zelfs dat vinden sommigen nog te weinig, laat staan dat je al je data afhankelijk gaat maken van het falen van één enkele disk!

Nu snap ik wel dat het een gratis dienst is dus moet het zo goedkoop mogelijk. Maar als je dat doet zet er dan wel volle bak disclaimers en loeiende sirenes bij wanneer je die dienst afneemt.

[Tozz]

Die opmerking is mij toch echt te simplistisch. Als een RAID5 array met 4 disken not done is. Is RAID6 met 8 disken dan ook not done? Kans dat met een 8-disk array 2 disken stuk zijn is immers net zo groot als 1 disk kapot in een 4-disk array

Nu heb ik een array van 48 schijven, moet ik daar dan RAID met 7 parity disks gebruiken?

[mkools24]

Met 8 disks doe je normaal 2 x Raid5 want dan heb je de writespeed van 2 disks. Anders maar van eentje.

Maar idd buiten dat is raid5/6 leuk voor thuis of voor een testsetup. Anders gebruik je gewoon mirrored disks.

[Tozz]

Je reacties zijn naar mijn idee toch echt te kort door de bocht. "Met 8 disks doe je normaal 2xR5", waarom dan? Wie zegt dat? Nog steeds heb je met 2xR5 in feite gewoon R6. Het klopt ook niet. Met 8 disks in R5 is je writespeed niet lager dan 2xR5 met 4 disks.

En "dan gebruik je mirrored disks" is ook echt te simplistisch. Het hangt helemaal af van de use-case. De wereld is niet zwart wit.

[mkools24]

In het geval van ZFS wel (wat TransIP blijkbaar gebruikt):

- 2x Raid5 met 4 disks heb je 2 vdevs = writespeed van 2 disks.
- 1x Raid6 met 8 disks heb je 1 vdev = writespeed van 1 disk.

Dus je zou wel dom zijn om dan Raid6 te doen, aangezien je hetzelfde aantal disks (2) kwijt bent aan parity en het vrijwel even (on)betrouwbaar is.

Maar dat is enkel als je echt persee raid5 of 6 wilt. Ik zou dat hoe dan ook afraden en enkel voor mirrored disks gaan. Zelfs thuis. Tegenwoordig met die disks van 12-14 TB en hoger is de rebuilt tijd gewoon veel te lang, je praat dan over dagen soms weken.

[The Van]

Ik heb RAID5 nooit begrepen, juist vanwege dit soort scenario's. Zelf, thuis ook nooit toegepast. Alles wat van waarde op schijf staat/stond had/heeft een mirror. En tegenwoordig een hot sparen.
HDs kosten niks meer, dus alleen daarom al geen Redundant Array of Inexpensive Disks.

[mkools24]

Ja ik zeg het, zelfs thuis gebruik ik het ook niet. Maar lees de reacties genoeg mensen die het gebruik ervan nog rechtvaardigen.

[jaenster]

Een RAID als backup gebruiken is not done.

Een RAID 5 gebruiken als manier dat het niet direct uitvalt bij een stukke disk, prima.

[Tintel]

niet de marketing van een WD red

? WD Ultrastar is toch van hetzelfde merk?

[mauritsl20]

WD ultrastar zijn enterprise grade maar werken prima in je nas of pc

[BitProcessor]

Was vroeger HGST inderdaad.

[Polderviking]

RAID 5 is zeker geen "nono" omdat het 2020 is, maar zoals overal moet je kijken naar wat je van je oplossing wil en wat je hebt.
Als je gewoon maar 4 schijven hebt en die ook nog kleiner zijn van een terabyte lijkt het me prima uit te leggen dat je voor RAID5 kiest als "middenweg" tussen failure tolerance en ruimtebenutting. NIet iedereen heeft immers mega heftige storage pools nodig of voert servers die onder geen voorwaarde down mogen.

Als je tien schijven van elk tien terabyte ergens in fietst moet je allicht wat anders gaan doen als je nog rustig wil slapen ja.

Uiteindelijk moet je het zwikkie in zijn geheel toch zo inrichten dat je niet helemaal kapot gaat als je server spontaan in de fik vliegt.

[Reactie gewijzigd door Polderviking op 23 juli 2024 17:13]

[Q]

Tja, zeker dat laatste is iets waar een hoop mensen niet bij stil staan.

Data opslaan is heel makkelijk.

Data veilig opslaan, met een gewaarborgde beschikbaarheid is een rotklus:

- Minimaal twee machines die data syncen (drama opzichzelf)
- RAID(variant gebruiken)
- Backups maken

en dan laat ik performance nog buiten beschouwing, om mensen niet helemaal verdrietig te maken.

[mkools24]

CephFS kan dat alles vrij simpel Helpt ook als je een 10 gbit lijn hebt tussen 2 dc's.

[Q]

Ceph is awesome maar bevestigd ons beider punt: Ceph maakt dit makkelijker, maar het is ook een beest van een storage oplossing, die de nodige kennis vereist om dat veilig te draaien. Er zijn genoeg anekdotes te vinden over gedonder met Ceph clusters die plat gaan.

[The Van]

4 schijven? SAME. U wellicht bekend als RAID 01, of RAID 10. Ik hou het op 01

[Polderviking]

Raid 01 en Raid 10 zijn opzich twee verschillende dingen, alleen met vier schijven zijn ze functioneel gelijk.
En je levert daarmee nogal wat potentiele storageruimte in want uiteindleijk is dat een gewoon een soort luxe mirrored raid met meer schijven.
En dat kan een prima keuze zijn, als je die redundancy wil hebben, maar daarmee is Raid 5 niet op voorhand slecht.

[The Van]

Nee functioneel gelijk zijn ze niet. Een striped mirror is wat anders dan een mirrored Stripe.
In het eerste geval maak je twee mirrors, twee keer twee schijven, immers.
En die twee mirrors ga ja stripen.

Andere geval is een Stripe set, die je mirrored. Ik hou niet van Stripe sets. Een eventuele fout wordt keurig gemirrord.
All data gone...

[Q]

RAID5 is nog steeds prima, maar je moet niet teveel schijven in een RAID array stoppen, zeg max een stuk of 6.

Rebuilds duren tegenwoordig veel langer, maar dat is niet erg. Je bent wat langer kwetsbaar voor een 2e schijf uitval, maar dat risico is weer niet zo groot met een klein aantal schijven in de array. Zeker niet als je goed scrubt.

Het hangt gewoon heel erg af van de context. En of je nu RAIDZ/RAID5/RAIDZ2/RAIDZ6 draait, je zou een backup van de data moeten hebben en dat is met name wat ik TransIP zou verwijten: die hebben ze niet.

Maar context: dit was voor gratis gebruikers, dus ik snap helemaal dat ze dan zo kostenefficient mogelijk draaien en voor RAID 5 kiezen en geen backups maken.

Maar dan kan een pers bericht als deze een gevolg zijn, met mogelijke imago schade als gevolg, maar alles is een tradeoff.

Maar nog belangrijker de kans op lees fouten van 1 fout per 11tb tegenover 110tb.

Dit lijkt te refereren naar de URE rating van schijven die voor veel reguliere schijven ongeveer een leesfout op 12.5 TB aan data die verstookt wordt. Dat zou betekenen dat je een 14TB schijf nooit meer in zijn geheel zonder fouten kunt uitlezen maar dat is natuurlijk niet waar.

Harde schijven zijn veel betrouwbaarder. Zie ook dit artikel (blog zonder ads) voor wat meer context.
https://louwrentius.com/dont-be-afraid-of-raid.html

Die hogere URE ratings van duurdere schijven maken gewoon niet zoveel uit.

[Reactie gewijzigd door Q op 23 juli 2024 17:13]

[mauritsl20]

De URE van enterprise schijven zijn het verschil tussen wel of geen data terug winnen.
Is factor 10. Het zijn kansen in falen dus tuurlijk kan een WD red zich redden maar de kans is minder groot.

https://www.acsapp.com/blog/raid5-is-dead/
En zo zijn er nog veel meer artikelen in de omloop.

[Q]

Dat soort artikelen praten vaak dit hele slechte artikel van ZDNET na.

Maar in bovengenoemd blog artikel leg ik uit dat hier niets van klopt.

Over die URE waarden zou ik mij niet druk maken. Zeker niet als je netjes regelmatig je RAID(Z) disks scrubt.

Misschien dat duurdere schijven met betere URE/MTBF waarden minder vaak uitvallen maar ik zou me vooral richten op de https://www.backblaze.com/b2/hard-drive-test-data.html en al die URE en MBTF verhalen gewoon links laten liggen. Backblaze draait ook met desktop schijven (die gebruiken erasure encoding voor redundancy).

Als je data echt belangrijk is en je wilt het downtime risico minimaliseren (het doel van RAID is beschikbaarheid) dan is vaak RAID6 of RAID60 als je de performance nodig hebt de beste keuze.

En dan maakt het gewoon niet zo uit wat voor schijven je koopt, zolang het maar geen SMR schijven zijn

[Reactie gewijzigd door Q op 23 juli 2024 17:13]

[mauritsl20]

Is factor 10 waarin je wel or niet je data kan behouden. Zeker wel iets om over na te denken of je dat risico wilt nemen. Los van datascrub etc. Die helpen maar niet tijdens het opnieuw opbouwen van je raid 5 of Z1.
Tijdens het opnieuw opbouwen is URE factor je beste vriend.

in RAID 5, if you have a disk failure and you replace the drive, it tries to rebuild the new drive by reading the differences between the remaining drives. If one of the remaining “good” drives gets a URE, it will not be able to rebuild the array and effectively crash the entire array and you lose all your data. All because one bit on one drive could not be read.

The unfortunate fact is, as drives get bigger, they are going to be more common. That is because 1 bit in 10^14 (100,000,000,000,000 – a 1 followed by 14 zero’s) is likely to have an Unrecoverable Read Error (URE)*. That may seem like a very large number, but when you realize that that is about 12.5 TB of data, you’ll understand that it means that 1 in 6 – 2 TB drives is going to fail in a way that some data cannot be read from it. Data can be written just fine, but reading from parts of the drive will not work. When you can’t read a portion of the data, that whole file thus cannot be read. If the file is a single Word document that cannot be read, it’s not such a huge deal. But if the file is part of a backup file, that’s a large portion of your data that is lost. Looking at buying a 3 TB drive? You just went from a 17% chance of having a URE to a 25% chance. And according to Murphy’s Law, if you do have a failure, the data that will be lost will be the most highly valuable data on the disk.

[Reactie gewijzigd door mauritsl20 op 23 juli 2024 17:13]

[Q]

Nee, sorry, dit klopt niet, het spijt me.

Het doel van een scrub is om te voorkomen dat je tijdens een rebuild een bad sector aantreft op een van de overgebleven schijven: het is preventieve maintenance.

En die factor 10: dat is een leuke spec op papier, vaak gevoed door marketing, maar het is niet de praktijk. Het is niet erg dat jij je klanten die duurdere schijfjes laat kopen hoor, maar de RAID variant, backups en eventueel een 2e machine (als availability belangrijk is) is vele malen belangrijker dan welke schijven je koopt, wat mij betreft.

Zeker moderne hardeschijven zijn erg betrouwbaar, gezien de backblaze stats.

[mauritsl20]

De schijven die goed scoren bij backblaze zijn juist de schijven die ik aanprijs in mijn post. Scrub trekt datarot recht en inderdaad mogelijke slechte sectors. Echter bij rebuild gaan alle schijven vol aan de slag met opnieuw risico tot falen. Mijn verhaal klopt zodoende gezien iedere lees actie en schijf actie opnieuw een risico tot falen is. Het blijft casino met welke schijf dan ook. Maar voor een iets duurdere schijf (“enterprise”schijf) 1 tot 10x meer kan op succes lijkt mij prima keus.

Ps URE is geen marketing maar feiten gebaseerd op metingen.

[Reactie gewijzigd door mauritsl20 op 23 juli 2024 17:13]

[Hakker]

URE is helemaal niet gebaseerd op feiten. Het is gebaseerd op interne memo's en wat de fabrikant zelf ok vindt. Nergens zijn er harde tests te vinden van echt URE's. Mechanisch zijn ze allemaal hetzelfde. Het is zelfs zo erg dat je tegenwoordig Seagate Exos in externe schijven vindt. Dat zijn dus enterprise schijven die voor de allergoedkoopste schijven verkocht worden. De reden... omdat het gewoon dezelfde schijven zijn. Het enige verschil is de firmware die erop staat en dat ze bij Seagate de serienummer op een externe hebben gezet en je dus kortere garantie van Seagate heb.

[mauritsl20]

Ultrastar en MG07 zijn helium gevuld zodoende niet gelijk aan lucht gevulde goedkopere schijven. Deze zal niemand in externe schijven vinden. Seagate ja die heeft wel wel Exos schijven weggeven bij mensen die verkeerde externe schijf hadden ontvangen. Zou mij idd ook niets verbazen als ze Exos schijven hebben gebruikt. Wellicht per ongeluk of uit onvoldoende voorraad van andere modellen misschien?

[Hakker]

Exos zijn ook helium schijven. Alle schijven van 12TB of meer zijn helium schijven. En nee het gaat niet om vervanging het gaat gewoon om gekochte externe schijven. De 16TB externe schijven zijn allemaal Exos schijven tot nu toe. in WD elements zitten vaak witte label Red schijven.
Dat is geen incidenteel iets. Shucken is een ding en kan je als je de garantie niet boeit honderden euro's op een nieuwe raid array schelen.

[mauritsl20]

Goede tip. Scheelt 70 euro per schijf als ik zo even snel zoek op de pricewatch dat is wel de moeite.daarmee komt een Exos 16tb op het prijs niveau van een Toshiba MG07

[Reactie gewijzigd door mauritsl20 op 23 juli 2024 17:13]

[Q]

Nee, je punt was dat RAID5 niet meer kan en dan verwijs je naar URE statistieken. En dat is gewoon onjuist. RAID5 is prima onder de juiste omstandigheden.

[Reactie gewijzigd door Q op 23 juli 2024 17:13]

[mauritsl20]

Tuurlijk kan het prima als afweging. Echter gezien de grote datadichtheid anno 2020 niet aan te raden.

[Q]

Tuurlijk kan het prima als afweging. Echter gezien de grote datadichtheid anno 2020 niet aan te raden.

Onder de juiste omstandigheden is RAID5 een prima keuze.

[mauritsl20]

in RAID 5, if you have a disk failure and you replace the drive, it tries to rebuild the new drive by reading the differences between the remaining drives. If one of the remaining “good” drives gets a URE, it will not be able to rebuild the array and effectively crash the entire array and you lose all your data. All because one bit on one drive could not be read.

The unfortunate fact is, as drives get bigger, they are going to be more common. That is because 1 bit in 10^14 (100,000,000,000,000 – a 1 followed by 14 zero’s) is likely to have an Unrecoverable Read Error (URE)*. That may seem like a very large number, but when you realize that that is about 12.5 TB of data, you’ll understand that it means that 1 in 6 – 2 TB drives is going to fail in a way that some data cannot be read from it. Data can be written just fine, but reading from parts of the drive will not work. When you can’t read a portion of the data, that whole file thus cannot be read. If the file is a single Word document that cannot be read, it’s not such a huge deal. But if the file is part of a backup file, that’s a large portion of your data that is lost. Looking at buying a 3 TB drive? You just went from a 17% chance of having a URE to a 25% chance. And according to Murphy’s Law, if you do have a failure, the data that will be lost will be the most highly valuable data on the disk.

Dit is waarom ik enterprise schijven kan aanraden en raid 5 wil afraden. Tuurlijk kan het maar je kansen tot succes zijn lager.

[Reactie gewijzigd door mauritsl20 op 23 juli 2024 17:13]

[The Van]

Enterprise disks. Het null argument van elke "storage specialist".
Backblaze statistieken hebben die rubbish allang onderuit gehaald.

"Gewone" HDs zijn nauwelijks slechter, en een goede lay-out, en goede monitoring en backup strategieën zijn veel belangrijker dan dure hardware.

[Q]

Lees mijn artikel, die 10^14 is een worst-case garantie. Het is geen zekerheid! Harde schijven zijn veel betrouwbaarder dan 10^14.

Anders zou geen enkele RAID array meer kunnen rebuilden, ook een RAID6 niet want bij iedere rebuild zouden alle schijven UREs ervaren.

[mauritsl20]

Ik verkoop geen schijven aan klanten ;-)
Hoezo duur is goedkoper dan WD red of seagate ironwolf per GB. Enkel koop je hier 12TB in 1x
pricewatch: Toshiba MG07ACA12TE (512e), 12TB

[Reactie gewijzigd door mauritsl20 op 23 juli 2024 17:13]

[The Van]

Backblaze stopt 19 schijven in elk array, en drie sets van 19 in een set. Alle details, inclusief delen van de code, zijn openbaar.

BTW, RAID60, serieus? Je vertrouwt RAID5 niet, en stopt er een extra disk in (RAID6) om vervolgens te zeggen weet je wat, we mirroren de hele handel. Dat had je dat beter vanaf het begin kunnen doen. Stripe And Mirror Everything

[Q]

Je bedoelt: stripen die hele handel . RAID60 is meerdere RAID6 arrays gestriped !

RAID 60 is fundamenteel veiliger en geeft meer opslag capaciteit dus ja!

[Reactie gewijzigd door Q op 23 juli 2024 17:13]

[Indentical]

Hangt er net van af hoe ze die de klanten vooraf hebben geïnformeerd over die 1TB aan opslag en of zij vooraf wisten of deze data geback-upt was. Ik heb ook mee gedaan aan die actie(Helaas niets gewonnen)

Als zij in een mail, of ergens anders kenbaar hebben gemaakt dat je een betaalde abonnement moet hebben om je data geback-upt te hebben vind ik persoonlijk dat ze hier niets te verwijten zijn. De klant is immers op de hoogte gebracht dat zij een service gebruiken die aan de zijde van TransIP geen back-up heeft. Mocht TransIP dit niet hebben gedaan dan kan je ze inderdaad verwijten dat ze geen back-up hebben uit gevoerd en dat ze dit niet hebben laten weten. Ik zou verwachten dat ze dat hebben gedaan want het is een goed middel om een gratis klant een betaalde klant te maken, het is algemeen bekend dat back-ups erg belangrijk zijn.

[pe0mot]

Leuke Website Mr. Louwrentius.
Leuk om te lezen.Ga zo door!

[mkools24]

Onvoorstelbaar dat een bedrijf als TransIP RAIDZ1 gebruikt. Ik heb een colo server in een DC en zelfs daar gebruik ik mirrored ZFS. Zelfs RAIDZ2 of 3 zou ik niet aanbevelen, hoewel het in ieder geval beter is dan 1.

[rbroen]

Betere schijven is geen vervanging voor redundancy en/of backups.
Op de lange duur gaat alles een keer stuk, Murphy will come.

Hou er altijd rekening mee dat alles stuk kan gaan. Zorg altijd voor plan b.

[mcDavid]

Dat is wel héél kort door de bocht. Zonder verdere informatie over de grootte van de zpools valt er weinig zinnigs te zeggen. Ze zullen vast geen 24 disks in één RAID-Z1 pool hebben. Zolang de pools behapbaar blijven en de disks van een beetje kwaliteit zijn, is er niets mis met RAID-Z1.

[jDuke]

Het aantal disk is altijd een probleem geweest met RAID-5 / RAID-Z1, tegenwoordig (al lange tijd geleden eigenlijk) is RAID-5 een issue, statistisch gezien is de kans op een onherstelbare leesfout dat je onmogelijk de hele schijf fout vrij kan lezen. Dat is al jaren het idee dat RAID-5 "dood" is. Daarnaast duurt het opnieuw opbouwen van je RAID array zo lang tegenwoordig (grote schijven, TransIP geeft al aan 1,5 week) dat in die tijd de andere schijven constant bezig zijn, als je dit online doet dan worden de schijven zeer zwaar belast. Meestal komen die schijven uit een enkele productie batch, waardoor de kans op fouten erg ophoopt.

[klakkie.57th]

Dan stel ik me toch wel vragen. 1,5 week Mijn Raid60 array met 72 disks is toch echt wel klaar op 48u wanneer een 14TB harddisk failed.

[Epidemias]

TransIP maakt waarschijnlijk gebruik van SMR disks (= goedkoper) terwijl jij gebruik maakt van CMR disks.
SMR (Shingled Magnetic Recording) is retetraag. Dit word opgevangen door een deel CMR (Conventional Magnetic Recording) sectoren aan de disk toe te voegen. Hier word dan data naar toe geschreven, en op een dood moment verplaatst de firmware van de disk de data van het CMR gedeelte naar het SMR deel.
Voor het meeste gebruik is dit ok, maar voor een raid rebuild (of ZFS resilver) zit je bij 6TB disks al snel aan een week.

[klakkie.57th]

Ok, sowieso gebruik ik natuurlijk ook SAS12 disk en dedicated controllers.
Doe je dat niet dan zoek je natuurlijk problemen. maar ik mag hopen dat een "cloud" provider zijn hardware zaakjes toch wel voor mekaar heeft ...

duidelijk niet

[Reactie gewijzigd door klakkie.57th op 23 juli 2024 17:13]

[wankel]

TransIP maakt waarschijnlijk gebruik van SMR disks (= goedkoper) terwijl jij gebruik maakt van CMR disks.
SMR (Shingled Magnetic Recording) is retetraag. Dit word opgevangen door een deel CMR (Conventional Magnetic Recording) sectoren aan de disk toe te voegen. Hier word dan data naar toe geschreven, en op een dood moment verplaatst de firmware van de disk de data van het CMR gedeelte naar het SMR deel.
Voor het meeste gebruik is dit ok, maar voor een raid rebuild (of ZFS resilver) zit je bij 6TB disks al snel aan een week.

De werkwijze die je beschrijft geldt voor device-based SMR. Bij host-based SMR kunnen schrijfacties eerst naar een andere (non-SMR) schijf geschreven worden. Het OS/een logica-laag buiten de harddisk-firmware regelt dan het schoonmaken en opnieuw beschrijven van de SMR-disks.

Het schrijven an sich van een SMR disk kost niet meer tijd dan bij reguliere (bestaat dat nog?) harddisks, de vertraging zit erin dat -analoog aan een SSD- de reeds geschreven data gelezen en opnieuw geschreven moet worden om aanpassingen te maken.

Zoals hierboven ook aangehaald: de lange doorlooptijd ligt vooral in het online resilveren van een systeem under load.

[jDuke]

Online met een limit op de snelheid van het rebuilden. Daarnaast is een RAID-Z rebuild wel iets anders dan een Raid60 rebuild. Je hebt met de striping erbij hoe dan ook rebuild winst.

Maar denk dat het komt door de rebuild op lagere gelimiteerde snelheid te doen, nu is een degraded array hoe dan ook al trager dus om daar een rebuild tussendoor te doen zal het allemaal nog trager worden.

Maar met 72 disks van 14TB, 2 disk failures aan kunnen vind ik ook wel gewaagd mits het voor een storage in productie. Thuis is het natuurlijk wat anders ;-)

[klakkie.57th]

Nee hoor 6 R6 volumes van ieder 12 disks, die samen een raid 60 vormen

[jDuke]

tja, als je dat gelijk erbij zegt dat verklaard dan een hoop waarom het dan 48 uur duurt

[Hakker]

Hoezo het maakt niet uit hoeveel schijven er in een pool zitten. Het is afhankelijk van de grootte van de schijf en de snelheid waarmee geschreven kan worden. Of er nu 6 schijven van 14TB zijn of 72 van 14 TB dat maakt voor je rebuild proces helemaal niks uit. De schijf die vervangt zal altijd het langzaamste deel zijn in je rebuild.

[jDuke]

Je hebt effectief 6 RAID6 arrays, als je 1 schijf vervangt wordt 1 RAID 6 array opnieuw opgebouwd, dus data van 12 disks en niet van 72 disks. Dat scheelt zeker wel een hoop tijd... Als je diezelfde schijven in 1 RAID6 array zou doen zal het rebuilden ook wat langer duren... Dat komt omdat 1 zo'n RAID 6 array kleiner is dan 1 grote array.

Het aantal schijven maakt meestal wel wat uit, want meer schijven is een grotere volume en dus meer data, aangezien dit op block level gebeurd maakt het niet uit hoeveel data op je filesystem hebt staan, zo'n array gaat alles langs.

[Reactie gewijzigd door jDuke op 23 juli 2024 17:13]

[Ultra]

Ligt ook aan hoe je je RAID-60 hebt opgebouwd.

[Henk Poley]

Dan hebben ze mogelijk van die SMR schijven in hun RAID zitten.

While all three CMR drives comfortably completed the resilver in under 17 hours, the SMR drive took nearly 230 hours to perform an identical task.

Src: https://www.servethehome....r-tested-avoid-red-smr/2/
Video: https://youtu.be/8hdJTwaTl8I

9 en een halve dag voor 4TB drives..

[Reactie gewijzigd door Henk Poley op 23 juli 2024 17:13]

[beerse]

Van een raid-spec van 15 jaar geleden herinner ik mij dat voor een rebuild van een schijf gerekend moet worden met een kwartier per GB. Een rebuild van een schijf van 1 TB duurt in dat geval dus 1024 kwartier of wel 256 uur.

Dat is niet omdat het zoveel tijd kost om alles 'effe snel' voor elkaar te krijgen, maar omdat de raid ondertussen gewoon online is en dus gebruikt wordt. Dat gebruik wordt niet al te veel geblokkeerd.

Enneh, het is dat met zo'n doorlooptijd gerekend moet worden. Dat wil niet zeggen dat het zo lang duurt, meestal is ze sneller klaar omdat de raid niet tot haar strot vol zit.

[Bigs]

Toch wel. Als je grote trage schijven gebruikt is de rebuild tijd gemakkelijk meerdere dagen waarin je array dus onbeschermd is. Het aantal spindles heeft hier weinig invloed op. Zoals @jjkester al aangeeft loop je juist in dit soort situaties bijzonder veel risico.

[mcDavid]

Ja, dat klopt, daarom is RAID ook geen backup. RAID is enkel risicospreiding. Als je een array van 3 of 4 disks hebt, is het risico dat er 2 tegelijk defect raken écht heel beperkt. Als je een array van 8 disks hebt, wordt dat risico natuurlijk een stuk groter.

Raid-Z2 of Raid-Z3 kan het risico óók verminderen, maar de kans dat er meer disks uitvallen dan je aan pariteit hebt, blijft altijd bestaan.

Kortom er is geen heilige graal. Je moet een afweging maken hoe groot de faalkans is, hoeveel disks er in je pool zitten, hoe lang het resilveren duurt, etc.. En als je echt alle kans op dataverlies wilt uitsluiten, moet je backups maken.

[Raymond Deen]

Ze spreken over honderden gebruikers die een deel van hun data kwijt zijn.
Dan begin ik me wel af te vragen wat de topologie is, want dat is met een zpool van zelfs 24 disks moeilijk af te vangen kwa data-omvang. Geneste pools misschien?

[FreqAmsterdam]

Verbaasd mij niet. Het is een gratis dienst zonder al te veel garantie.

[tom.cx]

Ze hebben inderdaad altijd duidelijk erbij gezet dat er geen backups worden gemaakt.

[TWeaKLeGeND]

Ik neem aan dat de meeste gebruikers, gratis en betaald, stack als backup gebruiken voor live data, en dat die data ook nog lokaal een offline backup heeft.

Het 'zou' dus ook niet uit moeten maken, vooral voor gratis ja.

[The Zep Man]

Het 'zou' dus ook niet uit moeten maken, vooral voor gratis ja.

Wat je eigenlijk zou willen hebben is dat een (lokale) online backupoplossing automatisch de data die TransIP nu mist opnieuw synchroniseert. Pas dan maakt het echt niets uit. Anders ben je nu wel blijvend een backup kwijt, tenzij je handmatig acties uit gaat zetten.

[beerse]

Zo gaat dat bij mij precies. De pc-s en zo gaan naar de nas. De nas gaat 2 keer per maand naar Stacker. Dat is een job die de komende keer misschien wel veel langer gaat duren omdat ze alles weer over moet zetten. De job is zo ingericht dat ze alle bestanden controleert en niet alleen maar kijkt naar wat nieuwer is dan de vorige backup.

[Oon]

Je zou dan verwachten dat ze de gratis en betaalde dienst helemaal opsplitsen, Z1 voor gratis en Z2 voor betaald, met extra redundancy door back-ups.

Maar goed, het is een dienst die ze langs hun primaire bezigheden hebben opgezet, daar zal ook geen groot deel van hun budget ingestopt zijn.

[Xfade]

Je zou denken dat het gesplitst is, want betaald is niet betrokken, plus transip maakt backups voor die groep.

[mj.oke]

Bij het lezen van dit bericht had ik dat ook: ow, mijn data stond dus ook op die server, niet verwacht

Er is wel een verklaring (mogelijke)

Ik ben een tijd geleden over gegaan van de gratis stack naar nu een betalende klant, 3,03 per maand
voor dat bedrag heb ik dus de oude 1Tb plus de 250gb en dus ook nog de backupfunctie
3,03 euro per maand voor 1.250gb plus ssh toegang en backup

dus ik ben betaalde klant, ze zullen de data van mijn oude gratis stack niet van deze server hebben verhuisd en dus gelukkig wel een backup hebben gemaakt
ik kreeg ook een melding op het stack desktopprogramma (er is een backup detected).


en in mijn mening, 1 backup is geen backup, 3 dubbel 4 dubbel ... --> daarbij heb ik dan ook nog oudere versies, of dom verwijderde oude zooi, of bij een hack, mogelijk niet alle backups encrypted

[Amanoo]

Ik wist dat niet over het falen bij het herstelproces. Maar ik ben dan ook geen bedrijf dat cloud storage aanbiedt.

En zelfs dan was ik van plan om RAID-Z2 in mijn thuisserver te gaan gebruiken. Alsnog ben ik verbaasd dat er niet op zijn minst 2 disk redundancy was.

[teek2]

Mja, als je 1TB gratis aanbied heb je niet veel ruimte voor redundancy.

[selcukb006]

is raid Z1 beter dan raid 1? raid 1 was dat je data wat of schijf 1 zit, ook met een andere schijf deelt om tijdens failurehet te herstellen. is Raid Z1 dan data wat op 1 schijf zit delen met 3 andere hardeschijfen ?

[bolke de beer]

Inderdaad, zet daarom bv ook niet twee dezelfde schijven met dezelfde leeftijd in je NAS thuis, die aanbeveling heb ik hier al vak genoeg gelezen. Lijkt me volkomen logisch.

[Dilkooo]

Ze moeten bij transip misschien wat meer investeren in pro-actief onderhoud. ik heb in de laatste paar maanden echt wekelijks vpsen die down zijn omdat schijven stuk zijn. Ook veel problemen gehad met bigstorage die had meerdere dagen downtime. Support is vervolgens alleen maar brutaal en zeer traag. Ik had Transip altijd hoog zitten maar ze zijn tegenwoordig echt waardeloos.Wij zijn momenteel bezig met alles daar weg te migreren.

ps wat ook jammer is, dat ze geen publieke statuspage hebben. Dit hoort wat mij betreft gewoon transparant te zijn.

[Reactie gewijzigd door Dilkooo op 23 juli 2024 17:13]

[Kronossan]

Wij zijn ook stukje bij beetje aan het weg migreren. Dat hele proces kost stiekem heel veel centen dus het is niet voor de lol...

Feitje trouwens: als je tweetrapsauthenticatie inschakelt op je TransIP account, schakelt ook automatisch SMS-authenticatie in (of in andere woorden: als je de voordeur sluit gaat vanzelf je garagedeur wagenwijd open)

[FvdM]

ps wat ook jammer is, dat ze geen publieke statuspage hebben.

Zie TransNOC, al heb je daar alleen wat aan op het moment van een storing zelf. Er staat geen geschiedenis op.

[slijkie]

Mijn vriendin kreeg recent een mail, dat was inderdaad zo’n 1,5 week geleden. Ze heeft de gratis versie met nauwelijks data erop.

De mail:

Van: TransIP Support <[e-mail]>
Verzonden: Monday, September 28, 2020 1:29:44 PM
Aan: ***********
Onderwerp: STACK incident 28-09-2020

Beste klant,

Hierbij willen we je informeren over een probleem met je STACK (**********) dat optreedt sinds 13:08:28. We houden je graag op de hoogte van de status van het incident via https://transnoc.nl/incident/************/nl

Je ontvangt nogmaals een e-mail van ons wanneer het probleem is opgelost. Onze excuses voor het ongemak.


Met vriendelijke groet,

TransIP

[KriSH]

/ Stopzetten van gratis STACK-accounts
Beste klant,

In september en oktober zijn we opgeschrikt door een tweetal incidenten met STACK. Door het tegelijk defect raken van meerdere harde schijven, is een deel van de data van enkele gratis STACK-accounts aangetast. Van de gratis STACKs worden geen back-ups gemaakt, wat ertoe heeft geleid dat er bestanden verloren zijn gegaan. Dat betreuren we zeer.

De STACK-infrastructuur is zo opgezet dat een kapotte harde schijf automatisch wordt overgenomen door een reserveschijf. Data wordt zodanig verdeeld dat bij een defect deze data hersteld wordt. Sinds de start van STACK heeft dat nooit tot problemen geleid, tot afgelopen september. Door het tegelijk kapotgaan van meerdere harde schijven op één storageserver zijn STACKs aangetast. Een kleiner, maar vergelijkbaar incident heeft zich vervolgens voorgedaan in oktober.

Daaruit blijkt dat wij de data-integriteit van gratis STACK niet meer kunnen garanderen, wat niet past bij de kwaliteitseisen die we stellen aan onze producten. Daarom hebben we de moeilijke keuze moeten maken om op korte termijn te stoppen met de gratis 1TB STACK-accounts.

Wat betekent dit voor jou?
Binnen drie maanden zullen alle gratis STACK-accounts worden stopgezet. We geven je in deze periode graag meerdere opties om je data veilig op te slaan. Dit zijn:

1. Je gratis STACK upgraden naar een betaalde STACK. Hierbij wordt er dagelijks een back-up gemaakt van je volledige STACK. Je krijgt dan meteen 50% korting voor de eerste 12 maanden.

2. Je gratis STACK-account opzeggen. Je data wordt dan direct door ons verwijderd.

3. Wil je wel je data behouden dan kan je nu alvast beginnen met downloaden. Op 10 februari wordt je data door ons verwijderd.


We vinden het vervelend dat we deze keuze hebben moeten maken. Gratis STACK heeft ons en vele gebruikers veel plezier gebracht. In dit artikel vertellen we je meer over de geschiedenis van STACK en hoe we tot dit besluit zijn gekomen.

Heb je naar aanleiding van deze mail nog vragen? Hier vind je meer details terug, geven we een dagelijkse statusupdate en staan de antwoorden op de meestgestelde vragen. Vind je daar niet het antwoord dat je zoekt? Dan is onze supportafdeling eveneens maandag t/m vrijdag van 09:00 tot 24:00 uur beschikbaar voor je vragen.

Met vriendelijke groet,

Frank Schreuder
Managing Director TransIP

[ManIkWeet]

TransIP verving daarom de defecte schijf en moest de data opnieuw verdelen over alle schijven binnen de server. Dit proces duurt volgens het bedrijf meestal anderhalve week. Tijdens het herverdelen ging echter een tweede schijf stuk. Omdat het herverdelingsproces nog niet klaar was, is de integriteit van de data volgens TransIP aangetast. TransIP benadrukt dat het nooit eerder is voorgekomen dat een tweede schijf tijdens het herverdelingsproces is stukgegaan.

Anderhalve week? Hoe groot/langzaam zijn die schijven?
De kans dat een tweede schijf kapot gaat terwijl ze anderhalve week extra belast worden lijkt mij niet zo gek...

[svenslootweg]

Is vrij gebruikelijk bij systemen die onder zware load draaien, zeker in het geval van HDDs (t.o.v. SSDs). Bedenk dat de I/O load tijdens herstel niet alleen die van het herstellen is, maar ook die van het normale gebruik van de data daarbovenop; zeker als daar veel random reads tussen zitten, kan het lange tijd duren voordat je array hersteld is.

Dit is overigens ook waarom beheerders van grote arrays vaak schijven van verschillende merken / uit verschillende batches kopen - in de hoop dat dit de kans op gelijktijdige defecten vermindert. Of het ook daadwerkelijk effect heeft in de praktijk is me echter nooit duidelijk geworden.

[Piemol]

Ik ben getipt door een data recovery bedrijf,
om ná starten van het volume simpelweg om de x maanden/jaren al schijven te gaan vervangen, om te voorkomen dat meerdere schijven met hetzelfde aantal draaiuren in het volume zitten en daarmee de kans te verkleinen dat meerdere vlak na elkaar kuren gaan vertonen.
Dus je gaat echt preventief (ruim van te voren!) schijven vervangen om te in ieder geval te voorkomen dat ze allen dezelfde draaiuren hebben.

[sapphire]

Dan kun je met een deel van die vervangen schijven +nieuwe toch weer een 2e array maken?

[mjl]

Inderdaad, de ‘niet heel oude’ schijven plus wat nieuwe, dan heb je meteen daar een fee van opgevangen.

Overigens is het niet raar dat tijdens een ‘rebuild’ een andere schijf kapot gaat. Er is dan veel extra activiteit waardoor de schijven zwaarder belast worden, coral bij ouderwetse raid 5 of 6 is dat een bekend fenomeen en bij raid-z vast ook wel.

[Reactie gewijzigd door mjl op 23 juli 2024 17:13]

[Vullisbak]

Storage clusters geven meestal aan dat een schijf 'predictive maintenance' nodig heeft. Dat geeft doorgaans voldoende tijd om de schijf te vervangen. Er is natuurlijk kans dat je schijf nog maanden/jaar meegaat, maar de vraag is of je het risico wilt lopen om in een situatie als dit te komen.

[cariba]

Ik doe ook zoiets iets, iets minder betrouwbaars waarschijnlijk, maar wel beter dan niets en je bent vanaf het begin wat veiliger:

Als het om een raid setup gaat, koop ik de ene batch schijven op plek A, en den andere op plek B. Zo heb je een grotere kans dat ze uit een net iets andere productierun komen.

[wankel]

Ik ben getipt door een data recovery bedrijf,
om ná starten van het volume simpelweg om de x maanden/jaren al schijven te gaan vervangen, om te voorkomen dat meerdere schijven met hetzelfde aantal draaiuren in het volume zitten en daarmee de kans te verkleinen dat meerdere vlak na elkaar kuren gaan vertonen.
Dus je gaat echt preventief (ruim van te voren!) schijven vervangen om te in ieder geval te voorkomen dat ze allen dezelfde draaiuren hebben.

Bijkomend voordeel is dat je dat zelf kunt plannen. Je kan dan rustig je draaiboek afwerken, zonder dat je 's nachts in een stresssituatie op zoek moet gaan naar de juiste procedure.

[RefriedNoodle]

Eens.

Dat niet alleen: als je een rebuild doet na het vervangen van een defecte schijf, worden de overgebleven schijven nog eens extra belast door continu te lezen (naast regulier lees/schrijf-werk als je in productie bent), wat de kans op een defect nog meer vergroot.

[Q]

Leuk idee, voor thuis, maar in een business-setting op schaal ga je dat gewoon niet doen, dan los je dit soort risico's anders op .

[Arcastin]

Ik vroeg mij ook al af "hoe groot is de kans dat er op korte termijn een 3e schijf kapot gaat?".

Best wel aanwezig die kans dus als je van die logica uitgaat.

[JAVE]

Het is simpele kansberekening. De MTBF van een bepaalde batch zit dicht bij elkaar. Ander merk of batch betekent een andere MTBF.
Je kan ook schijven pakken die al een bepaald aantal uur hebben gedraaid in combinatie met nieuwe.

Een tijdje terug was er een item over SSD disks die zichzelf brickten na x uur aan te hebben gestaan. (van HP meen ik).
Moet je voorstellen dat je een array van die dingen maakt die allemaal vanaf de eerste minuut in die array draaien...

[bonus]

Kan ook zijn dat de koeling niet in orde was / dat het te warm in de ruimte is geweest. Dan kan je wel MTBF hebben maar daar kan het ook niet voor compenseren want dat is daar niet in mee genomen lijkt me. En als er dan al 2 gaan zou ik de rest ook meteen bekijken. Maar idd het kan ook een batch zijn

[justme256]

Een tijdje terug was er een item over SSD disks die zichzelf brickten na x uur aan te hebben gestaan. (van HP meen ik).
Moet je voorstellen dat je een array van die dingen maakt die allemaal vanaf de eerste minuut in die array draaien...

Dell/EMC had hetzelfde probleem. Is met een firmware update van de schijven opgelost.

[svsoke]

Een raid-array herbouwen kost vooral meer tijd naarmate de array groter is qua volume, zie deze calculator.

Je hebt gelijk dat de kans wat groter is onder stress, maar een raid herbouwen is vooral lezen van je correctie codes en het resultaat wegschrijven naar je nieuwe disk. De extra stress is dus minimaal.
Daarnaast heb je te vertrouwen op de mean-time-between-failures die de disk fabrikant aangeeft, wat in de jaren zou moeten liggen.

Al met al, dit is meer gevalletje pech denk ik zo dan echt lanksheid.

[3raser]

Ik vraag me af of TransIP de rebuild op volle snelheid uitvoert. De raid-array wordt ondertussen namelijk ook door klanten gebruikt en als de array vooral bezig is met het lezen van correctie codes om de nieuwe schijf van data te voorzien dan blijft er minder tijd over om klanten van data te voorzien. Mogelijk zoeken ze hier een balans in waardoor het herstellen van de nieuwe schijf nog langer duurt.

[Blokker_1999]

[...]

Anderhalve week? Hoe groot/langzaam zijn die schijven?
De kans dat een tweede schijf kapot gaat terwijl ze anderhalve week extra belast worden lijkt mij niet zo gek...

Mij wel. Zoals TransIP aangeeft is het bij hen nooit eerder voorgekomen al weten we daarmee dus niet hoe vaak ze zo een rebuild hebben moeten doen. Daarnaast is de levensduur van zo een schijf de dag van vandaag veel groter dan de commerciële levensduur van de server waar deze in zit en worden ze dus meestal geconsolideerd voordat ze defect gaan. De kans dat twij schijven bijna op hetzelfde moment falen is dus altijd enorm klein, maar niet onmogelijk.

[scsirob]

Die levensduur is een weinig begrepen factor. Er wordt geschermd met MTBF getallen van 1.000.000 uur wat door gebruikers vaak vertaald wordt met "Deze schijf gaat dus 114 jaar mee"

MTBF werkt alleen bij grote aantallen. Als je schijven met 1.000.000 uur MTBF gebruikt en je hebt er 10.000 in een datacenter draaien, dan kan je er redelijk van op aan dat er gemiddeld elke 100 uur eentje stuk gaat. Dus eens in de 4 dagen ruwweg. Heb je RAID groepen met veel schijven dan is de kans dus redelijk dat de volgende defecte schijf in dezelfde groep zit (zeker als de schijven uit dezelfde productie batch komen). Met data loss tot gevolg.

De oplossing ligt redelijk voor de hand. Kijk in je SLA. Als daar in staat dat de provider onafhankelijke backups maakt, dan moet de provider daarop kunnen terugvallen om je data terug te krijgen. Staat er niets over in je SLA? Dan lijkt het me heel verstandig als je zelf backups maakt.

[WillySis]

Niet alleen de grootte van de schijven is bepalend. Het is de omvang van de totale array. Als de array uit 10 schijven bestaat is er gewoon een probleem als binnen die array twee van de schijven uitvallen.

[Xieoxer]

Op zich is dit niet zo gek hoor. Als je grote schrijven hebt met een opstelling van 8TB in een RAID 5 opstelling, kan het ongeveer 26 uur duren voordat de RAID weer geresilverd is. Dit zijn spannende uurtjes, omdat in die periode al je schijven flink worden aangesproken (I/O). De kans bestaat dat er nog een schijf stuk gaat. Inmiddels zijn er nieuwere technieken zoals ZRAID. Met ZRAID kun je behoorlijk los gaan hoe je precies de verdeling wil hebben en hoeveel schrijven er mogen gaan in een pool. Alleen zoals altijd, gaat het te kosten van capaciteit.

Daarom hebben wij op ons werk voor setup gekozen van RAID-Z3 opstelling, waarvan 3 schijven stuk kunnen gaan van de pool. Tevens zit er in de server een extra schijf dat direct als een schijf stuk gaat gebruikt wordt in de pool voor het resilveren. Om het extra redundant te maken hebben wij gekozen om Gluster (https://www.gluster.org/) daarvoor in te zetten. We hebben twee exacte machine staan die de data continue met elkaar syncen, en voor de eindgebruiker wordt gezien als 1 netwerk schijf. Hierdoor kan 1 machine fysiek uitvallen, zonder dat we de data kwijt zijn.

[Reactie gewijzigd door Xieoxer op 23 juli 2024 17:13]

[wankel]

(.... 4-level RAID...) Hierdoor kan 1 machine fysiek uitvallen, zonder dat we de data kwijt zijn.

Ook met slechts 1 machine kan die fysiek uitvallen zonder data kwijt te raken; met RAID gaat het om 'R'edundanie: je merkt, als gebruiker, niet dat er een machine uitgevallen is.

Je kan gewoon doorwerken en data raadplegen/opslaan, ookal is er een machine uitgevallen en is in de andere de 2e redundant disk uitgevallen terwijl de resilvering op je hot spare plaatsvond. Gaaf ! :-)

[bzzzt]

Probleem is dat schijven niet langzamer geworden zijn, maar wel veel groter. Doorvoer van draaiende roest is de laatste 10 jaar hooguit verdubbeld, de capaciteit bijna een factor 10. Het duurt dus 4-5x zo lang om een grote harde schijf uit te lezen dan 10 jaar geleden...

[Scriptkid]

Dat is een van de rede dat de meeste grote data systemen niet meer vertrouwen op RAID en backup maar liever met meerdere applicative allways on draaien.

Dat houd in dat meerdere servers een copy draaien en je altijd met high speed van een inactive een rebuild kunt doen naar een failed disk terwijl er nog andere meerdere online zijn

[Boermansjo]

Aangezien het hier enkel over het gratis gedeelte gaat, zullen ze wel een iets betere backup hebben voor betaalde klanten.
Hoe kan je anders 250k TB (ofwel 244 PB) gratis weggeven en dan nog super hoge backup kosten spenderen ?
Ik heb zelf een van die gratis accounts. Die 1TB is altijd lekker om in de cloud te hebben. Staat er data op die belangrijk is ? Nee.
Dit soort dingen kunnen altijd voorkomen.

[Marchel]

Inderdaad dat bedacht ik me ook. Als het een week duurt om een schijf te herstellen, lijkt het me best aannemelijk dat het kan voorkomen dat in die week nog een disk defect raakt. Dat het systeem een 2de defect niet kan permitteren is kwalijk, alhoewel het natuurlijk een gratis dienst is. Wat mag je hiervan verwachten?

Deze dienst is opgezet om nieuwe klanten te vinden, soort marketing machine. Zodra ze uitgelegd krijgen wat de beperkingen zijn, schakelen ze snel over naar de betaalde dienst. Dat lijkt me het doel van dit platform.

[rsbroer]

Is toch niet zo vreemd dat tijdens herverdelen data nog een disk faalt ?
Zie niet in hoe dit anders is dan een rebuild van een RAID; de resterende schijven worden namelijk extra flink belast.

Ik hou het wel bij mijn eigen backups. 3 x 12TB waarbij #2 en #3 regelmatig van plek verwisselen op een buitenhuis lokatie

[mcDavid]

Met ZFS is dat wel degelijk anders dan een rebuild van een "gewone" RAID. Ten eerste zijn er checksums voor alle data zodat er geregeld gecontroleerd kan worden of de integriteit nog in tact is, waardoor de kans dat data-errors pas tevoorschijn komen bij een resilver klein is. Ten tweede kun je ook partiële data herstellen, bijvoorbeeld als een deel van een disk onleesbaar is. Je kunt dan gewoon doorgaan met resilveren en je krijgt een rapport welke bestanden onherstelbaar beschadigd zijn.
Lijkt erop dat ze dat nu aan het doen zijn. Met een beetje mazzel krijgen de meeste van die klanten dus gewoon hun volledige (of iig een groot deel van hun) data terug.

[Oon]

Ik heb een server met 10x10TB in Raidz2, maar ik moet toch eens gaan kijken voor offsite backups. Heb wel wat her en der verspreid over verschillende clouddiensten, maar niet echt een backup die ik terug kan zetten als het ooit nodig zou zijn.

Maar probeer maar eens 65TB aan opslag te vinden ergens voor een bedrag waar je geen nier voor hoeft te verkopen. Google had het, maar die gaan het nu niet meer aanbieden, en bij veel andere diensten ben je gewoon 10 euro per maand kwijt voor 1TB. Denk dat ik maar moet hopen dat mijn schijven het volhouden tot betaalbare 100TB schijven bestaan.

[mysterion1989]

https://www.youtube.com/watch?v=_8OMN08VQ6A

[SCS2]

voor een bedrag waar je geen nier voor hoeft te verkopen.
Mooi, vooral als je je bedenkt dat het vaak maandelijkse / jaarlijkse bedragen zijn ...

extra: (Ik bedoel dat je maar 2 nieren hebt)

[Reactie gewijzigd door SCS2 op 23 juli 2024 17:13]

[Oon]

Ja, precies. Het is echt belachelijk wat sommige diensten rekenen voor een paar terabyte aan opslag. Als voorbeeld:

Bij Dropbox ben je voor 3TB al 20 euro kwijt, met een optie voor €18/gebruiker (min. 3 gebruikers) voor 'onbeperkte' opslag (tussen haakjes want je begint met een paar TB en moet contact opnemen met support om deze steeds iets te verhogen als je het limiet bereikt) dus €54 per maand

OneDrive heb je voor 10 euro per maand 6TB in je family plan (maar 1TB per gebruiker) en kun je voor €10/maand 1TB bij kopen, met een €8,40/gebruiker optie voor bedrijven waar vanaf 5 gebruikers ook 'onbeperkt' opslag is, hier krijg je 5TB per gebruiker en daarna moet je net als bij Dropbox ook contact opnemen met support om het op te hogen

Google One heb je 2TB voor €10/maand, met het grootste pakket 30TB voor €150/maand. Google Workspace heeft Business Plus met 5TB per gebruiker voor €15.60/maand, daarna zit je bij Enterprise met oneindig maar moet je contact opnemen met sales voor een prijs.

Dat zijn dan de drie grootste partijen, maar deze bieden allemaal wel volledige cloud opslag (dus niet alleen een backup dienst). Ik vind dat toch vrij duur.

[netpete]

S3 Glacier Deep Archive kost je $0.00099 per GB per maand, oftewel bijna een dollar per TB per maand. Aangezien het jou om een backup gaat, lijkt me dit voor jou een optie? En nu ben je dan voor jouw 65TB 65$/maand kwijt, maar misschien kun je nog comprimeren? Denk wel aan de lange restoretijd.
Bron hier te vinden

[Oon]

Ja restore tijd is dan wel een dingetje. Ik heb nu een groot deel naar gsuite gesynct (wat nu binnenkort weg gaat vallen blijkbaar) waar je een limiet van ongeveer 750GB/dag hebt, dus dan zou een restore ook al meer dan twee maanden duren, maar daar betaal ik wel zo'n 12 dollar per maand voor.

Ik vind 65 dollar per maand te duur, voor dat geld kan ik ieder half jaar een schijf vervangen

[GrooV]

Idd draai thuis ook met 2 drive fault tolerance, kost inderdaad wat meer maar mijn data is belangrijker.

Zodra 1 disk faalt, meteen een nieuwe disk bestellen, volgende dag repairen. Binnen 1 dag klaar. Mocht er nog een disk overlijden tijdens een repair dan wordt dit nog steeds opgevangen. Deze dient dan echter ook direct vervangen te worden.

Schijf gaat RMA en daarna op de plank of op V&A. Mocht ik niet in de gelegenheid zijn om dit zsm uit te voeren dan gaat de NAS uit.

Na 3 jaar (of einde garantie) worden de schijven sowieso vervangen

[Reactie gewijzigd door GrooV op 23 juli 2024 17:13]

[devices]

Is het niet zonde om schijven al na 3 jaar te vervangen? Ik dacht dat die wel langer mee konden.

[mauritsl20]

20.000 uur draaien vervangen is verstandig om te gaan vervangen. Bij 50.000 uur zeker vervangen.
Maar ja het is casino en gevoelskwestie. Heb hier een HGST met 58000 uur en draait nog perfect.
Je kan ook gewoon wachten tot ze stuk gaan en 10 jaar nog niks hebben. Niemand weet het......
Bedrijven gebruiken vaak de 20.000-25.000 regel.
Zo koop ik vaak schijven die zodoende 18.000-28000 uren hebben omdat ze vervangen “moeten” worden. Gaan bij mij vervolgens nog jaren mee! Sterker nog van de 21 schijven is er 1 stuk na 7 jaar draaien.

[Reactie gewijzigd door mauritsl20 op 23 juli 2024 17:13]

[barrybaksteen]

En als er perongeluk een folder of file van de nas wordt verwijderd, danwel door jezelf of een virus?
Ook al heb je dan een raidset met een drive tolerance van 10 schijven, de folder en/of file ben je gewoon kwijt.

Raid biedt enkel bescherming tegen disk failures, maar elke andere fout betekent nog steeds dataverlies.

[tweaker2010]

Goede reclame voor TransIP. Deels overmacht natuurlijk, maar dit bevestigd weer wat de minpunten zijn van data in de cloud onderbrengen bij derde partijen waarbij de gratis accounts geen prioriteit hebben.

[wica]

Overmacht? Of een verkeerde keuze qua inrichting?

Als ik naar onze storage kijk. hebben wij altijd 3 kopieën van de data.verdeeld over 3 racks.
Als er 1 disk, server of rack uit valt. Is er nog niets aan de hand.
Valt er van deze zelfde data 2 disks, servers of racks uit. Dan stop ons systeem, juist om er voor te zorgen dat er geen data verloren gaat.
Ja, het is wat duurder. Maar data integriteit is voor ons alles.

[jpfx]

Ik zit eerder te denken aan dat ze een beleid hebben/hadden om schijven pas te vervangen bij failure.
En als dan schijven ook nog eens tegelijk worden vervangen, cq het nog nooit is gebeurd (gezien de startdatum van de service zou dat best mogelijk zijn), dan zitten alle schijven ook gelijktijdig aan hun mtf. En dan is het eigenlijk helemaal niet vreemd dat er een tweede schijf de geest geeft tijdens het herstelproces waarbij deze waarschijnlijk ook nog eens zwaarder dan normaal belast wordt.

[wica]

Klopt, het zou mij niet verbazen, dat in de logs al enkele weken meldingen worden weg geschreven. Die duiden op het uitvallen van een disk.
Anders gezegd, ik heb nog nooit mee gemaakt, dat een disk spontaan uitvalt en al helemaal niet een 2de in het zelfde systeem.

[hackerhater]

Het kan gebeuren. Dat heeft een oud-werkgever ook gehad met schijven van verschillende batches.
Van vrijdag op zaterdag begaf schijf 1 het en de resynch begon direct (hot spare).
Van zaterdag op zondag begaf de 2e het en viel de NAS in nood-modus (read-only) om data-loss te voorkomen.

[RefriedNoodle]

Maar heb je die 3 racks dan alsnog verdeeld over meerdere datacenters? Want als er een Boeing op je dc landt, ben je anders alsnog alles kwijt.

[wica]

Klopt, daar zijn we ook mee bezig. Omdat bepaalde klanten die wens idd hebben.

[draadloos]

Kan me ook niet voorstellen bij welke dienst gratis accounts wel prio hebben? Bij mij niet iig..

[wankel]

Kan me ook niet voorstellen bij welke dienst gratis accounts wel prio hebben? Bij mij niet iig..

Geen prio? In dat geval hadden ze geen data-rescue gedaan op de defecte schijf natuurlijk... Kostbare optie als het voor een no-prio doelgroep gedaan wordt.

[wankel]

Goede reclame voor TransIP.

Ja, dergelijke openheid van zaken bij een vervelend voorval spreekt inderdaad positief over een bedrijf.

[z.jeroen]

Hoezo openheid? Ze hebben alleen de groep mensen ingelicht wiens data onbereikbaar was, en de rest mag het via Tweakers lezen.

[bbob]

Laten we nu eerlijk zijn voor betaalde klanten is er een backup, voor gratis klanten niet. Het is een beetje bot te stellen dat gratis accounts geen prioriteit hebben. De schijven van gratis staan al in raid en dan kun je niet verwachten dat er ook nog eens een backup van gemaakt wordt.

Ik ga er ook van uit dat als je de gratis stack gebruikt dit ook voor jou een backup is en als het een primair systeem is je je data lokaal als backup hebt staan. Als je het niet als backup gebruikt of zelf geen backup hebt en ook nog eens alles gratis wil, tja dan neem je een risico, klein risico maar dat is gratis nu eenmaal.

[tweaker2010]

Wat wica hier ook al zegt. Een RAID opstelling is geen backup, als ik mijn NAS in RAID zet is het geen backup. Elke schijf kan kapot gaan en is sowieso onwenselijk dat het herstellen (lees: terug spiegelen) zoveel dagen duurt. Een Apple en Microsoft kunnen hier niet mee wegkomen, ook niet met gratis accounts.

[Razwer]

RAID opstelling = redundancy
Backup = redundancy
Zo zijn er nog meer zaken te noemen. Backups zijn allang niet meer de holy grail van redundancy. Dat was 20 jaar geleden zo

[wica]

Backup != redundancy.
Backup is alleen maar een moment opnamen van je data

Je hebt gelijk, dat backups allang niet meer de holy grail zijn.
Er zijn andere technieken om je data relatief veilig te stellen in realtime.

[beerse]

Raid is niet altijd data-opslag-redundancy!. Met raid-0 (de stripe-set) heb je disk-gebruik-redunancy om de lees en schrijf snelheid te verhogen.

Backup is redundancy in de vorm dat het 2 keer data ruimte vraagt en 2 keer beter beveiligd is tegen kwijt raken. Maar andersom geldt het niet: Redundancy is geen Backup.

En aan een backup heb je helemaal niets, een backup op zichzelf is nergens voor nodig. Het gaat er om dat je de restore van gegevens en recovery van systemen voorbereid. Beide hebben tegenwoordig steeds meer een verschillende backup nodig.

[sygys]

Meestal gebruik je dit soort diensten inderdaad als backup. Met heel veel pech zou het kunnen dat de hardeschijf van een klant ook net op dat moment crashed. Maar dan heb je wel echt veel pech.

[cadsite]

Laten we eerlijk blijven.
Als leek lees je dat allemaal niet door. Als ze het al verstaan.
Als leek nam je een account dat met veel bombardie bekend gemaakt wordt, dus ga je er vanuit dat het ook gewoon goed is.

[bbob]

Transip stack was volgens mij niet echt op de leek gericht.

[walteij]

Ook voor betalende klanten is er geen backup hoor, tenzij dat expliciet is aangegeven door de cloud leverancier.
Bij TransIP inderdaad wel backup voor betalende klanten. Maar dat is lang niet bij alle cloud providers het geval. Dat mag je in diensten als Azure, Google Cloud en Amazon gewoon nog zelf even inrichten.

Er is wel disaster recovery, dus als een complete site down gaat, dat je diensten dan op een andere site weer worden opgestart. Tussen sites is er echter a-synchrone synchronisatie, dus dan kan het zijn dat de DR locatie nog niet al je data heeft.

Wij hebben voor de cloud producten die we afnemen dus ook gewoon backup draaien. Voor Office365 zelfs gewoon een continuous backup, zodat daar geen enkele mail of document verloren hoeft te gaan. VM's in de cloud wordt 2 keer per dag een backup van gemaakt. Data wordt ook via continuous backup naar een andere site veilig gesteld.
Kost iets meer, maar 4-8 uur werk kwijt bij een DR event kost nog meer aan productiviteit.

[Reactie gewijzigd door walteij op 23 juli 2024 17:13]

[aadje93]

raid is een systeem om schijven samen te voegen, niet een backup systeem. Backup is 2 machines die fysiek uit elkaar zijn, bij voorkeur in verschillende data centra ver uit elkaar

[bbob]

Zeg ook niet dat raid een backup is, het is wel een veiligheid.

Geen raid, drive kapot betekend backup moeten gebruiken.
Eenvoudige raid, 1 schrijf kapot, geen backup moeten gebruiken.

Raid is dus als de eerste veiligheid om systemen draaiende te houden bij uitval van een schijf.

Backup heb je sowieso nodig. Datacenter in de fik of hele kast fikt uit dan is ook met raid je data weg.
Idem lokaal.

[tweaker2010]

RAID is schijnveiligheid, geen veiligheid. Elk een beetje serieus bedrijf die alleen RAID op 1 locatie heeft draaien kiest daarvoor vanwege de kosten. Het strookt niet met het 3-2-1 principe zoals je zelf al aangeeft.

[bArAbAtsbB]

Beste Bbob1970, is het niet gewoon zo dat men niet genoeg voorzorgsmaatregelen heeft genomen omdat de opeenstapeling van problemen zoals n u gebeurd is bijna niet voorkomt!

Je zou zeggen dat men is voorbereid op incidenten, blijkbaar voert men geen check uit op de HDD's alvorens de data te herverdelen.

[wica]

Raid is geen backup.

[Yggdrasil]

Nogal flauwe uitspraak omdat het in deze context niet relevant is.

[johanl79]

Dat zegt bbob ook helemaal niet.

[Huugje]

Feitelijk wel met zijn opmerking: "De schijven van gratis staan al in raid en dan kun je niet verwachten dat er ook nog eens een backup van gemaakt wordt."

[Razwer]

Dus zegt hij niet dat er een backup is, hij doelt op "een vorm van redundancy" en dat klopt. Niet zo snel gaan strooien met feiten

[Huugje]

Het is blijkbaar maar net hoe je die zin interpreteert. Zoals ik het lees ziet hij RAID als een volwaardige alternatief voor een backup (als in: er is geen backup nodig, want de schijven staan toch al in RAID). Jij leest er blijkbaar iets anders in. Prima.

[bbob]

Dan hier de oplossing van diegene die het gezegd heeft.

Raid is idd al een vorm een redundancy, is dat een backup, feitelijk niet maar het is wel een veiligheid als 1 schijf uitvalt. Voor een gratis service is dat op zich als een goede service.

Je kan het lokaal ook zien met raid, dat gebruik je in eerste instantie ook als veiligheid. Valt 1 schrijf uit neemt de rest het over.
Heb je geen raid zul je meteen een backup moeten aanspreken.
Wederom raid is geen backup maar wel een veiligheid om te voorkomen dat je eerder een backup moet aanspreken.

Nu kun je met raid ook verder gaan zodat er 2 schijven kunnen uitvallen en je kan ook nog 2 nas systemen nemen zodat de hele hardware van eentje kan uitvallen. Die kun je dan weer met glas in 2 datacenters zetten. Het gaat er uiteindelijk om hoe belangrijk is je dat en wat wil je er voor betalen.

Laten we gewoon eerlijk zijn bij gratis moet je niet zeuren en raid schijven geven normaal geen probleem als er eentje uitvalt. Dat dat nu gebeurt is hele kleine kans.

[Prince]

Een ander veel gemaakte fout is dat bij de opzet van een RAID opstelling vaak eenzelfde soort schijven van eenzelfde batch geplaatst worden. Dit betekent dat de 'slijtage' gelijk oploopt en dus de levensduur op ongeveer eenzelfde moment gedaan is. Ook is het spijtig dat ze maar 1 schijf hadden met partiteitsdata op ivp 2. Het is juist een gekend fenomeen dat tijdens de wederopbouw van de gegevens je niet enkel geen redundancy meer hebt, maar ook juist de schijven veel meer belast en dit juist het kritieke moment is waarop deze overige schijven ook kunnen falen...
Het is misschien een gratis dienst, maar dit betekent niet dat de dienst niet goed moet werken. De imagoschade zal meer kosten dan een paar schijven... Ik ga alvast minder vertrouwen hebben in de technische know-how van TransIP.

[GeroldM]

Je kan het lokaal ook zien met raid, dat gebruik je in eerste instantie ook als veiligheid. Valt 1 schrijf uit neemt de rest het over.
Heb je geen raid zul je meteen een backup moeten aanspreken.

Een gedachten-experimentje:
Gaat er echter nog een drive stuk, dan is er de rebuild-tijd. Hoe lang duurt het terugspoelen van een (complete) backup? Als het terugspoelen minder tijd in beslag neemt dan het rebuilden...waarom zou je dan nog je RAID rebuilden? Is het dan niet verstandiger/efficienter om een backup terug te spoelen?

En als het terugspoelen inderdaad efficienter is, waarom zou je RAID dan inzetten voor redundancy? Lijkt me dat in zulke gevallen RAID nog maar voor een ding goed is, rauwe snelheid. Spiegel je de main server op een andere soortgelijke server, dan neemt het maken van backups significant minder tijd in beslag.

[bbob]

Zo werkt raid niet. Wat jij aangeeft werkt als je geen raid hebt. Schijf kapot, backup terug naar nieuwe schrijf.
Idee van raid is schijf kapot nieuwe schijf er in je kan door blijven werken en parallel word de nieuwe schijf geupdate.
Bij jou thuis zal dat sneller gaan als je de schijven niet benaderd. Bij transip zal er veel verkeer zijn waardoor het in de achtergrond op langzamere snelheid moet gebeuren om er voor te zorgen dat systeem niet te traag gaat worden.

Raid is er in verschillende smaken, bij sommige kan 1 schijf uitvallen bij andere zelf 2.
Heb je geen raid ligt je systeem plat en data die niet op de backup stond ben je kwijt. Bij goed werkende raid heb je alle data nog, tenzij zoals nu 2 drives er eentje te veel is.

[eymey]

Het terugspoelen van een backup klinkt leuk, maar zoals @bbob1970 hieronder ook al aangeeft vormt ook dit een belasting voor 'productie' op een druk systeem. Bovendien zal een backup nooit helemáál actueel zijn. Er gaat dus hoe dan ook data verloren.

Het hele idee achter een goed opgezette RAID is zero downtime, als er een disk sneuvelt.

En inderdaad: Er bestaan bij goede RAID systemen ook varianten met een fouttolerantie voor 2 disks. Dat is natuurlijk een stuk duurder, maar als je jezelf als aanbieder van betaalde opslag serieus neemt zou je het eigenlijk wel gewoon moeten gebruiken.

In het geval van een dienst met zowel betaalde als gratis accounts zou je dan desnoods voor de gratis accounts een aparte pool op kunnen zetten.

[ayse]

Hey, ehm, raid wat? 1, 10, 5? Hoeveel pariteit en hoeveel data? Ik heb nu eigenlijk geen idee hoe redundant dit is.

[bbob]

interesse, zoek het zelf even op. Genoeg sites die je een uitleg geven.

https://en.wikipedia.org/wiki/Standard_RAID_levels
Heb op mijn synology 4 drives in raid 6, dan kunnen er dus in totaal 2 kapot gaan.

[ayse]

Ik ken de RAID levels wel, maar welk level gebruikt transip? In elk geval geen raid 6 of mirrored raid 5 want dan waren twee kapotte schijven geen probleem geweest.

[TommyboyNL]

RTFA. TransIP gebruikt RAID-Z1.

[bbob]

@ayse https://en.wikipedia.org/...andard_RAID_levels#RAID-Z

There are five different RAID-Z modes: RAID-Z0 (similar to RAID 0, offers no redundancy), RAID-Z1 (similar to RAID 5, allows one disk to fail), RAID-Z2 (similar to RAID 6, allows two disks to fail), RAID-Z3 (a RAID 7 [a] configuration, allows three disks to fail), and mirror (similar to RAID 1, allows all but one of the disks to fail).

m.a.w raid-z1 laat toe dat 1 disk kan uitvallen, bij 2de disk heb je dus een probleem.
Persoonlijk zou ik eerder gaan voor de optie dat 2 disks kunnen uitvallen.

zoals in deze thread al opgemerkt als 1 disk uitvalt en de andere zijn uit dezelfde serie is er een kans dat er nog meer uitvallen. Aangezien het dus tijd kost om nieuwe disk weer in het systeem op te nemen loop je idd de kans dat zoals nu gebeurt een 2de disk kan uitvallen en dan heb je een probleem.
Had je de optie met 2 disk dan was in de tussentijd de andere disk waarschijnlijk al actief of als er echt 2 uitvallen had je misschien moeten nadenken alles op een heel nieuw systeem te zetten aangezien er waarschijnlijk problemen met die disk zijn.

[mvrhrln]

Dacht wel dat het bekend was dat met de gratis versie er wat risico's waren.

[andreetje]

Transip voldoet nog steeds aan wat ze beloofd hebben, dus er is niets aan de hand.

[007Nightfire]

Ik heb een groot aantal (minder belangrijke) bestanden die ik toch wel wil bewaren op mijn pc staan en voor de veiligheid ook in STACK staan. Zolang mijn eigen hardeschijf niet tegelijk kapot gaat met twee hardeschijven van TransIP, zit ik goed. Precies omdat ik 1TB gratis opslag heb, verwacht ik geen wonderen, vertrouw ik niet blind op STACK en blijven de bestanden ook lokaal bij mij op de hardeschijf. Maar heb ik toch een gratis backup op een andere fysieke locatie.

Alternatieven zoals Drive heeft 17GB gratis en Onedrive 15GB, dat is misschien veiliger wat betreft kans op gegevensverlies maar wel fors minder opslagruimte en gebruik ik dan ook voor andere doeleinden. Ik denk dan ook dat er niets mis is met de manier waarop TransIP hiermee omgaat. Heb je toch die backup veiligheid nodig, dan is de gratis variant niet geschikt voor wat je ermee wilt doen en zal je de portemonnee moeten trekken.

[bbob]

TransIP back-upt de Stack-data van betalende gebruikers, volgens de woordvoerder is bij deze klanten dan ook geen data verloren gegaan.

Goede zaak dus dat er dan toch een backup is.
Voor gratis klanten kun je deze service ook niet verwachten en neem aan dat je de stack ook alleen als backup voor jou eigen data gebruikt en niet als enige plaats waar data staat.

[dbzokphp]

Ja en nee, je weet inderdaad van tevoren dat er geen backups zijn, want dat staat ook bij de gratis variant vermeld. Aan de andere kant vind ik het niet helemaal meer van deze tijd, gratis of niet.
Ik zie zoiets niet gebeuren bij je gratis Gmail account bij Google, of je gratis Hotmail account bij Microsoft. Daarbij verwacht je gewoon dat je data veilig is, en niet zomaar verloren kan gaan, ongeacht dat het gratis is.

[GertMenkel]

Het hele idee van STACK was dat je gratis storage kon krijgen met het risico dat je data verliest. De dienst is ontstaan uit oude harde schijven die eigenlijk over waren en waar TransIP iets mee wilde doen. Een gratis terabyte krijg je zelfs bij Google niet.

Ik weet dat dit risico er is en ik gebruik STACK zelf dan ook als tweede of derde backup; dat de data op een gegeven moment verdwijnt vind ik geen probleem, als het maar niet verdwijnt terwijl mijn andere backups verdwijnen.

Als je daadwerkelijk je belangrijke data toevertrouwt aan een product dat letterlijk bezigheidstherapie voor bejaarde schijven is, heb je duidelijk de verkeerde keuze gemaakt.

Op de verkooppagina staat ook heel groot dat er geen backups worden gemaakt zoals je zegt, als dat een betaalde feature is moet je toch kunnen bedenken dat je data er niet superveilig is. De term "veilige opslag" wordt dan wel weer gebruikt voor advertenties voor GDrive of OneDrive, daar zou ik er als gratis gebruiker wel van uitgaan dat er backups zijn.

[comecme]

Als het om oude schijven gaat is het wel apart dat op dezelfde server/schijven ook de data van wél betalende klanten staan.

[GertMenkel]

Ergens wel, aan de andere kant is het de eerste keer dat het zo hard mis gaat en hebben de betalende klanten hun data al lang terug. Aan de andere kant is het wel onhandig de data zo op te slaan.

Als er meer clusters falen denk ik dat transip vast en zeker andere schijven gaat gebruiken voor betalende klanten. Ik denk niet dat het veel problemen oplevert, aangezien dit de eerste keer is dat we iets hierover lezen. Schijven falen in iedere server, het zijn de backups die voorkomen dat je écht data verliest.

[z.jeroen]

Het is niet meer van deze tijd om te geloven dat Gmail een “gratis” product is. Google is een advertentiebedrijf en Gmail is een van hun extractiemiddelen voor het verkrijgen van gedragsdata. Uiteraard hebben ze die extractie goed op orde. Stack speelt een totaal andere rol bij Transip.

[Chris.nl]

Ik gebruik de gratis variant als backup / online versie voor een in de pc aanwezige schijf (die ik ook nogmaals offline af en toe een backup geef). Met WebDAV ook makkelijk m'n mobiel te gebruiken.

Maar ik mag toch hopen dat wanneer Slack bestanden 'kwijt' raakt ze deze opnieuw ophalen van m'n pc ipv ook verwijderen van m'n pc? Ik weet dat synchroniseren twee kanten op werkt maar hopelijk zien ze verschil tussen 'gebruiker heeft bestand gewist' en 'wij zijn iets kwijt geraakt'.

Desalniettemin blij dat ik offline nog een backup heb 👌

[BlackiE1982]

Inderdaad. Niet dat ik mijn pc aanzet en dan mijn bestanden één voor één worden verwijdert. Voor de zekerheid ga ik even de lan kabel eruit halen bij het opstarten en Stack even uitzetten tot nader bericht.

[mcDavid]

Jij hebt dus bericht gehad van TransIP dat jouw stack getroffen is? Wat stond daar precies in?

[BlackiE1982]

Jij hebt dus bericht gehad van TransIP dat jouw stack getroffen is? Wat stond daar precies in?

Nee, dat niet. Ik bedoel meer voor de zekerheid, maar ik realiseerde me na de opmerking dat het verlies van data al halverwege september is gebeurd. Na dat moment heb ik mijn pc al wel eens aangehad. Ik ga nu maar even checken of alles nog aanwezig is.

[Reactie gewijzigd door BlackiE1982 op 23 juli 2024 17:13]

[tom.cx]

Je kan ook niet vertrouwen op backups in cloud diensten. Een mooi voorbeeld was toen ook Megaupload. Er waren best wat mensen die deze dienst ook gebruikte als backup dienst. Toen ineens de stekker eruit ging door de ‘illegale’ activiteiten waren een hoop mensen ineens data kwijt en het is een deel toen ook niet gelukt alsnog de data terug te krijgen.

[Q]

Je krijgt waar je voor betaalt

[Chris.nl]

Klopt, ik verwacht ook weinig en schreeuw ook geen moord of brand. Vraag me dus enkel af of het data verlies niet naar de gebruiker wordt gesynchroniseerd.

[eborn]

De engineers van TransIP zijn er maar druk mee de laatste tijd. Het CEPH cluster (of clusters) waar de big-data omgeving door gebacked wordt heeft ook al een aantal keer flinke storingen gehad. Van het kaliber: het is stuk en we weten nog niet waardoor. Gelukkig zijn er inmiddels wat experts ingevlogen. Tot nu toe is er (zover bekend) nog geen data verloren gegaan, maar ik denk dat je als sysop niet heel lekker slaapt als je weet dat je storage oplossing voor veel van je VPS klanten een tikkende tijdbom is die je nog niet lekker onder controle hebt.

Gelukkig wordt je bij TransIP altijd wel keurig op de hoogte gehouden van de status.

[Reactie gewijzigd door eborn op 23 juli 2024 17:13]

[mcDavid]

Met een CEPH-cluster moet je ook wel héél hard je best doen om echt data kwijt te raken.

[c-nan]

Klopt, maar Ceph heeft al aardig wat kritische bugs gehad waardoor er data corruptie optreed. Als je dus tegen dit soort bugs aanloopt, kan je nog van alles proberen, maar het verhelpen doe je niet zomaar. Zie o.a. https://tracker.ceph.com/issues/42223.

[Bigs]

Mijn eerste reactie op dit bericht was 'wie gebruikt er anno 2020 nou nog ZFS ipv Ceph met erasure coding voor dit soort toepassingen', maar dat was dus ook niet zaligmakend geweest. Het beheer van Ceph clusters is absoluut iets wat je er 'niet even bij doet' aangezien hier ook zeer complexe problemen op kunnen treden. Zeker als je op het niveau werkt waarbij RAIDZ1 met grote schijven nog een goed idee lijkt.

[Charlie_Root]

Dit is wel echt vragen om problemen. Oude harde schijven, trage harde schijven, en Raid Z1. Sorry, hoe dom kun je zijn.

Bij Ceph moet je wel écht iets verkeerd doen wil dit gebeuren, veel stabielere oplossing maar ook dan moet je kiezen voor een juist replica.

[Ethirty]

Het verhaal en de reacties hieronder klinkt het alsof TransIP vooral op de verkeerde dingen bezuinigd en de klant daar de dupe van is. Maar gelukkig krijg je wel status updates.

Het verhaal maakt duidelijk dat ze het verkeerde RAID level hebben gekozen. 1 defecte schijf of RAID-Z (R5) is dus al jaren not done is met grote schijven en disk sets, juist omdat de rebuild zo lang duurt.

Ze hadden dus minimaal voor RAID6 / Z2 moeten kiezen. Het is dat het een gratis dienst is, maar anders had je ze denk ik wel aansprakelijk kunnen stellen voor het verlies van data.

Je mag als betaalde klant dus alleen maar hopen dat ze op die platforms wel betere beslissingen hebben genomen. Blijkt maar weer eens dat goedkoop leuk is, zolang er niks mis gaat.