KVM backup/snapshot

Linux-haladó

Üdv!

Milyen módszerrel csináltok a KVM virtuális gépeiről mentést?
Ütemezett (cron) megoldást keresnék. Mennyire használható a qemu snapshot-ja? Ez online készíti gondolom, azaz egy adott pillanatbani állapotot (ahogy a neve is mondja). Ami egy az egyben visszaállítható. Vagy a virsh Live Snapshot?

Vagy mást megoldást használtok?

--
G.

  • 8546 megtekintés

( Elbandi v | 2014. 11. 09., v – 23:03 )

proxmox sajat backupja: egy pillanatra megallitja a gepet, csinal egy lvm snapshotot, majd azt lementi (config + diskek raw data egy tarban tomoritve).

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( makgab v | 2014. 11. 10., h – 09:32 )

A virsh Live Snapshot-ja nem igazán megy:

# virsh snapshot-create-as CentOS7_backup snapshot1 "Backup snapshot1 description" --disk-only --atomic
hiba: Operation not supported: live disk snapshot not supported with this QEMU binary

A qemu snapshot-ja működik:

# qemu-img create -f qcow2 -b CentOS7_backup.img backup-snapshot.img
Formatting 'backup-snapshot.img', fmt=qcow2 size=42949672960 backing_file='CentOS7_backup.img' encryption=off cluster_size=65536 lazy_refcounts=off

# qemu-img info backup-snapshot.img
image: backup-snapshot.img
file format: qcow2
virtual size: 40G (42949672960 bytes)
disk size: 196K
cluster_size: 65536
backing file: CentOS7_backup.img
Format specific information:
compat: 1.1
lazy refcounts: false

Ez utóbbi nem egy nagy fájl lett. Az eredeti img méretét nézve (5GB -> 196KB).
A doksi szerint csak a változások kerülnek bele? Jól értem?
Vagy a Temporary snapshot lenne jó?
qemu -hda centos-cleaninstall.img -snapshot

--
G.

( makgab v | 2014. 11. 10., h – 09:43 )

Itt van egy "backup.sh" script, ami csak rsync-el ment - ha jól nézem.
A KVM img fájlja csak így simán lemásolható (és a restore meg egy visszamásolás), vagy elkerüli valami a figyelmemet?

--
G.

Igen, megnéztem én is. Köszönöm.
Viszont a virsh shutdown nem működik, utána fut állapotban van a VM:

# virsh shutdown CentOS7
CentOS7 tartomány leállítása folyamatban

# virsh list
Azonosító Név Állapot
----------------------------------------------------
3 CentOS7 fut

A suspend működik (és resume is):

# virsh suspend CentOS7
CentOS7 tartomány felfüggesztve

virsh list
Azonosító Név Állapot
----------------------------------------------------
3 CentOS7 megállítva

Ez valami acpi probléma lesz?

(A host gép CentOS7 x64.)

--
G.

( makgab v | 2014. 11. 10., h – 10:50 )

Ez alapján lehetne dd-vel is?

dd if=/path/to/virtualmachine1.img of=/backup/to/backup.img bs=512K

Ez "live" is működhet? Bár lehet hogy inkább leállított VM-el biztonságosabb.

--
G.

Technikailag mukodik, gyakorlatilag az eredmeny nagy eselyel egy inkonzisztens allapot -> Backupnal alap szabaly, hogy a backupolando adatot konzisztensz allapotba kell hozni mielott meg elkezdened backupolni. Virtualis gepnel abba a problemaba fogsz belefutni, hogy hiaba keszitesz snapshotot az adott filerendszerrol, attol meg a virtualis gepen belul az adat siman inkonzisztens lehet (az adat resze nincs kiirva a diszkre), tehat vagy olyan megoldas kell neked, ami ossze tud dolgozni a virtualis geppel is, vagy pedig le kell lonod a virtualis gepet ideiglenesen amig a backup folyik (akkor tuti nem irja semmi sem a virt-gephez kotheto adatot :))
Alternativa, hogy nem a KVM szerveren probalkozol, hanem leviszed a backupot a kliens szintjere, es hagyod, hogy a kliens gondoskodjon az adat-konzisztenciarol.

Edit: Most megneztem a CentOS wikit - ott egy server-kliens megoldast javasolnak (tehat amikor a szerver osszebeszel a kliensel): http://wiki.centos.org/HowTos/BackupKVMGuest#head-644eea5899ec1692af5bb…
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Ha jól tudom a suspend is elég nem kell leállítani
DD helyet, meg egyáltalán img lemezek helyett lvm-re költöznék, és akkor úgy lőném be, hogy suspend utána lvm-snapshot majd resume, ez viszonylag gyorsan megvan, majd másolnám a snapshot + a guest konfigot a backup területre.

Az oprendszerek/alkalmazások/journaling filerendszerek felelőssége az, hogy minden időpillanatban konzisztens adat legyen kiírva a (virtuális) adathordozóra. Amennyiben ez nem teljesül, akkor még egy szimpla áramszünetet se biztos hogy túl él.
Egy LVM alapú snapshotnak elég kell lennie (ami szintén crash state konzisztens).

Hat ezzel vitatkoznek szemely szerint: Legtobb DB nem COMMITOL minden tranzakcio utan, a tranzakcios logok is csak kis delay-el irodnak ki, illetve az OS maga se syncel minden pillanatban. Amugy ertem en, hogy mit szeretnel kihozni belole, sot meg azt modnom, hogy van olyan eset amikor ez meg mukodhet is, de azert en erre a technikara nem biznek komolyabb rendszert
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Pedig komoly helyeken storage szinten megy a replikáció a site-ok között, és storage failover esetén szükséges a mindenkori konzisztens állapot fenntartása. Szerintem minden kereskedelmi DB ügyel erre, hiszen széles körben támogatott ez a fajta replikáció (de gondolhatunk itt akár egy vSphere cluster host kiesés utáni VM rebootra is).
Itt egyébként nem teljesen arról van szó, hogy mindig minden legyen kiírva a diszkre, hiszen akkor nagyon lassú volna. Inkább arról van szó, hogy a kiírás megfelelő sorrendben történjen meg, hogy egy crash state-ből recoverezhető legyen egy konzisztens állapot, ami azt is jelentheti, hogy az utolsó néhány tranzakció elveszik.
Tudtommal a DB-k O_DIRECT módban nyitják meg a filerendszert, hogy önmaguk szabályozzák, hogy pontosan mikor mi íródjon ki, ne az OS cache-eljen össze-vissza...

Szerk.: és ugye van olyan hogy "hot backup mode" DB-knél, ami gondolom annyit jelent, hogy bőszen fsync-el minden írás után. Ezt elég csak arra a néhány másodpercre aktiválni, amíg az (LVM) snapshot elkészül.

Ennek azert en a helyedben jobban utana jarnek, mert a valosagtol kicsit messze all. Igaz, hogy 1-1 ilyen kieses eseten a rendszernek kepes kell lennie ismet felalnia, de garanciat az adatok integritasara sehol nem vallalnak (nem 1 olyan esetem volt, ahol backupol kellett egy DB-t visszarangatni, mert nem elt tul egy komolyabb HW failure-t). A replikacio szinten jo dolog, de az se teljesen valos ideju (ergo ott is siman elofordulhat adatvesztes, bar ott legalabb az adat konzisztenciara rendesen figyel a DB)
Ez mellett meg szamold azt is bele, hogy mi most backuprol beszelunk (nem pedig data replication-rol), ahol -szerintem- nem elfogadhato az, hogy normalis futas eseten (esetleg) adat veszhet el. Igen is legyen minden konzisztens es legyen meg minden a helyen. Az szamomra nem elfogagadhato, hogy talalsz olyan setupot ahol 100-bol 99x szepen lefut minden, mert ha csak 1x belefutsz abba az 1%-ba, es pont akkor borul meg a geped, akkor onnantol lehet kukoricara terdelni..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Alapvetően én arra válaszoltam, hogy bizony az OS+DB ügyel arra, hogy konzisztens legyen alatta az adat. Ebben egyetértünk. Tehát backupra jónak kell lennie a snapshotnak is.
Adatvesztést nem úgy értettem, hogy random helyen hiányzik valami, hanem hogy esetleg az utolsó néhány tranzakció hiányozhat, ha azt az OS/DB nem írta még ki. Egy időzített (mondjuk napi) backupnál mindegy, hogy a konzisztens adat pár millisec-kel korábbi állapotot tükröz-e, csak konzisztens legyen...

Vagy elbeszélünk egymás mellett, vagy valami nem ment át: Az ok, hogy az adat konzisztenciájára ügyel a rendszer (journaling, tranzakciós logok, meg amit akarsz), de ezt az állapotot nem tartja fent folyamatosan (hanem csak időnként kieszközöli a konzisztenciát), ergo te nem tudsz 100%-os biztonsággal megbizonyosodni arról, hogy az snapshot pillanatában az adat valóban konzisztens e (általában nem, főleg azon esetekben ahol a DB maga manageli az adatot). Ezért is mondtam, hogy a backup solution-nek feladata ezen konzisztencia kierőszakolása (DB2 esetén a SET WRITE SUSPEND, Oracle DB esetében meg az ALTER SYSTEM SUSPEND parancsok valók erre; LVM esetén ott a snapshot, Filerendszer esetén meg az fsfreeze). Miután ezekkel a parancsokkal biztosítottad a konzisztenciát, utána már egy KVM szintű snapshot valóban működhet (persze azért egy sync is kelleni fog a kliens oldalon, ha biztosra akarsz menni), de ehhez a kliens VM-el közösen kell ezt a bulit levezényelni, nem pedig annak tudta nélkül.

szerk: helyesírási hibák javítva
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Szerintem meg Neked nincs igazad. Mint már írtam: egy OS/FS/DB kötelessége olyan módon kiírni az adatot a (virtuális) adathordozóra, hogy az bármilyen pillanatban recoverezhető legyen egy konzisztens állapotra. Ha ez nem így volna, akkor az összes adatreplikációs/snapshot megoldás kukázható lenne. Úgy tudom IBM-es vagy, ezért onnan hozok példát: egy DS8000/XIV/SVC/Storwize Metro vagy Global Mirror nem tud az OS/FS/DB lelkivilágával foglalkozni, csakis a diszkre kiírt adatot viszi át egy másik site-ra azért, hogy ha a primary site tetszőleges időpillanatban lehal, akkor fel lehessen éleszteni az alkalmazásokat a túloldalt. Az egész mirrorozás arra épül, hogy a storage-on lévő adat _minden_ időpillanatban konzisztens (vagy konzisztens állapotra hozható), nem csak alkalmanként, ahogy Te állítod.

Adatbázisok esetén azért jó ha flusholunk + leállítjuk az írást a snapshot idejére, hogy gyorsabban indulhasson a DB, mivel nincs szükség hosszadalmas recovery-re. De ez nem azt jelenti, hogy azok használata nélkül haszontalan lesz a mentésünk.

Megint kevered a szezont a fazonnal.. Mint már előzőleg írtam, nem data replication-ről beszélünk, hanem backupról. A data replicationnél is ugyan ay a helyzet, mint az OS oldali adat-konzisztencia elérésénél: Nem garantál neked adat konzisztenciát bármelyik pillanatban. Ahogy mondod, a SAN nem törődik a klienssel, nem is kommunikál vele, így nem is képes az adatkonzisztenciáért felelősséget vállalni (ettől persze még recovery stratégiát lehet építeni rájuk, vagy esetleg GEO-mirrort/dual-site solution-t). Amúgy pont a DS8k/XIV/SVC/Metro-Mirror-al napi szinten foglalkozok is, és mindegyiknél a kliensel kell összeszinkronizálni az adott activity-t HA az backupra akarod használni (konkrét backup strategy például így épül fel: DB2 betolja a suspend write-ot, JFS2 rátolja az FS freezet-t, majd a kliens visszaszól, hogy részemről ok, és csak akkor kezdi el a DS8K a flaschopy-t, majd amikor az lefut (az már snapshot alapú így az gyorsan megvan), akkor a kliens gép szépen elereszti az FS freezt (thaw), és visszaállítja a normál DB2-s működést)

szerk: Alternatíva, hogy felpakolsz egy Tivoli Flashcopy Managert, ami kb pont ugyan ezeket a lépéseket fogja neked végig csinálni a kliens, a target és a SAN oldalon.

Amúgy a definiciód alapvetően ellenkezik a backup-al is:
A backup nem egy "konzisztens állapotra hozható" mentés, hanem egy konzisztens mentés és pont. Ha a te backupod egy rendszer visszaállítás után nyomban fsck-val indít, az számomra nem backup.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Na és a DS8k Global Mirrorjában lévő (néhány másodpercenkénti) FlashCopyhoz hogyan készíted fel az OS/DB-t? Sehogy. Csak abban bízhatsz, hogy az adat konzisztensé tehető vhogy (fsck, DB recovery, stb.) utólag. Sok cég ilyet használ Disaster Recovery gyanánt, csak van benne vmi ráció.

Persze, ha van rá mód, akkor legyen "tiszta" a backup. Nyilván.

Backuphoz? Sehogy.. Amit írtam az egy backup solution.. Amit te írsz az data replication.. Disastre Recoveryhez tökéletes (bár ott is elképzelhető, hogy additional backupra kell támaszkodni), backuphoz kevés (remélem a RAID1et/LVM mirrort se tekinted backupnak)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

tekint a snapshot adatokra ugy mint egy nemvart poweroff esten levo disk allapot (pl virsh suspend helyett virsh destroy). ha ilyen poweroffbol ossze tudja magat vakarni az os/fs/db/akarmi, akkor a snapshotbol is fel tud allni.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Áruljátok már el pls, hogy egy full risk free-re tervezett solutionhöz (backup) miért is kéne egy risk assessmentet csapni, hogy aztán elbírálhassuk, hogy az elkészült backupból vissza tudom e majd állítani azt a file-t amin épp dolgoztam (akkor amikor a backup készült)?

Bonusz pontért hülye use-case scenario: Tegyük fel azt, hogy az én rendszerem Ramdrive-ról fut, amit aztán saját megoldásokkal nap végén (a shutdown részeként) újracsomagolok (azt akár virtdiskre is menthetem), és a legközelebbi alkalommal arról bootolok be (ha közben elhasal a gép, akkor azt elfogadom, max az előző órai kliens oldali inkremental backupból visszaállok - az még belefér az SLA-mbe). Erre kaphatnék alternatív backup strategy javaslatot ami kliens független?
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Szoktam ilyeneket építeni, működik, de azért nagyon észnél kell lenni.

1. Az adatbázisoknak logolt módon célszerű futnia (archivelog, binlog, etc)
2. Csak tranzakciós adatbázisokra működik megbízhatóan
3. A leszakadás utáni állapot gyakorlatilag megegyezik azzal mintha kirúgtad volna a tápkábelt. Induláskor egy böszme nagy rollback indul meg, és visszaáll az utolsó ismert konzisztens állapotra. DB szinten konzisztens lesz a dolog, de ugye létezik az "üzleti konzisztencia" fogalma, aminél pl egy csatlakozó rendszer bedobta a feladatot, el is könyvelte hogy kész, ugye utána az meg eltűnik a DB-ből. Innentől a két rendszer szinkronja szétszakad (beteg példa, mert ilyet csak rossz programozó követ el, de sajnos előfordul).

( Kronosz v | 2014. 11. 10., h – 20:29 )

Egyik kedves kolléga után szabadon:

http://relax-and-recover.org/

Ezt használom, cégnél proxmox saját backupját.
A rear-t azért szeretem, mert futó gép mellett képes konzisztens mentést csinálni, többször megmentette már az életem.
________________________________________________
http://kronosz.krocomp.hu

root@venus:~# cat /etc/rear/local.conf
# Create Relax-and-Recover rescue media as ISO image
OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL="nfs://192.168.0.24/data/backup/"

root@neptunus:~# cat /etc/rear/local.conf
# Create Relax-and-Recover rescue media as ISO image
OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL="nfs://192.168.0.24/data/backup/"
ONLY_INCLUDE_VG=( neptunus )

Azt nem tudom milyen trükköt alkalmaz, soha nem néztem, de több éles tesztet végrehajtottam, mire az itthoni szervereimen belőttem véglegesen. mindig visszahúzta a gépeimet, LVM-et használok majdnem az összes szerveremen, egyre nem tettem LVM-et, az az első konfig, második példa az LVM-es, ott ki lehet include-olni, hogy melyik LV-t akarod csak menteni.
Úgy működik, hogy a 0.24 nekem a "storage", oda ment el egy 32 megás iso-t, ami egy bootolható iso, vész esetén erről kell bootolni, indulás után beírod, hogy "rear recover", és már húzza is vissza image-ből a gépet, illetve oda menti magát az image-t tar.gz "formátumba". Mentésre én egy scriptet írtam, heti egyszer lefut, majd küld egy mailt, hogy sikeres volt-e a backup, vagy sem.
________________________________________________
http://kronosz.krocomp.hu

Igen, így van. A kliensről futtatod. Teljes gépet ment, mindent, de tudod definiálni, hogy milyen LV-t szeretnél csak. Ha van külön datalv-t azt nem szeretnéd betenni gondolom system backupba, hanem inkább rsync-es mentésbe. Egy 32 megás bootolható isot és egy .tar.gz filét csinál és felmásolja egy adott helyre, amit megadsz.

Bocs, hogy csak most reagálok, nehéz és fájdalmas napom volt ma :D

Semmi gond! Inkább én köszönöm a segítséget!! Eddig tényleg jó.

A teszt eddig sikeres. :)
A "yum install syslinux cifs-utils" kellett még.

# /etc/rear/local.conf

OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL="cifs://192.168.1.104/data/backup/"
BACKUP_OPTIONS="/etc/rear/.cifs"

# /etc/rear/.cifs

username=felhasználó
password=jelszó
#domain=tartomány

A "sudo rear -v mkbackup" szépen megcsinálja a hostnév könyvtárba a mentést:
README
VERSION
backup.tar.gz
rear-centos7.iso
rear.log

A "sudo rear recover" meglátjuk mit produkál.

--
G.

A 32 megás iso-ról bootolj, és azon add ki csak a ream recover-t. Utána ha elindul és ha teszt gép, töröld ki mondjuk az egész /usr-t, vagy a /etc-t, aztán úgy próbáld ki a restore-t. Ha úgy is megy, akkor a saját szemeddel látod, hogy megy. :D

________________________________________________
http://kronosz.krocomp.hu

Egy apró bibi van a backup-al. Otthon ment simán samba4-el. Most egy samba3-as megosztásra kellene készítenem a backup-ot, de hibát ad:

# rear -v mkbackup
Relax-and-Recover 1.16.1 / Git
Using log file: /var/log/rear/rear-backup.log
Password for root@//192.168.1.254/backup-rear/: *****
ERROR: Mount command 'mount -v -o /etc/rear/.cifs //192.168.1.254/backup-rear/ /tmp/rear.6ISwttdRvDxhJMx/outputfs' failed.
Aborting due to an error, check /var/log/rear/rear-backup.log for details

# A mount paranccsal van gondja:
# mount -v -o /etc/rear/.cifs //192.168.1.254/backup-rear/ /mnt/smb/
Password for root@//192.168.1.254/backup-rear/: *****
mount.cifs kernel mount options: ip=192.168.1.254,unc=\\192.168.1.254\adatok,/etc/rear/.cifs,user=root,prefixpath=backup-rear/,pass=********
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Az /etc/rear/.cifs-ben:

username=myuser
password=**********

Samba3 esetén hogyan kellene mountolnia?

--
G.

Itthon virtuális gépben próbáltam a visszaállítást (VirtualBox). Végülis sikerült, de azért nem egészen úgy, mint a honlap videoján. :) Persze attól még sikerült.

Szóval a host gépemen van egy samba4, ez volt megadva a virtuális gépnek, hogy oda mentsen.
A mentés után csináltam 1-2 módosítást a VM-ben (centos7), van egy MySQL adatbázis is, amibe adatokat szúrtam be... stb.
Majd az egész /usr könyvtárat töröltem. Már a leállítás sem volt egészen működőképes, tehát egy rendszerösszeomlást szimuláltam. :) Egyszerűen le is kapcsoltam a VM-et, szabályos leállítás nélkül!

A rear által készített boot ISO fájlt felcsatoltam a VM-nek, hogy arról bootoljon. Volt két menüpont a boot menüben, az "automatikus rear rcover" nem működött, a manuális meg adott egy parancssort.
Itt adtam egy "rear recover" parancsot, de a samba mountolás nem működött, mert az /etc/rear/.cifs fájlt nem találta, amiben a samba elérés jelszava volt. Nem baj, kézzel létrehoztam:

username=sambauser
password=sambapassword

Ismét "rear recover" kiadva és 1-2 dolgot akart kérdezni, de C) opciót választottam, hogy "Continue Recover". Kb. 5 perc után ujraindult, majd a boot menüben nem indult a CentOS7. Viszont ebben a visszaállított boot menüben volt egy "rescue..." menü, az dolgozott szorgalmasan 0... 100% és után a reboot. Ekkor már gond nélkül elindult a centos7-em.

Szóval ki kell tapasztalni még ezt a rear-t, de az elmentett állapotot szépen visszaállította! Sőt a MySQL adatbázisom is ugyanabba az állapotba került vissza! :)

Újra fogom tesztelni még párszor!

--
G.