Wat als de data in je systeem niet meer betrouwbaar is? En nog erger, wat als je niet eens weet dat de data onbetrouwbaar is geworden?
Stel je voor: je medisch dossier, dat is opgeslagen bij het datacenter van een medisch centrum maar geen back-up heeft, wordt op een of andere manier aangetast. In plaats van honderd miligram medicijnen krijg je ineens tien miligram toegediend. Of denk aan een financiële instelling die door bederf van data bepaalde overheidsregelgeving niet meer naleeft, zonder dit te weten. Of de bank die fouten maakt met gegevens van bankrekeningen (geloof me, dat soort dingen werken nooit in je voordeel). Of een cruciaal softwareprogramma werkt na een tijdje niet meer zoals het hoort. Denk aan de persoonlijke of zakelijke problemen die hiermee gepaard gaan. Zonder backups en het vermogen om deze 'bit rot' op tijd te signaleren blijven fouten in het systeem onopgemerkt tot het moment waarop het leed onomkeerbaar is.
Bit rot – de naam zegt het al – is een onopvallende ziekte in computersystemen die data binnen documenten en applicaties op den duur kan bederven. Met andere woorden, een of meer delen van bestanden raken beschadigd, wat zogenaamde 'silent data corruption' veroorzaakt. Een essentieel onderdeel van ieder bestandssysteem is dat het de precieze data die eerder geschreven is kan terughalen. Als dat niet meer mogelijk is, zou het systeem de fout moeten detecteren en rapporteren. Het vervelende is alleen dat de meeste moderne bestandssystemen dit soort fouten niet kunnen detecteren.
Belangrijk om te weten is dat dit probleem niet zomaar uit het niets ontstaat. De oorzaken van deze rotting zijn dan ook behoorlijk alledaags:
– Dupliceren van software: te veel van iets hebben is niet altijd gunstig. In dit geval gaat het om een overschot aan toolbars, apps, media, emailprogramma’s en firewall software dat uiteindelijk data kan beschadigen;
– Updaten, installeren en verwijderen: bij het updaten of aanpassen van software kunnen kleine beetjes data afval achterblijven in zowel het bestandssysteem als het register, oftewel de centrale database;
– Ouderwetse stuurprogramma’s of een gebrekkig moederbord: veroorzaakt beschadigingen in het geheugen (RAM), wat er toe leidt dat bits niet meer naar behoren werken;
– Malware, Spyware: hoewel dit niet een hoofdoorzaak van Bit Rot is kan malware een systeem erg traag maken en op die manier allerlei soorten dataverlies veroorzaken.
Om te beginnen is het aan te raden bovenstaande oorzaken zoveel mogelijk te vermijden.
Data corruptie is een van de meeste gevreesde zaken in het leven van een bestandsbeheerder. De dreiging van bit rot is reëel en kan een bedrijf op den duur schade toebrengen. Zorg dus voor betrouwbare oplossingen voor het kopiëren van belangrijke bedrijfsgegevens en voor het behoud van kritische data. Ieder bedrijf doet er goed aan om routinematig de betrouwbaarheid van data te verifiëren.
Het is een heel algemene uitspraak die hier wordt gedaan: “Het vervelende is alleen dat de meeste moderne bestandssystemen dit soort fouten niet kunnen detecteren.”
Maar ik weet niet of ik hier de juiste interpretatie aan kan hangen. Welke bestandssystemen hebben we het hier over? NTFS? Reiser? EXT4? DOS? HPFS? Voor zover ik weet houden dit soort (ik weet niet of dit voor alle geldt) een CRC bij en kan aan de hand hiervan in elk geval foutieve sectoren worden opgespoord.
Hebben we het hier over NAS en SAN systemen? Dan moeten we ons richten tot de technische handleidingen en de parameters waarmee we deze aparaten kunnen inrichten, maar vaak genoeg zijn die met een bepaalde RAID versie redelijk rot-dicht te krijgen.
Het vervolg van het verhaal doet mij echter vermoeden dat de auteur het over geen van beide heeft, maar over de Windows systemen. Vooral de opmerking dat het bestandssysteem “als het register” een probleem kan hebben. Ik spreek niet tegen dat de windows-register een bron van grote ergenis en problemen is, maar we hebben hier niet te maken met een bestandssysteem, maar over een applicatie.
Ja, een gebrekkig moederbord kan problemen geven, maar hoe detecteer je zulke problemen? Je zult toch het moederbord zelf moeten gebruiken om te testen of die juist werkt, en wellicht is juist het feit dat deze “niets aan de hand” meldt terwijl dit niet het geval is juist de makke. Kom er maar achter.
Updates/installs/removals van applicaties. Tja, dat het onderliggende bestandssysteem (NTFS, DOS, etc.) besluiten om sectoren aan te merken als “leeg” in plaats van ze echt leeg te halen is een bewust besluit geweest: dit is een stuk sneller dan alle bits daadwerkelijk op ‘0’ te zetten. Daar zijn ook weer andere tooltjes voor te krijgen om dit daadwerkelijk te doen. Ook het regelmatig draaien van een diskscan (e2fsck, en wat heeft Microsoft hier ook weer voor gemaakt) helpt bij het betroubaar mogelijk maken van je bestandsysteem.
De oplossing die wordt aangedragen is ook maar een pleister op de wonde: als er meerdere petabytes moet worden gebacked-up, hoe wordt dat georganiseerd? Hoe zorg je ervoor dat de gegevens zo up-to-date mogelijk zijn ook NA een ‘disaster-recovery’? Hoe verifieer je dat de kopie die je gemaakt heb inderdaad gelijk is aan het orgineel (terwijl ondertussen de bron-database in gebruik moet blijven)? Hoe garandeer je dat de doel-database (filesysteem… wat je ook gebruikt) niet last heeft van bit-rot?
Dat laatste is een heel interessant en ongelofelijk ingewikkeld gebied, en verdient meer aandacht in de media. Maar dit stuk is iets te oppervlakkig en ambigu om een hele discussie op te baseren.
Ik prijs de auteur dat hij niet dit artikel gebruikt om zijn bedrijf te verkopen.
Wat mij opvalt, is dat dit artikel in een trend lijkt te passen die de laatste tijd in meer artikelen op Computable naar voren komt: de feilbaarheid van informatiesystemen en toepassingen, de risico’s die daar uit voortvloeien en vooral: wat de gevolgen kunnen zijn en wat we daaraan zouden moeten doen. Dit laatste kan een risico zijn voor de objectiviteit van de artikelen, als je begrijpt wat ik bedoel. Naarmate we langer gebruik maken van automatisering, de techniek zich verder ontwikkelt en er steeds meer toepassingen mogelijk zijn, lijken we ook meer risico’s te signaleren. Als dat een evenredige toename is staat de ontwikkeling feitelijk stil en in dat geval lijkt me dat geen gunstige ontwikkeling. Is dit onevenredig, in positieve zin, dan valt het met die risico’s eigenlijk wel mee en zijn de in het artikel genoemde maatregelen normaal gesproken afdoende. Het lijkt me zinvol grip te willen krijgen op dat gegeven, maar we moeten er voor waken ICT paranoia voor doemscenario’s te kweken.
Een beetje vreemde column, in ieder geval in deze tijd. ‘Vroeger’ hadden PC’s enkel parity-bits, en zou je in theorie een dubbele fout van je RAM hebben gemist. Moderne machines, en zeker servers, hebben ECC-geheugen wat enkele of dubbele fouten corrigeert, en complexere fouten detecteert. Harddisks hebben uitgebreide ECC checks op data, en kunnen vrijwel altijd data herstellen, en ook weer minimaal beschadiging op het moment van lezen vaststellen. RAID legt daar een eigen foutdetecterende en -corrigerende laag bovenop. Ook Filesystems gebruiken soms eigen checks bovenop ruwe disks of RAID. Extreme voorbeelden zijn ZFS en btrfs, wat hardware en RAID niet gelooft en alles na het schrijven terugleest en controleert op CRC.
25 jaar geleden, in de begindagen van de PC, was dit misschien een punt van zorg, maar een hedendaagse systeembeheerder heeft meer dan genoeg mogelijkheiden om dataintegriteit te kunnen controleren en garanderen.
Ik heb het zelf in de praktijk meegemaakt. Helaas. Een kostbaar bestand (want veel aan gewerkt) was kapot. De backup die bij mij tot 6 maanden teruggaat bood geen oplossing, in alle backups zat de “bit-rot”. Ik had het bestand meer dan zes maanden niet geopend.
Een RAID systeem is geen optie voor bit-rot. In een RAID systeem worden de checksums alleen gebruikt voor het herstellen van de gegevens, niet voor het verifiëren van de juistheid tijdens het lezen. Dit zou namelijk een performance killer zijn.
Voor zover ik weet heeft alleen ZFS end-to-end checksumming. Hmm, misschien een idee om een OpenSolaris fileserver op te zetten met ZFS.
Google heeft in samenwerking met anderen interessant onderzoek gedaan: “Failure Trends in a Large Disk Drive Population” en “DRAM Errors in the Wild: A Large-Scale Field Study”. Beide studies geven verrassende resultaten.
Gelukkig zijn storage engineers ongeveer de meest paranoïde mensen op deze wereld.
Daarom hebben moderne storage systemen een veelvoud van beschermingen hier tegen. Onder andere end-to-end CRC checks om dit te detecteren, RAID om disk defecten op te vangen, doen aan disk scrubbing om slechte disken op tijd te herkennen. De disken zelf hebben CRC checks op de sectoren. Ook moderne bestandssystemen detecteren dit soort fouten.
Natuurlijk als je bestandje maar op één plaats staat en je krijgt een melding dat het bestand corrupt is dan heb je een probleem. Maar daarvoor heb je natuurlijk braaf je back-up gemaakt, toch?
Inderdaad Orion6, alleen ZFS heeft zulke bescherming. Solaris is het beste, OpenSolaris een goede tweede, maar FreeBSD kan ook. Dat laatste is misschien wel erg aantrekkelijk.
Onlangs heeft BTRFS een filecheck optie gekregen en begint daarmee ook volwassen te worden. Echter, ZFS is op dit moment gewoon volwassener. Het fijne van BTRFS is wel dat het met Linux werkt: de kernel devs zijn verliefd op het nieuwe filesystem.
Verder is het het HAMMERFS van DragonFlyBSD, maar de status daarvan ken ik niet goed.
@Cpt: NTFS, Reiser, EXT4, DOS, HPFS, etc. hebben allemaal geen bescherming voor bitrot in data, of alleen in meta-data. En “DOS” is geen mij bekend filesystem (misschien bedoel je FAT).
Wat er in de meeste gevallen ontbreekt, is iemand die de kwaliteit van data controleerd.
De meeste problemen met betrekking tot data integriteit, ontstaan doordat gebruikers iets niet goed invullen, een backup niet goed wordt teruggezet of als een systeem tijdens het verwerken van data vastloopt of uitvalt.
In al deze gevallen is het belangrijk dat er iemand is, die de kwaliteit van data kan garanderen, door de data te controleren. Een voorbeeld kan zijn om invulvelden te beperken en om data te controleren tijdens ETL processen.
Soms is het ook de vraag of je bepaalde informatie moet vragen, als je op een webformulier voor het telefoonnummer een verplicht veld opneemt, is de kans groot dat er veel onbestaande telefoonnummers worden ingevoerd.
Kortom, wat de oorzaak ook is van non-integere data, er zal altijd iemand in het proces moeten zitten die de data op gezette momenten controleerd.
Nullen die verdwijnen in 1tjes is nog maar het puntje van de ijsberg. De weg die data aflegt in het storage netwerk moet end-to-end zijn. Een checksum error bij data mismatch is erg simpel – wat lastiger is: hoe te reparen. Hiervoor gebruikt ZFS een self validating merkle tree waardoor het dus niet alleen mogelijk wordt om het te detecteren maar ook om het te repareren. Als het gaat om bestand systemen dan hebben het dus over CPU, memory, IOHC, HBA’s, switches, back planes en vervolgens disken welke het meet onbetrouwbaar zijn.
Om dit te kunnen doen zijn ze helemaal afgestapt van de traditionele RAID systemen en is de hele notie van data integriteit volledig veranderd. Het file systeem is verantwoordelijk — end-to end. Geen applicaties die data checken, geen rare back-up check before restore maar het file systeem de verantwoording geven voor juistheid.
Daar stopt het natuurlijk niet, je data zal de loopduur van je disken ontegenzeggelijk overtreffen en is data migratie (replace van disken) van groot belang. Het asynchroon op schalen van read en write performance, replicatie van data het eenvoudig kunne groeien geen data scans, transparant herstellen van corruptie etc..etc
Voordat een file systeem op dit niveau kan werken (SAN/NAS) heeft het jaren van testen en voor zich. Gelet op de leeftijd van ZFS en en BTRFS (welke nog niet eens de helft van de features heeft als ZFS) duurt het zeker nog een jaar of 5 voordat het datacenter ready is. Ook als je kijkt naar de stabiliteit van ZFS in het BSD systeem zie je dat het nog veel kinderziektes platform keuze zou dus zijn een Illumos based systemen zoals of een commercieel bedrijf dat het exploiteert.