Valideren van je backup

[Japje]

Door een rare uitval van een raidcontroller ben ik gaan nadenken over hoe je data veilig kunt backuppen. Wil jullie het volgende voorleggen en ben benieuwd hoe je het zou oplossen:


Stel je hebt een simpele server, om je data veilig te houden wil je raid draaien, en je kiest voor raid 1.

Om je data te backuppen maak je gebruik van bv rsync (met een pakkket zoals rsnapshot) om je data incrementieel veilig te stellen op een apparte server. Dit doe je elke nacht, en 7 dagen in de week. Tevens gebeurt dit ongecomprimeerd. Er word dus geen tarbal of gzipje van gemaakt.


Nu draait alles goed en de klantjes zijn lustig aan het gebruik maken van hun accountjes :D

Opeens krijg je een mailtje/smsje van je monitorings systeem.. je server is down! :( Je rushed naar je server toe en komt tot de conclusie dat je partitie tabel aan gort is en ondanks verwoede pogingen je deze niet kunt herstellen dmv een fsck (of iets anders wat aan repair van FS doet).

Tja, daar zit je dan.. :crying: maar je blijft niet zielig zitten doen.. je pakt een spare server.. slingert deze aan op het ip van de oude server en log je vast in op je backupserver want je gaat gewoon de data terugzetten en dan is alles weer goed :thumbup:

je zet je scp (oid) aan en hij begint lustig te kopieren! zo hoort het ook! Maar terwijl je naar je terminal zit te kijken begint het je op te vallen dat accounts wel heeeel erg snel gekopieerd zijn.. sterker nog.. dat ene account.. van die grote klant met zn grote filmpjes is binnen luttele seconden overgezet.. hoe kan dat nou?

Je zet je scp uit en cd'ed naar de backup dir van vannacht en begint rond te neuzen... je pakt dat ene accountje van die grote filmpjes.. en begint woest te ls -alh'en ... alle files zijn maar een paar KB groot :huh: WTF denk je.. en langzaam begint de realiteit binnen te sijpelen.. je backup is corrupt :crying:

Sterker nog! Alle 7 backups zijn zo gaar als een raap.. is niets meer mee te beginnen. :cursing:

Er zit niets anders op dan het aan je klanten te melden.( De afhandeling hiervan laat ik voor wat het is)

Door onderzoek van de server kom je er achter dat de raidkaart geen raidsets meer herkent, en als hij al iets doet dan is het erg snel stuk.. de kaart is dus brak/stuk/kapot/stom

Bij controle van de 2 disks in de server merk je dat 1 disk idd stuk is en nu je stapel fanmail netjes bij elkaar kan houden door er op te liggen.

De 2e disks is echter wat grappigs mee, deze heeft nog een beetje data er op staan, maar deze data dateerd ruim 3 maanden geleden! Deze disk is dus uit je raidset gebonjoured door de raidkaart zonder dat hij echt stukstuk was. En belangrijker nog, de raidkaart heeft dit niet gemeld! anders had je er een andere disk in gedaan! ;-) Dan was het geheel misschien niet eens gebeurt!



Dus als moraal van dit verhaal, hardware blijft hardware en kan op de meest vreemde manieren stuk gaan.

dus..

Hoe zorg je er voor dat je backups correct zijn?

Ben erg benieuwd wat voor oplossing je zo verzinnen.. welke je nu gebruikt of hebt gebruikt!

[Jesperw]

Er is denk ik maar 1 oplossing. Backups controleren met je eigen handjes, menselijk verstand en dus gewoon kijken of alles healthy is.

[VinceSTM]

Wij hebben een rsync backup process draaien + een verify ervan.

Dit is een afzonderlijk proces: hij kiest elke 4 uur 5 willekeurige bestandjes uit hele willekeurige mappen die ouder zijn dan de laatste backup en maakt daar een md5 hash van. Deze controleert ie met het origineel. Daar krijg ik een mailtje van ;)

[Japje]

Wij hebben een rsync backup process draaien + een verify ervan.

Dit is een afzonderlijk proces: hij kiest elke 4 uur 5 willekeurige bestandjes uit hele willekeurige mappen die ouder zijn dan de laatste backup en maakt daar een md5 hash van. Deze controleert ie met het origineel. Daar krijg ik een mailtje van ;)

En doe je dit vanuit de content? of vanuit de benaming?

Het punt is namelijk een beetje, als je op de zelfde manier controleerd als je backupt.. namelijk het lezen van een file, kan de uitkomst hetzelfde zijn. Ondanks dat die file misschien al corrupt is.

Heb al zitten nadenken over het maken van files random op de disk waarvan ik weet wat er in staat (of in zou moeten staan) en dit controleren met de backup.

Echter zit je dan met het probleem dat dit slechts een steekproef is. En slechts een zeeer klein gedeelte van je totale disk is. Grote kans dat je aan het controleren bent op een stuk wat het prima doet! (dan heb je wel wat goeie files in je backup natuurljk ;-) )

En wat jesper zegt is natuurlijk waar, je kunt IMHO nooit 100% zeggen dat een backup goed is zonder dat je er zelf naar kijkt (of hebt laten kijken). Maar wij hebben bv meer dan 40 webbakken, met elk meer dan 25gb aan data.. dat is alsnog niet (eenvoudig) te controleren door een mens. Dan moet je al met meerdere personen backups gaan controleren :P

[Erik H.]

Ik herken het probleem. Je denkt met 700 shared hosting pakketjes al snel dat het goed zit. Tot je dat ENE database-je nodig hebt en blijkt dat die nimmer is gebackupped. Dat is meer dan vervelend. En leg dan maar uit dat je toch echt backups maakt .....

[MMaI]

volgens mij is hiervoor dan ook een funcite ontwikkeld die md5 heet :P
redelijk eenvoudig te implementeren door via een shell scriptje een willekeurig bestand uit je map te selecteren, vervolgens hiervna een hash (fingerprint) te maken en deze te vergelijken met je remote gebackupte variant.

goede manier is ook het gebruik van snapshots en vervolgens de grootte controleren (automatisch via du [args + map] > [je output file.txt])

[Japje]

volgens mij is hiervoor dan ook een funcite ontwikkeld die md5 heet :P
redelijk eenvoudig te implementeren door via een shell scriptje een willekeurig bestand uit je map te selecteren, vervolgens hiervna een hash (fingerprint) te maken en deze te vergelijken met je remote gebackupte variant.

goede manier is ook het gebruik van snapshots en vervolgens de grootte controleren (automatisch via du [args + map] > [je output file.txt])

een md5sum van een lege file is gelijk aan een md5sum van die zelfde file ;-)

Die laaste is an sich wel een id, maar net anders. Ik weet dat mn backups steeds groter worden. soms gelijk blijven, maar nooit kleiner worden.Je zou dus bij kunnen houden hoe groot een backup was, en de nieuwe backup vergelijken met de vorige (of vorige week, of maand) en als ie kleiner is (mag 1% afwijken) kun je mailtje laten sturen.

Maar dan nog.. corrupte bestanden kunnen ook gewoon netjes groot zijn :P

Hoe langer ik er over nadenk, hoe logischer het is dat je niet kunt controleren of je bron geldig is zolang je diezelfde bron gebruikt om je data te valideren ;-)

Tenzij iemand nog een goed id heeft? ;-)

[MMaI]

meerdere bestanden als source gebruiken om de md5 hash te vergelijken :P

[mind]

Je zou een percentage bij kunnen houden van de bestaande bestanden in een back-up die per run aangepast worden. Zie je hier een grote piek, dan is er hoogst waarschijnlijk wat mis met het origineel en is nader onderzoek nodig.