Data recovery

Zoals eerder aangehaald, konden we twee weken terug aan de slag met de recuperatie van wat data. Met een goede portie logisch denken zijn we erin geslaagd om de verloren gewaande data terug te halen. Een half dagje systeembeheer dat niet doordeweeks is. 

Situatieschets

De situatie was als volgt: twee disks die via een Areca Raid Controller in een RAID 1 (mirror) configuratie zaten, waren voorzien van een Citrix XenServer 5.5 installatie. Deze installatie werd verkeerdelijk overschreven met een standaard virtualisatie "zoals wij het normaal doen". Ons recept is ook geen groot geheim: een aantal partities: boot, swap en root, en daarna een groot stuk dat onder LVM controle geplaatst wordt. (De boot-partitie is heden ten dage natuurlijk niet meer nodig, maar we doen dit al even, en we slepen al soms een oud gebruik mee...).

De disks werden dus herpartitioneerd en hervoorzien van file-systemen. Helaas was er een stuk data op die disks die niet gebackupped was en wat de klant zeer graag terug wou.

Na wat analyse werk kwamen we tot de volgende uitgangs-situatie: XenServer 5.5 partitioneert het systeem in een standaard installatie als volgt: twee keer een partitie van 4 GB voor XenServer zelf en dan een partitie voor de "local storage". Die "local storage" is dus wat we nodig hadden. Het begin van dit stuk data bevond zich rond de 8 GB, gezien vanaf het begin van de disk. Na wat rekenwerk kwamen we uit op sector 16032870.

De installatie die we toegepast hadden maakt een partitie van 200 MB voor de boot, daarna een partitie van 2 GB voor swap en dan een partitie van 10 GB voor de root. Uiteindelijk maken we een extended partitie met daarin één stuk voor LVM. Al bij al konden we veronderstellen dat de basisinstallatie van Debian zeker nog geen data over de LVM data gezet had, behalve dan de ext3 superblok-backups die geschreven waren bij het aanmaken van het root filesysteem. We gingen er echter van uit dat als die een stuk van het filesysteem overschreven hadden we met een repair-opdracht vermoedelijk nog grote stukken andere data zouden kunnen terughalen. Er was meer dan een grote kans dat verder zoeken de moeite waard was.

Na een initiële extra veiligheidskopie genomen te hebben van de disks, gingen we aan de slag. We namen een gelijk systeem, met exact dezelfde RAID-kaart, gelijke disks (zelfde merk, grootte en reeksnummer) en een gelijke configuratie (RAID 1) zodat we sector-gewijs zeker gelijk werkten...

De eerste poging

Een eerste poging was eenvoudig: we namen de partitietabel van een XenServer installatie op exact dezelfde configuratie (zelfde server, raidcontroller en disks) en schreven die over de partitietabel op de disk. Helaas, geen direct succes. Er werden geen LVM headers gevonden in het begin van de data-partitie. Een partitietabel herschrijven is vrij eenvoudig, het is de eerste 512 byte op een disk waar dit opgeslagen wordt wanneer een eenvoudig MSDOS disklabel gebruikt wordt. Met "dd count=512 bs=1 if=/dev/sda of=/usbstick/partheader" is dit een fluitje van een cent. Je kan het ook met sfdisk doen: "sfdisk -d /dev/sda > /usbstick/partheader_sfdisk" om op te slaan en "sfdisk /dev/sda < /usbstick/partheader_sfdisk" om het terug inteladen.

De tweede poging

Een tweede poging werd gedaan met software om partitie-headers en file-system headers te detecteren. We lieten dit los rond de 8GB marker, in de veronderstelling dat er kleine verschuivingen waren, en dat we enkele sectors verkeerd zaten in onze partitionering. Ook hier geen geluk. We gebruikten hier enkele tools, waarvan "gpart" en "testdisk" onze eerste keuzes zijn.

Derde keer goede keer...

Daarna waren alle gemakkelijke oplossing opgebruikt, en moesten we manueel aan de slag. We bleven hardnekkig geloven dat we correct gerekend hadden en dat de LVM header zich op sector 16032870 bevond. Met het commando "dd" haalden we wat data rond die marker van de schijf (een 10-tal MB aan data) en gingen we even "manueel" kijken. De eerste "pagina's" waren weinig belovend, maar opeens zagen we een flard LVM-config. Blijkbaar, naast de headers, wordt een backup van de configuratie (en vorige configuraties) weggeschreven in de LVM header.

Met deze configfiles (die ook in /etc/lvm/backup/ worden weggeschreven op een standaard systeem) kan je normaal je structuur op je disks terug wegschrijven in de LVM headers. De data werd terug ingelezen met "dd", waarna we gewoon in Textmate wat knip en plakwerk deden. Geen rocket science daar, behalve dat je op zoek moet gaan naar de laatste goede versie. In de config zitten echter "seqno" velden die oplopend zijn, zodat je eenvoudig de ordening kan terugvinden.

Nu hadden we de twee nodige delen van de oplossing - de layout van de LVM-volumes in de configfile en de zekerheid dat we toch correct waren qua beginsector van het LVM block device. Nu moesten we alles nog samen puzzelen. We maakten een correcte LVM-backup file uit de verzamelde informatie, en her-initialiseerden de LVM headers met de correcte UUIDs en bijhorende informatie (pvcreate neemt parameters die bvb de UUID vast instelt, vgcfgcheck kan een configuratiefile lezen en herzetten). Zo kregen we opnieuw onze logische volumes te zien.

XenServer maakt verschillende volumes aan voor de verschillende virtuele machines. Na een installatie van XenServer, en het uitvoeren van verschillende stappen om bestaande storage aan een nieuwe installatie van XenServer te koppelen, waren we uiteindelijk in staat om de data te recuperen.

Al bij al een leuk namiddagje systeembeheer. Dat we de nodige data konden recupereren is natuurlijk zeer mooi meegenomen en zorgde voor een tevreden klant en extra trots bij onszelf.

Uiteraard werd het backup-schema van deze kritieke data ondertussen aangepast in samenspraak met de klant en zal dit in de toekomst niet meer voorvallen.