Som jeg nevnte i en post som selvfølgelig ble borte når vi gjenopprettet en nyere backup, så beror hele denne saken på mennesklig feil og der må desverre jeg ta på meg det hele og fulle ansvar. Det var jeg som var på vakt og det var jeg som jobbet med denne saken hele tiden.
For å ta hele historien, for de som er interessert;
Tidlig søndag formiddag begynte en sikkerhetsmodul (mod_security) å slå seg vrang. Det var problemer med skriving til logg-fil og dermed stoppet apache og ville ikke la seg starte igjen, noe som førte til at folk ikke kom seg inn på sidene sine. Vi begynte da å jobbe med serveren for å se hva som var galt. Det viste seg etter kort tid at det var noe feil med filsystemet og ikke en softwarefeil som vi opprinnelig trodde. Vi kjørte dermed en sjekk (fsck) for å se om dette var noe som kunne fikses. Det begynte etterhvert å vise seg at det var flere lese/skrivefeil på disken og etter å ha kjørt flere skanninger og konsultert med datasenteret, ble det avgjort at vi skulle sette inn en ny disk.
Serveren kjørte med 2 disker satt opp i raid-1 oppsett, noe som betyr at det i teorien skulle ligge en eksakt kopi av dataene på disk 2. Dermed skal det vanligvis bare være å sette inn 1 ny disk og så vil innholdet på disk 1 gjenopprettes automatisk fra disk 2. Av en eller annen grunn (som vi fortsatt ikke har funnet ut av) var ikke innholdet på disk 2 identisk, og dermed lot ikke ting seg synkronisere. Nå har vi rutiner for slike ting og det var her jeg tok en feil avgjørelse. SolidHost kjører 2 backupsystemer; cPanels system, som kjører daglige, ukentlige og månedlige backups + R1soft backupsystem. Alt backes selvfølgelig opp til separate, dedikerte backupservere.
R1soft systemet har vi desverre ikke fått installert på alle serverene ennå og dette var en av serverene som ikke var beskyttet av dette systemet ennå.
Vi stod nå ovenfor en situasjon som gjorde at vi måtte velge å reinstallere hele serveren og deretter kjøre inn backup data. Siden cPanels backupløsning kjøres 1 gang i døgnet (og gjerne om natt/tidlig morgen) var det bare et fåtall kunder som hadde fått "dagens" backup før serveren sluttet å fungere. De aller fleste hadde en backup som var nærmere 2 dager gammel.
På dette tidspunktet trodde jeg ennå at dataene på disk 2 som stod i serveren var "speilet" fra disk 1 og jeg valgte derfor å prøve å gjenopprette dataene fra disk 2. Grunnen til dette var at jeg følte det var bedre å kunne gi tilbake alle kundene "nyere" data enn å begynne å gjenopprette fra backuper som var over 24 timer. Her gjorde jeg en feilvurdering og gikk ut over det vi har av etablerte rutiner. Det skulle nemlig vise seg at det hadde oppstått en feil med speilingen og dataene som lå på disk 2 var alt fra 0 - 168 timer (1 uke) gammelt og dermed ble det som ble gjenopprettet deretter. Når denne gjenopprettingen var ferdig (nesten 24 timer sener) hadde det skjedd som gjorde at dette tok mye lengre tid enn det skulle ha gjort; cPanel lagrer bare 1 versjon av "daglig backup" og dermed overskrives den gamle backupen når ny, daglig backup tas. I og med at vi hadde opprettet "gamle" systeminnstillinger, var også backupen fra denne serveren igjen aktivert og dermed ble backup tatt av cPanel, med gamle data på serveren, og disse overskrev siste versjon av backup som vi hadde liggende. Om man skal kalle det siste hell i uhell vet jeg ikke, men vårt siste valg var nå å prøve å redde data ut fra den ødelagte disken. Vi fikk denne satt inn i serveren igjen og etter å ha jobbet med denne i noen timer, klarte vi å redde ut nyere data fra denne til kunder som var avhengig av dette.
Status pr. nå er at de fleste hjemmesider på serveren var oppe og gikk med 6-7 timer eller mindre nedetid og alle vitale data var gjenopprettet innen 24-36 timer.
Etter dette er prosessen med å utvide vårt backupsystem akselerert og innen i kveld vil alle våre servere være operative i R1softs backupsystem hvor vi oppbevarer daglige backup av våre webhotell i en uke før disse slettes. Vi evaluerer alltid slike hendelser og selv om vi som jobber med disse tingene har lang erfaring, så er SolidHost fortsatt et lite firma og vi tar slike ting meget seriøst. Vi har allerede laget endringer i våre rutiner og oppdatert godkjenningsprosesser, hvor situasjoner som f. eks. gjør at man skal gå utenom rutiner, skal evalueres av flere og godkjennes.
Vi har fra første stund kommunisert med våre kunder, både via e-post og våre hjemmesider om fremgangen og om faren for datatap etterhvert som dette ble et tema. Vi er alltid ærlige mot våre kunder om status i slike saker og prøver ikke å rosemale ting for å gi våre kunder falske forhåpninger, da vi mener at ærlighet varer lengst.