Gepubliceerd: Dinsdag 6 januari 2009
Een ontslagen ict-medewerker heeft blogplatform Journalspace.com 'vernietigd'. Alle data is weg, het platform uit de lucht en de boedel zelfs te koop gezet.
Toon volledig artikel
De bedoeling was dat bij het falen van de ene schijf, de gegevens opgeslagen bleven op de andere schijf. Vergeten werd dat als gegevens die tegelijkertijd op beide schijven vakkundig worden overschreven, de data niet meer terug te halen is.
Vakkundig? Wordt allemaal geregeld door de raidcontroller. Als je het spul overschrijft is het gewoon weg.
Wat een knuppels om geen backups te maken, zeg.
"Ex-beheerder draait blogbedrijf de nek om"
Is het al zeker dan dat de ex-beheerder het gedaan heeft? Volgens mij gissen ze een beetje. En toevallige enkele maanden ervoor was er iemand ontslagen.... Enkele maanden? Toevalliger was geweest als die kerel gisteren ontslagen was en dat vandaag het gebeuren crasht.
Een fatale crash kan nog steeds de oorzaak zijn. Ik heb twee maal meegemaakt dat van een 12-disk RAID5 stripe set respectievelijk 3 en 4 schijven tegelijk onderuit gingen. De eerste keer omdat het disks uit dezelfde serie waren (productiefoutje) en de tweede keer door een stroompiek. Weg data.
De beste redundantie heb je door op twee fysiek gescheiden lokaties een RAID server neer te zetten en deze te synchroniseren. Dan kun je zelfs bij stroomuitval, of een netwerkstoring nog live blijven.
Het wissen van bestanden blijft bij zo'n opzet onomkeerbaar omdat een file die op 1 server wordt gewist, ook op de andere server wordt verwijderd. Om dat te voorkomen kun je ook nog eens periodiek offline backups draaien.
Uitvallen van meerdere schijven tegelijk? Stroompieken? Misschien toch eens overwegen om fatsoenlijke servers te kopen, en wat dacht je van een UPS om de stroompieken op te vangen en je systeem fatsoenlijk te laten afsluiten bij langere stroomuitval. En periodiek offline backups maken? Elke dag een backup maken ongeacht wat voor redundantie lijkt me niet meer dan normaal. Zo te lezen is er bij jullie ook nog een hoop te verbeteren. ;-)
Pardon? kan je nog bottere, ongefundeerde opmerkingen plaatsen? Meerdere schrijven kunnen weldegelijk crashen. Hoewel ik het zelf nog nooit heb meegemaakt heb ik meerdere IBM engineers gesproken over situaties waar dit voorkwam.
Een voorbeeld betrof een AS400 met Raid5 die al 10 jaar ( vrijwel onafgebroken ) draaide maar die voor onderhoud uit de lucht moest. Na opstarten bleken 5 van 10 schrijven niet meer op te komen. Het betrof toch een van de duurste en meest stabiele systemen die er te vinden waren in die tijd. Goed 10 jaar voor harddisken is natuurlijk wat veel, maar in elk geval hoeft het dus niet aan de kwaliteit van het materiaal te liggen, er kunnen meerdere oorzaken te vinden zijn.
In elk geval Dien je als zelf respecterend bedrijf altijd een fatsoenlijke backup te hebben, of dit nu is door clustering, tapes of andere methodes is verder weinig relevant. Alleen schrijf redundantie als backup beschouwen is natuurlijk van den zotte.
Het is geen botte opmerking, het is een kwestie van goed netwerkbeheer, iets wat veel bedrijven nog niet snappen. Elk systeem ongeacht prijs of merk heeft grote kans om niet meer op te komen na 10 jaar dienst, en dat is normaal. Als je als IBM engineer een systeem van 10 jaar oud uit zet, en dan nog de illusie hebt dat het wel weer gaat werken getuigd ook niet echt van uitblinken, ik zou ze niet durven uitzetten zonder een recente backup in elk geval. En als je meent dat mijn opmerkingEN ongefundeerd zijn, kom dan eens met wat fatsoenlijke argumenten i.p.v. "ik heb gehoord dat.."
Stroompiek is lekentaal. Echte pieken komen nooit door de voeding heen! Hij bedoelt waarschijnlijk een dip. Het komt regelmatig voor dat harddisks die lange tijd hebben aangestaan niet meer opstarten als ze worden uitgezet. Een RAID met 12 schijven en 1 redundante schijf is dus niet zo slim want die is statistisch gezien kwetsbaarder dan een enkele harddisk. Ik zou zelf hooguit voor 4+1 gaan met een goede externe backupvoorziening.
De beste redundantie heb je door op twee fysiek gescheiden lokaties een RAID server neer te zetten en deze te synchroniseren. Dan kun je zelfs bij stroomuitval, of een netwerkstoring nog live blijven.
Neen, neen, neen, koekenbakker, dat is nog steeds geen goede backupoplossing! Op moment dat er kritische fouten in software of data ontstaan traverseren die fouten door naar alle gesyncte schijven en kun je nooit terug gaan naar een eerdere gezonde situatie.
Een paar maanden
dan hadden hebben ze tch tijd gehad om deze "feature" te ontdekken met een nieuwe beheerder? Volgens mij proberen ze gewoon de fout af te schuven op die ontslagen onkundige-beheerder.
Als er zo iets gebeurd binnen je bedrijf dan ga je toch als eerste alle security na lopen en verbeteren? en niet pas maanden later gaan miepen.
Dit is heel heel erg dom. De redenatie is dat het backupsysteem goed was omdat men van een RAID controller gebruik maakte. Maar backups maak je omdat er 'iets' fout kan gaan. Als eerste in het backupplan beschrijf je mogelijke fouten:
1) Disk Crash (Duh, logisch).
2) Je gooit iets weg wat niet de bedoeling was. (En daar gingen ze al de fout in. Simpel op te lossen door een automatisch kopie te maken naar een andere schijf over het netwerk. Er zal toch wel ee Freeware AppleScriptje ergens zijn dat dit voor je doet. Anders een Perl-scriptje (het is immers FreeBSD)
3) Kwade systeembeheerder. Kwestie van backuppen naar een locatie waar systeembeheer alleen maar write-access en geen delete-access toe heeft. Of, de eigenaar/directeur rukt effe die externe usb-disk uit de server voor dat ie naar huis gaat elke avond.
4) Brand, 747 die het pand binnenvliegt, etc : Zie oplossing bij 3.
Overigens, GMail accountje is gratis en heeft 1 Gb opslag. Als je er daar een aantal van aanvraagt en de SQL-dump daar elke dag effe naar toe mailt heb je al geen last.
Conclusie: Iedereen bij journalspace.com was zeer amateuristisch bezig, zowel ICT, als de eigenaren. Geen meelij mee dus.
Het hielp daarbij dat het bedrijf een bijzonder stuntelig backupsysteem er op nahield.
Backupsysteem? Er WAS helemaal geen backupsysteem! RAID beschermt je alleen als er een schijf kapot gaat. Niet als iemand moedwillig de boel overschrijft, want een RAID systeem voert dat commando genadeloos vrolijk uit. Een backup maakt je !in principe! altijd naar Tape. Als je bedrijf er vanaf hing (zoals het hier het geval was) en je kiest voor een cheapo-niet-weten-wat-een-backup-betekent systeem is het gewoon een kwestie van eigen schuld dikke bult.
Backup naar tape? Als je tegenwoordig al een usb-TB-disk koopt voor nog geen 100 euro?
Wij hebben op de zaak gewoon een 12tal TB disks gekocht, sticker van de dag erop (MA/DI/WO/etc) die zitten bij twee verschillende mensen in de PC's, backups worden tijdens de lunch naar die disks gedaan en als ze naar huis gaan nemen ze dat ding mee. Niks geen incrementals, gewoon full backups.
En wat is de levensduur van die USB disks? En wat kosten die disks in verhouding tot tapes? En ten slotte, is USB snel genoeg om al je data in een bepaalde tijd weg te schrijven?
Een goede back-up oplossing voldoet aan minimaal 2 criteria: snelle toegang tot verwijderde data en een veilige, langdurige opslagtermijn. Hoe je dat technisch inkleedt kan van organisatie tot organisatie verschillen (denk ook aan verschillen in wettelijke verplichtingen), het meest gangbaar is nu denk ik wel de disk-2-disk-2-tape. Er wordt eerst een back-up gemaakt naar een ander disksysteem, vaak meerdere keren per dag/uur. Daarna wordt er dagelijks een tape gemaakt (of zelfs meerdere tapes) vanaf het disksysteem die extern wordt opgeslagen.
Volgens mij is een USB disk snel genoeg. En vroeger heb ik wel eens met tapes gewerkt, toen nog de oude TK50's op VAX/VMS, maar die waren na een tijdje ook niet betrouwbaar meer. Als je naar prijs/prestatie kijkt is USB-disk 1 van de beste oplossingen. Tapdrives zijn belachelijk duur en tapes zelf ook.
Nou, probeer jij maar eens 1TB aan data tijdens de lunch van een medewerker naar een USB-disk te pompen. Ongeacht hoe lang die lunch duurt, daar heb jij langer voor nodig.
Zelfs als je het incrementeel doet en alleen gewijzigde bestanden overpompt, heb je na de backup-fase ook altijd nog de controleer-fase. Dus ALLE data teruglezen en de checksums controleren. Anders heb je een backup van nix. En laat het teruglezen van 1TB aan data bij de huidige generatie schijven toch al gauw een uur of 5 duren. Dan is USB niet eens de bottleneck, maar de fysieke eigenschappen van de schijf.
Tapes hebben ook niet het eeuwige leven. Na +/- 30 keer schrijven moet je een tape weggooien. Daarnaast is een USB schijf van 1TB waarschijnlijk veel goedkoper dan 1 tape van 1TB. Tape is een gepasseerd station.
Data langdurig opslaan is een lastig vraagstuk. Eigenlijk zijn alle media aan veroudering onderhevig waardoor je eigenlijk de backups regelmatig op een nieuw medium moet zetten. Probleem daarbij is dat het medium dan nog wel (uit)leesbaar moet zijn. Een oude tapedrive of IDE ATA interface van Ebay of Marktplaats moeten halen om de oude backups terug te halen lijkt me niet ideaal.
Naar mijn mening is het het verstandigste om alle data die je wilt bewaren on-line op harddisk te hebben en die domweg mee te nemen in een periodieke backup. Dan worden de gegevens vanzelf meegenomen als de hardware wordt vervangen en loop je nooit het risico dat gegevens verloren gaan doordat het medium defect of verouderd is.
Backup naar tape? Als je tegenwoordig al een usb-TB-disk koopt voor nog geen 100 euro?
Wij hebben op de zaak gewoon een 12tal TB disks gekocht, sticker van de dag erop (MA/DI/WO/etc) die zitten bij twee verschillende mensen in de PC's, backups worden tijdens de lunch naar die disks gedaan en als ze naar huis gaan nemen ze dat ding mee. Niks geen incrementals, gewoon full backups.
Als je rustig leest staat er "!in principe!" Als dit goed is voor jou bedrijf en je accepteert de risico's: Prima. Zo te horen werk je bij een klein bedrijf, want hoe denk je dit met USB-disken op te lossen als je b.v. 50TB/week moet back-uppen met een retentietijd van van 3 maanden? Dan zou je met jou methode c.a. 640 schijven nodig moeten hebben. Zie je het voor je? (Dat wordt wel een erg lange lunch ;-) ) Dus gebruiken de wat grotere bedrijven !in principe! tapes als back-up medium. Zeker om het tape management systeem wat er achter zit, want het lijkt me sterk dat je nog weet welke tape je 2 maanden geleden hebt gebruikt voor die en die server... ;-)
Hmmz lekker. Ik heb zelf een wordpress blog op een eigen server. Via de MySQL administrator tool heb ik een Scheduled Task aangemaakt die elke dag een SQL dump maakt op een externe Schijf. Enige fout die ik nu maak is dat ik de back-up schijf niet op een andere locatie heb steekt gewoon in de server. Lijkt me sterk dat een 747 in mijn huis vliegt. Hooguit brand *afkloppen*. Denk dat ik een 2e task ga toevoegen die de documenten kopieert naar een externe provider.
Jammer voor dit bedrijf maar dit is/was wel een erge ict omgeving...
Beetje off-topic, maar kijk hier eens naar:
http://wordpress.org/extend/plugins/wp-db-backup/
Kwestie van een gmail account aanmaken en deze plugin iedere dag je database daarheen laten mailen en je bent veilig (wat je database betreft - je uploads e.d. moet je zelf nog op de een of andere manier backuppen)
Je bedrijfsgegevens zo naar gmail sturen? Dat lijkt me niet verstandig :-(
Beter is de boel dagelijks wegschrijven naar tape en de tape meenemen c.q. op een andere locatie bewaren. Hier bestaan prachtige backup strategien voor, maar zo te zien is het IT beheer een onderschoven kindje bij dit bedrijf (zoals ik bij meerdere bedrijven heb gezien). Mag niks kosten en als het dan fout gaat.... dan gaat het goed fout.
Ralph
Het systeem draaide op OS X Server, wat het zeer onwaarschijnlijk maakt dat een dergelijke crash zich kan voordoen
Wie verlicht mij?
FreeBSD, Unix varianten en wat propietary systemen als OS400 en OS390 staan in de markt bekent om hun robuustheid.
OS X server is op FreeBSD gebaseerd en dat staat bekent als een betrouwbaar OS. Of dat de OS X implementatie van FreeBSD echt net zo betrouwbaar is als FreeBSD weet ik niet, wat heeft Apple er tenslotte nog meer mee gedaan?
Verder, MS Server is ook betrouwbaar (MS garandeert dat echt, zolang je er maar geen applicaties op gaat draaien). Een crash kan ook vanuit een applicatie komen, dit hoeft niet uit het OS afkomstig te zijn.
OS X server is op FreeBSD gebaseerd
Bijna goed. Apple gebruikt een BSD gebaseerd systeem met een Mach kernel. Voor de historie en zo:
http://developer.apple.com/darwin/history.html
Op MacOS X 10.5.6
$ uname -a
Darwin MBP.local 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386
Om te kunnen reageren, dient u ingelogd te zijn.
2 jaar geleden: 13 februari 2010
3 jaar geleden: 13 februari 2009
4 jaar geleden: 13 februari 2008
5 jaar geleden: 13 februari 2007
14 jaar geleden: 13 februari 1998
IDG Nederland is uitgever van: AppFish
, CIO, Computer!Totaal, Computerworld, ITworld, Jobworld, MacWorld, RAW fotomagazine, TechFish, Tips & Trucs, Webwereld en Zoom.nlMeer informatie: IDG Nederland, IDG.com, Privacy-statement, Cookie-statement Hosting by Terremark.
