[LVM2] snapshot van logical volume wat zwaar gebruikt wordt

[Bart B]

Hallo allemaal,

Ik heb thuis een server opgezet met GenToo Linux (samba, ldap, mysql, postfix e.d.). Voor het opslaan van de belangrijke bestanden heb ik een software RAID1 array ( MD ), en voor het makkelijk indelen van de ruimte is hier bovenop LVM2 geconfigureerd. Dit werkt ook zonder problemen.

Nu heb ik op dit moment met "rdiff-backup" een incremential backup van directories op een logical volume. Ik zou alleen heel graag een snapshot gebruiken, omdat ik dan tijdens de backup zeker weet dat de gebruiker geen verandering maakt. Opzich is het geen ramp dat de gebruiker een wijziging maakt, maar er zijn een aantal situaties waar ik het niet wil hebben.

Ik heb alle support in de kernel zitten voor het maken van een snapshot. Demonstratie hieronder

atec old # lvcreate -L1G -ntest --snapshot /dev/lvm_110G_r1/bmr_
aztec old # lvcreate -L1G -ntest --snapshot /dev/lvm_110G_r1/bmr_home
  Logical volume "test" created
aztec old # mount /dev/lvm_110G_r1/test /mnt/temp
aztec old # df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/lvm_110G_r1-bmr_home
                       50G   17G   30G  37% /home

....

/dev/mapper/lvm_110G_r1-test
                       50G   17G   30G  37% /mnt/temp

Bij mijn weten heeft LVM geen kennis van het file system (ext3 in mijn geval). Wat gebeurt er nu als er veel wordt geschreven naar een logical volume, en ik maar tijdens dat schrijven de snapshot aan? Volgens mij zou dit dan kunnen resulteren in een snapshot waarvan het file-system niet in orde is. Dit is dan ook niet bruikbaar voor backups.

MIJN VRAAG
Hoe kan ik er voor zorgen dat een snapshot altijd een valide filesystem bevat. Of wordt dit automatisch gedaan?

[Bart B]

^^ subtiele schop ^^

niemand die me hier iets over kan vertellen? Ik zal toch niet de enige op GoT zijn die LVM2 en snapshots (wil) gebruiken?

[DeBolle]

In principe heb je gelijk. LVM heeft geen kennis van het filesystem en tijdens de snapshot moeten geen files worden beschreven, eventuele databases moeten worden gesloten, enz. Een snapshot is immers een "foto" van de status van het hele filesystem, inclusief alle flags op dat moment. Dat betekent bij een open database bijvoorbeeld dat de te restoren versie eerst gerecovered moet worden of een log replay (roll back of forward) moet doorstaan voordat de applicatie de database weer kan gebruiken. Hetzelfde geldt voor normale bestanden, alle flags gaan mee in de snapshot (open voor write, locked) en zijn daarom pas na een eventuele herstelactie te gebruiken.
Het zal niet vaak of zelfs nooit voorkomen dat er tijdens een snapshot net iets wordt geschreven naar het filesystem of een bestand, de kans is er natuurlijk wel. Verder zijn er vrijwel geen applicaties welke rekening houden met snapshots, in feite moeten alle applicaties een commit doen naar het filesystem voordat de snapshot start.
Voor een consistente backup moet daarom het filesystem quiescent zijn, de meeste garantie wordt dan geboden door het filesystem read only te mounten voordat de snapshot wordt gemaakt.
Samengevat geldt dan ook dat hetzelfde moet gebeuren als bij een "normale" backup - users uitgelogd, applicaties gesloten, databases quiescent.
Als je de momenten waarop je een consistente snapshot wilt hebben kunt definieren is dit natuurlijk te scripten. Je zou kunnen overwegen om de (enkele?) bestanden die niet consistent meegaan in een snapshot gewoon mee te laten gaan en het risico nemen. Je weet het, Murphy's Law telt natuurlijk mee - dat ene bestand wat je wil recoveren was nu juist gelocked en bevat de inhoud van vorige week
Buiten LVM (en buiten Linux) zijn er veel toepassingen van snapshots die andere zaken doen en andere mogelijkheden hebben om de consistentie garantie te bieden, maar het gaat nu even om de omschreven situatie met LVM.

[Bart B]

DeBolle schreef op maandag 27 november 2006 @ 20:21:

... heel duidelijk verhaal te lang om te quoten ...

Ik snap dat ik nooit kan zorgen dat files en databases consistend zijn op het moment van het maken van de snapshot. Gelukkig voor mijn situatie is dit niet nodig, omdat het om de /home/<user> directories gaat. voor de databases en LDAP heb ik scripts die een LDAP en MySQL export doen.

Ik snap ook dat ik niet kan afdwingen dat alle files die open/in gebruik zijn consistend zijn. Dit is idd heel erg applicatie afhankelijk Het enige wat ik wil is dat het file-system consistend is.

Je voorstel om het file-system read-only te mounten had ik ook al aan gedacht. Mijn idee was om dan een scriptje te maken die :

- partitie mounten read only
- creeer snapshot
- partitie terug readwrite mounten

probleem is denk ik dat alle openstaande files voor read/write waarschijnlijk readonly open zijn, en ik niet weet hoe samba daarop reageerd.

[Bart B]

RESULTAAT:

Ik draai nu al enkele maanden met een backup, gebruik makende van LVM2 snapshots. 3* per dag wordt een snapshot gemaakt, wordt een backup gemaakt, en het snapshot wordt verwijderd. Tot nu toe geen echte problemen gehad.

het werkt

[Verwijderd]

Natuurlijk werkt het: je gebruikt namelijk een journalling filesystem. Eigenlijk kun je het maken van een snapshot (qua filesystem-status) vergelijken met een power failure: het filesystem en applicaties daarop hebben geen kans om alles consistent weg te schrijven.

Op het moment dat je een inconsistent journalling filesystem (dus niet een inconsistente database, maar echt het onderliggende filesystem) mount, dan zal het FS zichzelf herstellen naar een consistente staat. Het ligt aan je journalling-configuratie op welke manier dit gebeurt (kijk bijv. eens naar de tune2fs-documentatie over journalling)

In principe zijn goede applicaties (denk aan MySQL) ook in staat om zich na een power failure te herstellen naar een consistente staat, dus ook op een niveau hoger (applicatieniveau) gaat het bijna altijd goed.

Hoe dan ook, je hebt altijd een consistent filesystem. En dat is het belangrijkste!