Bekijk Volledige Versie : I backup (not) therefore I am (not)
Graag meningen over onderstaand verhaal.
Groeten,
Een hostingtime klant.
Start mail quote:
Subject: Briefing server crash
Hostingtime
Beste,
Het is u niet ongaan dat de server waarop uw website is gehost in de afgelopen 3 weken structureel onbereikbaar was.
Wat gebeurde er nou precies?
De server viel uit het niets steeds uit en door de server opnieuw op te starten, was de server meestal binnen 15 min weer online. Uit de log bestanden van de server bleek dat de kernel van de server was gecrashed. Uit voorzorg hebben wij de kernel en gehele software systeem geupdate om uit te sluiten dat de huidige kernel versie een bug bevatte. Na deze werkzaamheden heeft de server 5 dagen goed gewerkt. Na onze 72 uur intensieve monitoring dachten wij het probleem te hebben opgelost, maar tevergeefs.
Hardware defect?
Hierna zijn we dieper gaan kijken en meteen uit voorzorg hardware onderdelen gaan vervangen. Zowel de moederboard als geheugen modules zijn van de server vervangen. Want ook deze kunnen de oorzaak zijn van een eventuele server crash. De server heeft hierna 3 dagen goed gefunctioneerd en de 4de dag viel de server weer uit.
Vanaf dat moment wisten we dat het goed mis was met de server en konden we met zekerheid uitsluiten dat het in iedergeval geen hardware of kernel versie oorzaak was.
Dus besloten we een gehele nieuwe server te plaatsen en alleen de harde schijven te verplaatsen, omdat er 3 hardeschijven in de server staan, 2 staan in raid5 (mocht 1 uitvallen dan blijft de ander functioneren) en de 3de is er voor de backups. Dit zou het probleem definitief opgelost moeten hebben, maar ook deze poging was tevergeefs. Zelfs nadat wij externe hp deskundige hadden ingehuurd om dieper in de materie te gaan kijken, bleef de server crashen, en met als gevolg volledig te zijn gecrashed.
Toen dit gebeurde, was 1 ding belangrijk: dat was de data die op de server stond (uw website) te waarborgen, zodat deze niet verloren kon gaan. In dit soort zeldzame situaties hebben wij er voor gekozen om altijd een extra hardeschijf te gebruiken voor alleen de backups. Deze hebben we dus kunnen gebruiken voor het herstel.
Wat hebben wij hierna moeten doen?
Hierna was duidelijk dat de data en besturingssysteem van de server volledig instabiel waren en alle data van de afgelopen 2 weken instabiel en corrupt was. Dus het herstellen van de backups op de zelfde server was niet mogelijk, omdat hiermee het besturingssyteem niet mee wordt hersteld. Ook omdat de server zo instabiel was geworden dat er geen garantie was dat de backups ook werkelijk goed terug gezet zouden worden, en dat de server weer crashed tijdens het terug zetten van de backups.
Dus hebben wij gekozen om een extra server in te zetten, en deze precies in te richten als de oude, maar dan met een schone cPanel en besturingsinstallatie en de backups van 2 weken geleden op deze server te verplaatsen en vanuit deze nieuwe server de backups pas te gaan herstellen. Omdat we dan zeker wisten dat het besturingssyteem en de hardeschijven geen fouten bevatten.
Deze hele operatie heeft veel tijd en inspanning vereist. Met als gevolg dat we ruim 3.5 dag down waren en met man en macht de server getracht zsm online te krijgen. Wij hebben veel support gekregen van onze klanten, die op deze server al ruim 3 jaar zonder al te veel problemen altijd goed geb ruik hebben gemaakt van onze diensten. Maar ook een aantal klanten die weinig goeds vonden aan onze aanpak en de manier hoe wij de zaken weer op de rails hebbengeprobeerd te krijgen. Uiteraad begrijpen wij dat de ellende zowel voor ons, maar ook vooral voor u onacceptabel was.
De afgelopen 3 maanden hebben we helaas te kampen gehad met 3 grote storingen:
1. Onze server rack en die van 20 andere collega bedrijven stond een gehele middag zonder stroom.
2. Half Nederland lag plat, omdat er in het Datacenter van Evoswitch/Leaseweb een storing was.
3. En de huidige server crash.
Storing 1 en 2 was helaas buiten onze toedoen en had geen gevolgen voor de servers die wij hebben.
Wij willen niks verbergen voor onze klanten en vandaar de openheid, naar u toe. Wij hebben ruim 125 servers in beheer en hosten op dit moment ruim 10.000 domeinen en hebben ooit in het verleden een soort gelijke server crash mee gemaakt, maar nog nooit op zo’n wijze dat het zoveel tijd heeft gekost, het proces zoals hierboven beschreven heeft veel tijd gekost ipv de handdoek in de ring te gooien, hebben we doorgezet en alles zsm online weer te krijgen, omdat uw continuteit van ons afhangt en u als klant onze primaire continuteit bent. Op dit moment zijn we druk bezig om de verloren data van de afgelopen 2 weken alsnog te herstellen. Omdat de server en alle andere systemen op deze server zo instabiel zijn, kost dit veel tijd om hier bij te komen. Wij hopen morgen de server weer te kunnen gebruiken voor het herstel proces en aankomende weekend beginnen met het restoren van de meest recente versie. Als u dus subdomeinen of accounts in uw reseller pakket hebt aangemaakt in de afgelopen 2 weken, dan zullen deze niet zichtbaar zijn.
Als u vragen heeft of wilt reageren op deze mail, aarzel geen moment en stuur ons een email.
Hopend op uw begrip en toevertrouwen.
HOSTINGTIME CREW
Einde mail quote
Hier hoor je je klanten dus niet mee op te zadelen. Het verhaal mist zijn doel ook nogal.
Ik denk dat (gedupeerde) klanten alleen nog maar minder vertrouwen krijgen na zo'n veel te uitgebreide e-mail.
Indien wij zulke storingen zouden hebben (welke we (nog) niet hebben gehad) dan zou ik alle tijd gaan besteden om het weer recht te zetten.
Met dit verhaal proberen ze dat ook enigsinds. Het lijkt alsof iemand minimaal 2 uur in dit verhaal gestoken heeft.
Ik zou alleen (dan nog niet zo uitgebreid) uitgebreid verslag doen wanneer een klant er om vraagt. Wat de klant 100% van de tijd wilt is dat de boel gewoon werkt. En dan maakt het opzich niet uit hoe of wat ;)
Raid 5 is minimaal 3 schijven.
Drie dagen voor van scratch disaster recovery te doen is veel te lang. Misschien een maand gratis vragen om te compenseren?
Tja wat moet je er op zeggen, het komt niet erg professioneel over maar daarom plaats je het denk ik ook. Een aantal dingen kloppen ook gewoon niet, zoals bijvoorbeeld RAID5 met 2 HD's, dat kan niet.
Vind het nogal een beetje té uitgelegd..
Snap ook niet wat je hoopt te bereiken met het vervangen van het "moederboard en geheugen" (moederbord merk je meestal wel, geheugen test je gewoon), en enkele zinnen voelen grammaticaal gezien stijf en/of fout aan.
De stijl van de tekst en dan de 3 korte puntjes voelen kwa taalgebruik ook niet echt hetzelfde aan en ik zou ze als klant ook niet graag lezen..
Hoop niet dat dat een mailing is naar alle klanten, maar alleen die specifieke?
Als je het mij vraagt, kun je uit dit verhaal voornamelijk opmaken dat er onvoldoende technische kennis in huis is om professioneel met dit soort situaties om te gaan (en ze te voorkomen).
Enerzijds is het wellicht goed dat ze door middel van de deze lange mail inzet proberen te tonen, maar als klant zijnde zul je denk ik toch liever te maken hebben met iemand met meer kennis en ervaring. Met inzet alleen kom je niet zo ver.
Wat ik als klant zou willen lezen is:
1. Wat was de oorzaak
2. Waarom heeft het zo lang geduurd
3. Hoe denkt men dit in het vervolg op te lossen
Vooral punt 3 zou ik van belang vinden, er zit een heel verhaal achter natuurlijk maar daar heb je als klant niks aan. Als die server er voor een 2e of 3e keer uitklapt in zeer korte tijd dan hang je een andere server weg en gaat met de "oude" server lekker achter de testbank zitten om te kijken of deze nog op te lappen is.
En waarom worden ook overige "grote" storingen vermeld? Zijn die relevant aan deze storing? Nee, dus geen reden om te vermelden.
Je zou om een compensatie kunnen vragen, er word gesproken over "3 weken structureel onbereikbaar" om hoeveel tijd gaat dit? Heb je een uptime garantie?
Wat ik als klant zou willen lezen is:
1. Wat was de oorzaak
2. Waarom heeft het zo lang geduurd
3. Hoe denkt men dit in het vervolg op te lossen
Dat zijn inderdaad altijd de kernpunten. Maar als je tussen de regeltjes door leest, kun je het er wel uit opmaken.
Punt 1:
Onze server rack en die van 20 andere collega bedrijven stond een gehele middag zonder stroom.
De server viel uit het niets steeds uit en door de server opnieuw op te starten, was de server meestal binnen 15 min weer online
M.a.w. waarschijnlijk is het filesysteem corrupt geraakt, is er vervolgens geen adequate actie ondernomen en is het van kwaad tot erger gegaan. Als je telkens power off/on blijft doen, vraag je natuurlijk om dit soort problemen.
Punt 2:
Gebrek aan technische kennis kun je uit het verhaal wel opmaken. Het feit dat een server klakkeloos gereboot wordt en dat er vervolgens gehoopt wordt dat het probleem zich niet meer voor zal doen, spreekt wat dat betreft boekdelen.
Punt 3:
Dit is inderdaad het belangrijkste punt en is in het verhaal compleet afwezig.
En waarom worden ook overige "grote" storingen vermeld? Zijn die relevant aan deze storing? Nee, dus geen reden om te vermelden.
Het lijkt me dat dit voornamelijk genoemd wordt als een stukje erkenning, hetgeen op zich wel te waarderen valt. Daarnaast is het zeer goed mogelijk dat die stroomuitval hier weldegelijk direct aan is gerelateerd.
Het lijkt me dat dit voornamelijk genoemd wordt als een stukje erkenning, hetgeen op zich wel te waarderen valt. Daarnaast is het zeer goed mogelijk dat die stroomuitval hier weldegelijk direct aan is gerelateerd.
Hoe dat is met die server die zonder stroom zaten weet ik niet, echter die 2e storing bij EVO was een storing op de core router waardoor het netwerk plat lag en was niet relevant aan een stroom issue dus er is toen verder ook niks met die server gebeurd lijkt mij.
Verder schrijft men in het bericht toch ook:
Storing 1 en 2 was helaas buiten onze toedoen en had geen gevolgen voor de servers die wij hebben
Dus het klinkt mij dan in de orden als een op zichzelf staand probleem. Echter door gebrek aan (technische) kennis is men te laat met een degelijke oplossing gekomen.
Gewoon een gebrek aan ervaring, maar uit de mail maak ik wel op dat deze mannen hart hebben voor hun zaak. RAID 5 met twee disks is inderdaad onzin, maar ik geloof ook niet dat ze op eigen hardware draaien. Waarschijnlijk hebben ze een dedi gehuurd (Alfanet BVBA?) en werden ze door hun leverancier van kast/muur gestuurd.
Een startende hoster die vertrouwde op de expertise van zijn leverancier en zelf lekker met cPanel aan de gang dacht te zijn. Toen puntje bij paaltje kwam barstte de bubble. Wel weer jammer van de '10.000 domeinen en 125 servers'.
Wel weer jammer van de '10.000 domeinen en 125 servers'.
Ik ken er meer met last van grootheidswaanzin hoor :-)
Wat ik als klant zou willen lezen is:
1. Wat was de oorzaak
2. Waarom heeft het zo lang geduurd
3. Hoe denkt men dit in het vervolg op te lossen
Vooral punt 3 zou ik van belang vinden, er zit een heel verhaal achter natuurlijk maar daar heb je als klant niks aan. Als die server er voor een 2e of 3e keer uitklapt in zeer korte tijd dan hang je een andere server weg en gaat met de "oude" server lekker achter de testbank zitten om te kijken of deze nog op te lappen is.
En waarom worden ook overige "grote" storingen vermeld? Zijn die relevant aan deze storing? Nee, dus geen reden om te vermelden.
Je zou om een compensatie kunnen vragen, er word gesproken over "3 weken structureel onbereikbaar" om hoeveel tijd gaat dit? Heb je een uptime garantie?
Wat moeten klanten die van toeten noch blazen weten en slechts hun persoonlijke site over carnavaltoeters online willen hebben met technische info over bijvoorbeeld een zero day kernel exploit? Wat ook de oorzaak is geweest dit krijg je aan een leek nooit uitgelegd als je op de technische toer gaat. Voor deze mensen is eigenlijk geen enkele uitleg voldoende anders dan de gebruikelijke geruststelling en marketingpraat.
Maar misschien dat je op het bestelformulier kunt aangeven of je een beginneling of pro bent en afhankelijk van deze keuze een "komt goed schatje" of een "kernel race condition exploit oplossing uitgelegd" mailtje krijgt. Ideetje misschien? ;)
T. Verhaeg
01/10/10, 14:14
Haha die vind ik wel heel goed moet ik zeggen. Maar, men is dus afhangend van een 2 weken oude backup? Zijn er dan geen backup controles?
Dit lijkt me eerder een gevalletje van 'we hebben geen recente backups en proberen dit te verbloemen met een hoop technische bla bla'? Als een server 5 dagen zonder problemen kan draaien, dan ga ik er van uit dat er met de consistentie van het merendeel van de gegevens geen probleem is. In een beslissing om geen volledige server restore te doen inclusief OS kan ik nog inkomen, maar de user data dan gelijk ook maar even 2 weken terugdraaien...
T. Verhaeg
01/10/10, 14:31
Had juist meteen tijdens het "stabiel draaien" een backup weggeschreven en deze proactief in proberen te laden op een andere machine. 2 weken is wel erg veel, dus als er MKB'ers zitten zijn die bijvoorbeeld 2 weken mail kwijt?
Beetje vreemd. Zit er enige vorm van compensatie aan?
In een mail van 21-9-2010 is gesproken over financiele compensatie. Daarna niet meer.
De eerste mail quote in het begin van de thread is trouwens van 1-10-2010.
Begin mail quote 21-9-2010:
Beste,
Na een week monitoring en een weekend intensieve hardware check, bleek de server het na vrijdag weer te doen. Vandaag is de server helaas weer down gegaan. Dit heeft ons doen besluiten de server morgen meteen te gaan vervangen.
Waarom hebben wij dit niet eerder gedaan?
De reden van deze vertraging heeft te gemaken gehad met de data op de schijfen, deze konden niet 1 op 1 worden overgezet op een nieuwe server, omdat op advies van een HP consultant de risico te groot was voor data verlies. Wij hebben als oplossing een identieke server configuratie gecreeerd waar we de schijven 1 op 1 kunnen overzetten, zodat de data bewaard en veilig zal worden overgezet. De nieuwe server is een dual Xeon enterprise server die qua performance vele male sneller is dan de huidige.
De server is momenteel een schijfcheck aan het doen en we hopen deze zsm online te krijgen.
Onze excuses voor het ongemak.
Er volgt een financiele compensatie voor het overlast. Hierover deze week meer.
Met vriendelijke groet,
HOSTINGTIME
systemdeveloper
01/10/10, 14:43
Had juist meteen tijdens het "stabiel draaien" een backup weggeschreven en deze proactief in proberen te laden op een andere machine. 2 weken is wel erg veel, dus als er MKB'ers zitten zijn die bijvoorbeeld 2 weken mail kwijt?
Beetje vreemd. Zit er enige vorm van compensatie aan?
2 weken mail... balen... 2 weken orders en opdrachten... heel erg balen ;)
Niet weten of je mensen al automatisch gefactureerd hebt of niet... bleh...
Maar niet checken of je backups werken (of remote staan) bij de eerste de beste hik van je server... priceless :)
Backups onderbrengen bij een andere partij is volgens mij toch het beste advies.
Controle data integriteit lijkt me echter wel lastig. Hoe kan je nu weten of er geen corrupte data tussen zit?
Backups onderbrengen bij een andere partij is volgens mij toch het beste advies.
Controle data integriteit lijkt me echter wel lastig. Hoe kan je nu weten of er geen corrupte data tussen zit?
Door, zoals in ieder basishandboek aangegeven, minstens eenmaal per maand een test restore te doen?
systemdeveloper
01/10/10, 15:29
Backups onderbrengen bij een andere partij is volgens mij toch het beste advies.
Controle data integriteit lijkt me echter wel lastig. Hoe kan je nu weten of er geen corrupte data tussen zit?
Uh, checken of de data goed weggeschreven wordt, checksums controleren om dingen zoals bitrot te detecteren, smartgegevens van de schijven checken, mysqldumps doen ipv. binaire tabellen kopieeren. (Een dump gaat bij de eerste tekenen van corruptie al snel op zijn gat namelijk).
Maar belangrijkste is om het op een andere machine te gooien. Een backup disk is leuk, maar als je controller onzin gaat spuien, dan ben je toch blij als daar niet je backupdisk aan hangt.
ysqldumps doen ipv. binaire tabellen kopieeren. (Een dump gaat bij de eerste tekenen van corruptie al snel op zijn gat namelijk).
Yep dump.
Door, zoals in ieder basishandboek aangegeven, minstens eenmaal per maand een test restore te doen?
Yep.
Daar zit mijn probleem. 40 GB data restoren, ruim 400 databases.
Hoor graag de ervaringen van anderen dat ze dat in 4 uur kunnen.
Ben zeer benieuwd hoe en met welke hardware :-)
Edit:
of is replicatie (naar een ander DC) de enige oplossing voor dit probleem?
Graag meningen over onderstaand verhaal.
[...]
omdat er 3 hardeschijven in de server staan, 2 staan in raid5
[...]
:lovewht:
Enough said, zoek jezelf een hoster die wel tenminste basiskennis heeft van hardware.
Dank voor jullie reakties. Ik vond het (als leek) allemaal nogal knullig overkomen. Mijn gevoel klopte dus. Backup is regel 1. Ook voor mij. Gelukkig heb ik niet veel verloren. Ik kan dus verder gaan kijken voor een host.
Daar zit mijn probleem. 40 GB data restoren, ruim 400 databases.
Hoor graag de ervaringen van anderen dat ze dat in 4 uur kunnen.
Ben zeer benieuwd hoe en met welke hardware :-)
Als ik het goed lees staat er dat er gedurende de restore een downtime was van meer dan een dag. Zelf heb ik wel restores (maar dan met verhuizing van ene server na andere server waarbij beide servers gewoon werkten zonder problemen) gedaan die in minder dan 8 uur tijd meer dan 40GB aan data moesten restoren. Dat was overigens op een omgeving VPS met 15k RPM schijven in RAID50 eronder als storage omgeving (naast de 4 CPU cores en 4GB RAM binnen de VPS).
Edit:
of is replicatie (naar een ander DC) de enige oplossing voor dit probleem?
Zelf maken we backups naar een andere server in hetzelfde rack. Met enige regelmaat kopieren we die naar een andere server om ze als test te restoren, dit heeft dan echter geen haast en zet ik aan en kijk ik pas weer naar als hij klaar is om eerlijk te zijn. Replicatie is in bepaalde gevallen een goede optie, maar niet altijd. Het blijft een lastig iets (enkel replicatie zou ik niet adviseren als "backup").
Het enige dat mij echt opvalt in het verhaal is dat ze ruim 3 dagen nodig hebben om een backup te restoren (nu weet ik niet hoe groot de backup in totaal was). Persoonlijk vraag ik me wel af wat hier de oorzaak van is (en waarom ze als het toch zolang duurde niet ook een backup maakten van de "oude" server en die ergens gingen restoren om zo email/orders/facturen/etc. te redden).
Na het gelezen te hebben, dan is het fout, ronduit fout. En dat wijt ik aan het tekort aan kennis, en misschien beperkte budgetten die spare-materiaal niet toelaten (wat meestal een tekort aan financiële planning aanduidt).
Al dat terzijde moet ik wel zeggen dat ik de passie voel die soms ontbreekt bij beginnenden. De hoster blijft ervoor gaan, steekt zich niet weg (probeert het wel wat teveel te verbloemen), blijft eraan werken, en geeft uitleg aan de klant. Het zit nog niet 100% snor, maar ik ken een heel deel kleinere hostertjes die er gewoon de brui aan zouden geven, geen mails uitsturen,...
Al bij al gaan ze nu klanten verliezen, en terecht, maar ik zit liever bij een partij die passie en wilskracht heeft om door te gaan, en durft toegeven aan de klanten dat het niet optimaal is, dan iemand die zich verbergt of er gewoon mee ophoudt. Ik kan fout zijn, maar in heel dit fiasco zit misschien tussen de regels toch nog iets goed...
Al dat terzijde moet ik wel zeggen dat ik de passie voel die soms ontbreekt bij beginnenden. De hoster blijft ervoor gaan, steekt zich niet weg (probeert het wel wat teveel te verbloemen), blijft eraan werken, en geeft uitleg aan de klant. Het zit nog niet 100% snor, maar ik ken een heel deel kleinere hostertjes die er gewoon de brui aan zouden geven, geen mails uitsturen,...
Ja hier ben ik het helemaal mee eens, maar dan moet hij niet zo overdrijven met 125 servers bla bla bla...
Al bij al gaan ze nu klanten verliezen, en terecht, maar ik zit liever bij een partij die passie en wilskracht heeft om door te gaan, en durft toegeven aan de klanten dat het niet optimaal is, dan iemand die zich verbergt of er gewoon mee ophoudt. Ik kan fout zijn, maar in heel dit fiasco zit misschien tussen de regels toch nog iets goed...
Uiteindelijk is de email in zijn geheel ook goed bedoeld. Hij mis alleen zijn doel. Goed hij is nu even flink op zijn bek gegaan, zal hier behoorlijk wat van leren (hopen we) en de volgende keer zal het anders verlopen.
Eerder in dit topic zei iemand dat hij wellicht gewoon een dedicated ergens huurde en dus afhankelijk was van die partij, als dat zo is zou ik hem adviseren dit toch anders aan te pakken. En mocht hij geen kennis hebben van hoe je dat moet aanpakken dan mag íe altijd contact opnemen. Want ik vind dat zijn doorzettingsvermogen en inzet best gestimuleerd mogen worden en dat hij best bij een collega iets kan bijleren.
Al dat terzijde moet ik wel zeggen dat ik de passie voel die soms ontbreekt bij beginnenden. De hoster blijft ervoor gaan, steekt zich niet weg (probeert het wel wat teveel te verbloemen), blijft eraan werken, en geeft uitleg aan de klant. Het zit nog niet 100% snor, maar ik ken een heel deel kleinere hostertjes die er gewoon de brui aan zouden geven, geen mails uitsturen,...
Ik persoonlijk zit met een brok in mijn maag als een klant meld dat een dedi niet degelijk functioneerd. Zelfs als ik gecontateerd heb dat het overmacht is (broken disk) of dat hij/zij zelf iets fout gedaan heeft vind ik het gewoon niet plezierig.
Je leverd een product wat dan niet functioneerd, ook al is het door toedoen van de huurder zelf, dan is het toch niet fijn. Thans zo zie ik het, weet niet of andere deze mening delen.
systemdeveloper
03/10/10, 22:43
Ik persoonlijk zit met een brok in mijn maag als een klant meld dat een dedi niet degelijk functioneerd. Zelfs als ik gecontateerd heb dat het overmacht is (broken disk) of dat hij/zij zelf iets fout gedaan heeft vind ik het gewoon niet plezierig.
Je leverd een product wat dan niet functioneerd, ook al is het door toedan van de huurder zelf, dan is het toch niet fijn. Thans zo zie ik het, weet niet of andere deze mening delen.
Ik weet precies hoe dat voelt.
Dit gevoel ken ik ook maar jammer genoeg ken ik ook bedrijven die daar helemaal niet mee zitten. Desinteresse denk ik dan maar.
In dit geval is het echt een kwestie van een slecht calamiteiten plan en een nono die deze mailing opgesteld heeft.
En tenslotte: de MySQL databases zijn corrupt. Herstel gaat weken duren. 3 maanden financiele compensatie.
Groeten.
systemdeveloper
05/10/10, 20:13
En tenslotte: de MySQL databases zijn corrupt. Herstel gaat weken duren. 3 maanden financiele compensatie.
Groeten.
Gaan ze het overtypen?
hehe. quote: "wij hebben een extern bedrijf ingehuurd die gespecialiseerd is in data recovery ingehuurd, om te proberen de mysql data te herstellen, maar dit kan weken duren."
'k Heb al half opgefikte schijven opgestuurd en 4 werkdagen later de data teruggekregen, welk datarecoverybedrijf heeft er weken voor nodig? Of hebben ze de disk met TNT verzonden?
systemdeveloper
05/10/10, 20:32
Dacht dat ze dat bij ontrack binnen 24 uur doen. (En de economy optie binnen 6 dagen).
systemdeveloper
05/10/10, 20:35
'k Heb al half opgefikte schijven opgestuurd en 4 werkdagen later de data teruggekregen, welk datarecoverybedrijf heeft er weken voor nodig? Of hebben ze de disk met TNT verzonden?
Met DHL... dan sturen ze hem ook eerst 6 keer terug :P
Alsof ze geld hebben voor datarecovery.
Als je 10.000 domeinen en 125 servers beheert dan hoor je ook een aantal spare servers te hebben staan die (semi) automatisch de boel overnemen als een webservertje eigenwijs doet. Jammer dat het zolang heeft geduurd, compensatie van ongeveer een maand lijkt mij wel gepast hierbij.
systemdeveloper
06/10/10, 14:37
Als je 10.000 domeinen en 125 servers beheert dan hoor je ook een aantal spare servers te hebben staan die (semi) automatisch de boel overnemen als een webservertje eigenwijs doet. Jammer dat het zolang heeft geduurd, compensatie van ongeveer een maand lijkt mij wel gepast hierbij.
Knap als je tot 125 servers kunt groeien op zo'n manier...
PimEffting
07/10/10, 08:59
Volgens mij probeert hij wel zijn best te doen, maar weet hij niet zo goed hoe. Dat is op zich niet erg - we hebben het allemaal moeten leren. Ook de problemen die hij beschrijft klinken erg complex in de oren. Soms kom je wel eens een foutmelding tegen, ga je op google, en lijkt het alsof je de enige bent met dat probleem. Het oplossen kan dan heel frustrerend zijn en soms weken duren. Vaak is het beter om gewoon opnieuw te beginnen (schone server, data migreren -dus niets overschroeven-). Dat levert dan een paar uurtjes overlast op maar slaap je daarna weer rustig.
Dadarecovery kan echt wel heel tijdrovend zijn als je een volledige recovery moet doen. Soms doet een programma er wel een dag of meer over om een harde schijf in kaart te brengen (scannen). Dan is de recovery nog niet eens geweest.
Mijn ervaring met Linux bestandsystemen is dat het terughalen van bestanden zeer lastig gaat.
Gewoon een gebrek aan ervaring, maar uit de mail maak ik wel op dat deze mannen hart hebben voor hun zaak. RAID 5 met twee disks is inderdaad onzin, maar ik geloof ook niet dat ze op eigen hardware draaien. Waarschijnlijk hebben ze een dedi gehuurd (Alfanet BVBA?) en werden ze door hun leverancier van kast/muur gestuurd.
Waar haal je dat uit ?
T. Verhaeg
07/10/10, 21:02
Waar haal je dat uit ?
Vind ik inderdaad nogal een aanname..
Er is iets veranderd aan de setup sinds de openingspost, maar als ik me dat goed herinner verwees de PTR naar *.alfaservers.com. Alfaservers valt onder de genoemde BVBA, die weer op een ander adres is ingeschreven dan de mannen van Hostingtime. Genoemde Alfaservers doen weer in dedicated servers, dus zodoende.
Er is iets veranderd aan de setup sinds de openingspost, maar als ik me dat goed herinner verwees de PTR naar *.alfaservers.com. Alfaservers valt onder de genoemde BVBA, die weer op een ander adres is ingeschreven dan de mannen van Hostingtime. Genoemde Alfaservers doen weer in dedicated servers, dus zodoende.
Ok, vandaar .. ik snapte niet goed waar je het haalde (er is dus iets gewijzigd). Maar je verdere aanname klopt dan ook volledig :)