Xen image backup

Virtualizáció

Vannak gigás futó image-k Xen alatt, arról kéne naponta konzisztens (mármint pillanatnylag) mentést
csinálni.
Persze ismerjük az lvm snapshotos megoldást, de estleg valami más van e, amiről nem tudok?
Illetve az előzőhöz is kérnék tippeket...ki hogy csinálja?

  • 8609 megtekintés

( tilla_canet | 2011. 08. 30., k – 11:52 )

Üdv!

Én így csinálom a backupot, majd ftp-n elküldöm egy belső ftp szerverre:


#!/bin/sh
TAR="/bin/tar"
DATE="/bin/date"
MOUNT="/bin/mount"
UMOUNT="/bin/umount"
LVCREATE="/sbin/lvcreate"
LVREMOVE="/sbin/lvremove"
# Asterisk
`$LVCREATE -s -L 5G -n backup_img_snapshot /dev/vg01/asterisk.xxxx.hu-disk 1>> /root/Backup/error.txt 2>> /root/Backup/error.txt`
`$MOUNT /dev/vg01/backup_img_snapshot /mnt 1>> /root/Backup/error.txt 2>> /root/Backup/error.txt`
`$TAR --create --gzip --exclude-from=/root/Backup/exclude-asterisk.files --file /root/Backup/asterisk.tgz /mnt 1>> /root/Backup/error.txt 2>> /root/Backup/error.txt`
`$UMOUNT /mnt 1>> /root/Backup/error.txt 2>> /root/Backup/error.txt`
`$LVREMOVE -f /dev/vg01/backup_img_snapshot 1>> /root/Backup/error.txt 2>> /root/Backup/error.txt`

Ha a teljes partíciót mented, akkor nem kell az exclude rész! (Az error.txt-t pedig elküldöm emailbe magamnak!)

Tilla

( kiuka | 2011. 08. 30., k – 11:52 )

én lvm snapshot alapjan szoktam igy:

xm pause id
lvcreate -s id_lvm
xm unpause id

aztan mount, tarolom es kesz

( uid_2716 | 2011. 08. 30., k – 21:58 )

Nem igazán vágom, hogy az LVM snapshot hogyan tud egyáltalán működni. A logical volume egy élő, felcsatolt file-rendszert tartalmaz. Ha erről simán csinálunk egy snapshot-ot, akkor azt legközelebb felcsatolva rögtön lehet fsck-val kezdeni. Persze, persze, az fs valószínűleg naplózó, de azért az üzemszerű mentésnek ne legyen már az fs journal a része. A vm memóriájában lévő dirty buffer cache-t így minden egyes mentéskor elveszítjük.

Arról nem is beszélve, hogy a vm-ben valamilyen alkalmazás ezerrel dolgozhat (pár millió soros update oracle-ben...), ilyenkor talán nem szerencsés a mentést megfosztani a vm memóriájától. Szóval én két lehetőséget látok (bár nem vagyok rendszergazda):

  • Rendes
    xm save

    , majd amikor kész, gyorsan LVM snapshot és 

    xm restore

    . A mentésbe a teljes snapshot és a memória dump kerül. Helyreállítás csak vm szinten, az alkalmazások meg magukra vessenek (megszakadó TCP kapcsolatok, timeout-ok stb).

  • A vm-en belül read-only mount-oljuk a file-system-eket (ez persze a legtöbb alkalmazás leállításával jár), LVM snapshot, remount rw, alkalmazások újraindítása. A snapshot ekkor mount-olható RO-ban, és menthetjük, ahogy akarjuk.

( talisker | 2011. 08. 30., k – 23:28 )

subscribe
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

( funkykutya | 2013. 08. 28., sze – 10:14 )

Sziasztok!

Bocs, hogy felhozom ezt a régi témát, de hasonló problémával küzdök.

A VM-k sima ext3-on vannak, ezeket szeretném backup-olni nfs-en keresztül egy másik vasra, ahol leállítva pihennek. Vész esetén a másik vason indíthatóak lennének a VM-k.

Az igazi talán a xen live migration lenne, de ahhoz egy közös storage is kellene.

Próbálkoztam az xm-pause -al a másolás idejére, de nem egy elegáns
megoldás.

A live migration másra való. :)

A konzisztenciát igénylő (sql szerver) cuccokról csinálj a külső szerverre dumpot, az a biztos megoldás. Pl. MySQL-nél a mysqldump remekül átküldhető direktben ssh-n. Direkt nem a replikációt írom, mert az azonnal átküldi a DROP DATABASE-t is, akár kell, akár nem. :)

DRBD-t nézegettem/nézegetem :)

Igazság szerint pont azért virtualizáltam be, hogy az egyes gépeket egyszerűen lehessen menteni. Szóval nem akarok nagyom még külön mysql-eket dumpolgatni.

Egyenlőre ami biztos megoldás az a shutdown, másolás, create.. De ez nem valami elegáns...

A live migration mire való? :) Lehet hogy nem pont erre, de első ránézésre erre is jó lenne...

En biztos nem dumpolassal csinalnam, egy mysqldump visszatoltese a kulcsok ujraszamolasa miatt par ora is lehet. Akkor mar inkabb hotcopyval lementenem az osszes db-t. No ez persze csak innodb_file_per_table=1 mellett mukodik.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Tehát leállítás nélkül ezekszerint nem lehet normális backupot csinálni?

Mert ahogy lacos is írta annak idején, pause után ELVILEG akármivel is mentem az image-t, az új vason a backup indítva bizony tele lesz filerendszer hibákkal, és akkor még az egyéb félbeszakadt dolgokról nem is beszélek.

Szóval itt szerintem már nem is a drbd, sima copy, vagy lvm snapshot az alapvető probléma..

Az a baj, hogy a snapshot is csak 1 idopillanatban történik. Szóval ha pl van egy 2 perces SQL tranzakció akkor mi lesz a snapshotkor ? Vagy elkezd valaki feltölteni nagy fájlt? snapshotkor lehet csak a fele lesz ott.

Szoval ha tuti mentes csak shutdown vagy legalabbis a szolgáltatások kikapcsolásával lehet. szvsz

Fedora 19, Thinkpad x61s

Nezd valahol kompromisszumot kell kotni a backup integritasa es a rendszer rendelkezesreallasa kozott. Ha azt mondom, hogy belefer az, hogy az eppen feltoltott fajlok csak reszben lesznek ott, cserebe viszont nem allhat meg a gep egy pillanatra sem, akkor ez a megoldas mukodhet. Ha megallhat a gep, akkor viszont novelheto a backup integritasa.

Mondjuk SQL-t amugy se mentunk igy, hanem azt a geprol erdemes menteni, hogy konnyu legyen kiadni a LOCK TABLES-t az epp mentett adatbazisra.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Félig off:

"Tehát leállítás nélkül ezekszerint nem lehet normális backupot csinálni?"

De lehet ha a vendor is úgy akarja.

Lásd. MS SQL Server + Volume Shadow Copy. Ez leállítás nélkül tud csinálni konzisztens mentést.
Alapjaiban úgy működik, mint az LVM snaphost, csak a mentés előtt beszól VSS-en keresztül az SQL Servenek, hogy helló készülj, menteni foglak, az meg vissza szól, hogy kész vagyok, mehet a mentés.

Igen, nagyjából erről van szó. Például:

  • libvirt szól a Linux VM-ben futó qemu guest agent-nek, hogy "guest-fsfreeze-freeze"
  • a guest agent lefuttat egy sor scriptet, amely az egyes alkalmazásokat "lecsendesíti" (adatbázisok nem fogadnak további kapcsolatokat, a futó tranzakciókat elvégzik vagy abortálják a meglévő session-ökön, buffer-eket kiírják, session-öket felfüggesztik -- ez mind alkalmazásfüggő; olyan is lehet, hogy valamit le kell állítani)
  • ezután a guest agent meghívja a FIFREEZE ioctl()-t a felcsatolt file-rendszereken, aminek hatására ez utóbbiak is konzisztens állapotba kerülnek (amikor az fsck nem talál rajtuk hibát, kb. mint egy read-only mount); további write request-ek blokkolódnak
  • ezután a guest agent visszatér a libvirt-hez a "guest-fsfreeze-freeze"-ből
  • a libvirt elkészíti a másolatot vagy a snapshot-ot
  • a libvirt szól a guest agent-nek, hogy "guest-fsfreeze-thaw"
  • a guest agent meghívja a FITHAW ioctl()-t
  • a guest agent meghívja ugyanazokat a scripteket, mint korábban, csak más paraméterezéssel -- ennek hatására programok újraindulnak ill. felélednek
  • a guest agent visszatér a libvirt-hez

A fenti módszert egy ideje windows VM-ben is támogatja a qemu guest agent, a VSS-t egy elég trükkös módon a fenti keretekbe kényszerítve. Nemrég implementálta Tomoki Sekiyama.

http://thread.gmane.org/gmane.comp.emulators.qemu/226952/focus=227179