Hyper-V VM disk "block" különbözeti másolat -> ZFS backup

Microsoft Windows

Lenne egy érdekes HyperV Backup 5letem, kíváncsi lennék mások véleményére.
Leszögezném az elején, Windows/HyperV szakmailag távolabb áll tőlem, láttam már mindegyiket, dolgozom is velük, de ennyi.

Proxmox alatt több éve használunk megbízhatóan egy nagyon „egyszerű” backup megoldást.

  • VM-ek ZFS storage-en futnak.
    Windows, Linux, QEMU, LXC konténer, tök mind1.

  • QEMU alatt minden VM-en kötelezően fut qemu-agent

  • backup script igénytől függően:
    - leállítja az adott VM-et, és készít róla egy snapshotot-ot

    - simán készít egy snaphot-ot futó gépről
    - snapshot előtt futó gépen lefuttat X scriptet (SQL backup, SQL disk írás stop, etc …), snapshot, majd újra script VM-en ha szükséges

  • Az elkészült online/offline snapshot-ot (ami egy ZFS snapshot) egy ZFS send/receive -el elküldi backup gépre.

  • Paraméterek szerint Host oldalon törli X db snapshotot, tehát beállítható hogy Proxmox oldalon mennyi aktuális snapshot legyen, ha nagyon helytakarékosak vagyunk, akkor akár egy sem

  • Backup oldalon szintén töröljük az X időnél, vagy N darabnál régebbi snapshotokat

  • Ez az egész backup gépen fut, úgy hogy backup gép proxmox cluster része, így proxmox kulcsokkal bárhova be tud lépni.

  • Ehhez vannak még felügyeleti script-ek amik a backup integritását ellenőrzik.

Ebben a megoldásban az a jó hogy incrementális, block mentés készül, tehát a lehető legkevesebb a másolt „adat”, és teljesen megbízható.
Ha kell akár windows, akár linux VM/konténerből egy mount-al elővehető bármilyen fájl, bármelyik napra/órára amikor van backup. Ha VM restore kell, egy ZFS send/recevive-el vissza lehet állítani a VM-et, tehát csak a hálózat sebessége befolyásolja a visszaállítási időt.
Offline mentésnél teljesen konzisztens, online mentésnél is az ha SQL, etc ...-ra oda figyelsz.
Backup gépen csinálhatsz pl. heti 1x ZFS-ről egy exportot fájlba, és rakhatod egyéb (HDD, szalag, etc ...)-ra.

De nagyon sok helyen használunk Hyper-V-t, és igen tudom nagyon sok jó, szép backup megoldás van HyperV alá, de powershell-nek hála már windows alatt is elég jól lehet scriptelni.

Kíváncsi lennék a fentihez hasonló HyperV-s megoldás vajon készíthető lenne-e, kihasználva ZFS rugalmasságát.
Mivel HyperV alatt storage réteg nem ZFS, ezt sajnos block szinten nem lehet megoldani, de vajon VSS v. HyperV Snapshot + fájl copy-val nem lehetne megoldani?
Az esetek nagy részében hyperV VM sima fájl, azt nem lehet valamilyen normális (incrementális) módon snapshotolni, és megbízhatóan másolni? Tehát mindig csak a különbözet menjen át backup oldalra. (ehhez kéne ugye block szintű copy)

  • 440 megtekintés

( gyuri23 | 2020. 04. 15., sze – 14:38 )

sub

Ez engem is érdekel, mert van pár HyperV gépem. Én powershell mentést írtam hozzá, de az exportál és utána másol, a csak snapshot másolás tényleg jó megoldás lehet. Már ha működik...

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

( tompos v | 2020. 04. 16., cs – 12:20 )

Nem nagyon porog ez a topic.

Szoval mit szeretnel?

Vegig ZFS-sel beszelsz, de aztan kerdest megsem arra teszel fel. Szamomra nem vilagos, mit szeretnel megtudni.

( quash | 2020. 04. 16., cs – 14:19 )

Lehet hogy nem voltam eléggé egyértelmű, és inkább a működő Proxmox-os megoldást részleteztem ki.

Szeretnénk Hyper-V alá (az hogy ez most single gép, vagy cluster, etc … tök mind1) a topic elején vázolt Proxmox-on kiválóan működő backup megoldást készíteni.

Tehát nagyon leegyszerűsítve a következőt szeretnénk:

  • HyperV-n futó VM diszket (ami egy fájl) átmásoljuk egy ZFS-re, az egyszerűség kedvéért legyen offline a VM.
  • majd erről a diszkről bizonyos időszakonként szeretnénk egy újabb másolatot küldeni ZFS-re, de úgy hogy csak változások mennek át. Tehát a másolást végző eszköz kb. block eszközként kezeli a VM disk-et, és csak a változott block-okat másolja át.
  • minden másolás előtt készül egy ZFS snapshot, ezzel elérjük azt hogy N db időpontban másolatunk van a ZFS-en adott disk-ből.
  • a fentiek miatt egy pl. 500Gb-os VM-et nem kell minden backupnál átküldeni a hálózaton, és nem kell backup oldalon N x 500Gb helyet elhasználni.

Ezt az egészet jó lenne még megfejelni azzal hogy nem csak offline gépet lehetne így másolni, hanem online gépről készült snapshot-ot átküldeni.
Első körben csak arra kellene koncentrálni hogy lehetséges-e bármilyen módon HyperV VM diszkről „block szintű” különbözeti copy-t készíteni. Ha ez megy, a többi már adja magát.

Át is neveztem a topic-ot, így talán érhetőbb!

Jobb lenne, ha valaszt nyomnal, h maradjon thread a thread.

 

Meg mindig nem vilagos.

Atmasolod a VM image file-t ZFS, majd azt snapshotolod es kuldod a backup szerverre? Hol lesz ebbol inkrementalis mentes? Ugyanugy at kell mindig kuldened a full VM-et.

 

Ha jol ertem, amit szeretnel, szerintem kb. ketfelekepp lehet kivitelezni.

1. Tartasz vmi nativ eszkozzel keszitett replikat egy zfs-en es azt snapshotolgatod.

2. ZFS-en vannak mar eleve az image file-ok, amit aztan snapshotolhatsz

 

Valoszinuleg jobban jatsz az egesszel, ha vmilyen nativ modon csinalsz inkrementalis mentest.

Pl. ugy, h nem hasznalsz hyperv-t.

Huh! :(

Fogjuk az offline géphez tartozó VHD(x)-e(ke)t és átmásoljuk pl. egy ZFS share-re.
Ezzel lett egy „backup”-unk a teljes offline gépről.
X idő múlva készítünk egy snapshot-ot a VM-ről (offline/online most tök mind1).
Ehez a snapshot-hoz tartozó VHD(x)-t valamilyen tool-al „átmásoljuk” a backup gépen lévő VHD(x)-re. A tool-nak az lenne a feladata hogy csak a két VHD közötti különbséget másolja, ezért kell pl. valamilyen block copy ami képes ezt elvégezni. Ezzel a „másolással” csak a változások mennek át, tehát kapunk egy gyors megoldást.
Ehhez ZFS annyit rak csak hozzá, hogy backup oldalon azzal kezeljük a snapshotokat, tehát copy előtt v. után készül egy snapshot, és máris van egy helytakarékos backup megoldásunk.

Nem akarjuk feltalálni a spanyolviaszt, nagyon sok backup tool ezt a megoldást használja, csak jellemzően a gépeken belül végzi a block szintű másolást VSS alapokon.
De mennyivel 1xübb lenne ezt hypervisor oldalon megoldani, mint ahogy pl. ZFS alapú virtualizációknál (proxmox) ez csuklóból megy.

Nem más megoldást keresünk, tehát a csináld máshogy, és használj másik hipervisiort nem megoldás, ezzel nem segítesz!

Azure-ben már van ilyen megoldás, de az ott lévő storage-re, tehát biztos hogy Hyper-V is valamilyen szinten képes erre.

Meg mindig nem 100%-osan vilagos, mi a zfs szerepe itt. Ha jol ertem, a snapshotot mindig atmasoloda backup gepre es azzal egy aktualisan uptodate image file-t kapj, majd azt snapshotolod.

OK, feltehetoleg mukodik, habar egy kicsit serulekeny megoldasnak tunik.

 

Szoval meg mindig ott tartunk, h mi a kerdesed?:)

Nos, úgy nézem másnak átjött mi a kérdés …

Azt áruld már el hogy ez pontosan mitől is sérülékeny???
Egy VM image-et átmásolsz szabályosan, majd, szintén szabályosan utána küldöd a másolás óta megváltozott block-okat.
Tehát megkapod a cél helyen, az eredeti helyen lévő image másolatát, úgy hogy csak a változásokat másoltad át.
Ez mitől sérülékeny?
Ez egy sima különbözeti másolat block szinten.
De természetesen ezt is lehet a biztonság kedvéért ellenőrizni, a VM image-ban ott van minden block-hoz tartozó CRC érték, a másolaton napi 1x végig lehet szaladni, a block CRC értéke tényleg egyezik-e a tárolt értékkel.

A kérdés pedig az, hogyan lehet Hyper-V image-el különbözeti másolatot csinálni block szinten.
Ahogy lent leírták, amit keresek CBT (changed block tracking) copy Hyper-V image-hez.

Ez annyira sérülékeny, hogy egy csomó ismert, megbízható backup megoldás is használja (Veeam, Nakivo). Már csak azt kell megtudni hogyan …

Olyan jó lenne ha emberek nem azzal töltenék a szabad idejüket hogy belekössenek valamibe, hanem megpróbálnának érdemben hozzászólni! Vagy kioktatni hogy hova szóljak hozzá ...

Szerintem ne kavard össze a dolgokat. Ha menteni akarsz rendesen Hyper-V alól, akkor példul a Veaam Backup & Replication-t nézd meg, 10 ütemezett feladatig a Community Editionnel simán elketyegsz és valszin messze könnyebb visszaállítási metódusod lesz, mint egy ilyen belehekkelt ZFS-es sztorival. Értem, hogy szeretnéd a ZFS-t és kinézted magadnak ehhez is, de én a magam részéről az adott környezetbe illeszkedő megoldást választanék.

( zwei | 2020. 04. 16., cs – 16:00 )

Blokk szintű inkrementális mentéshez CBT (changed block tracking) kell, amit nem tudom támogat -e a hyper-v.

Ha a vhdx-ek alatt ntfs van, akkor megpróbálkozhatsz annak a shadow-copy-jával, bár gőzöm sincs hogy lehet shadow-copy-ból kimásolni a vhdx-eket, és hogy mennyire lesz konzisztens.

Szerintem a biztonsági mentés nem az a műfaj, amit házilag készült bonyolult scriptekkel kell megoldani. Ha már saját megoldással ment az ember, az legyen egyszerű mint a faék.

Ha a sima, windows szerver beépített backupjával, ZFS (samba)share-re mentesz, és azt snapshotolod, elvileg (és jobbára gyakorlatilag is) a kívánt eredményt kapod. Mondjuk a hálózaton átviszi a teljes cuccot, viszont a tárolás inkrementális lesz, mert a nem változott blokkok nem foglalnak el extra helyet a zfs snapshotokban.  (és pofon egyszerű a visszaállás belőle. ISO boot, és restore from backup)

Igen CBT, most már tudom hogy hívják :D

Alapvetően ha működik ez olyan 1xű mint a faék, mindig csak utána küldöd a változásokat.
Annyival érdemes megtámogatni, hogy a backup oldalon lévő VHD-ket, pl. napközben lehet validálni checksum alapján (minden block checksum = tényleges érték?), erre azt hiszem tool is van. Ha az is OK, akkor nincsen benne hibalehetőség.

( ricpet | 2020. 04. 16., cs – 16:09 )

Azon is el lehet gondolkozni, hogy nem volume szintről közelíted meg a kérdést, hanem csak különbözeti vhdx file-okat másolsz. Amikor készítesz VM snapshot-ot, akkor a .vhdx úgymond lefixálódik, és amíg létezik a snapshot, nem is változik. Minden írás a VM-ben egy különbözeti file-ba megy, lényegben csak a megváltozott blokkok. És ilyen módon minden nap csak az új különbözeti file-okat kell másolnod. Ha megvan backup-ban az alap vhdx és az összes különbözeti file, akkor bármikor elindítható a VM.

Itt a problémát az okozhatja, hogy egy idő után túl sok snapshotod lesz, és azokat illene törölni. Snapshot törlésekor viszont az alap vhdx már nem marad fix, visszamergel minden változást a különbözeti file-ból, és törli a különbözeti file-t. Tehát ilyenkor újra backup-olni kell az alap vhdx-et is.

Mindenesetre némi gondolkodást megérhet, hátha alkalmazható a te esetedre.

( quash | 2020. 04. 17., p – 09:37 )

Csak hogy a trollkodáson kívül legyen érdemi hozzászólás is.

Úgy néz ki nativ módon CBT vagy hasonló block szintű másolást nem tud/támogat Hyper-V, és hivatalos tool sincsen hozzá. (vagy még nem találtuk meg)

Van egy elsőre teljesen járhatónak tűnő alternatív megoldás.
VHD(x)-ekhez lehet mergelni snapshotot:

https://www.nakivo.com/blog/merge-hyper-v-snapshots-step-step-guide/

PS-ből is elérhető.

Ezt kicsit jobban körüljárjuk.

A kettő nem u.a.!

Te azt írtad hogy másoljuk el a Hyper-V snapshotokat, tehát backup oldalon lesz N db snapshot fájl + az "eredeti" fájl.

Merge-nél az eredetihez hozzá adod a snapshot fájlt, tehát a cél oldalon egyetlen fájl képződik! Ami nem tartalmaz snapshotot!
Tehát a visszaállításkor nem kell Hyper-V snapshotokat kezelni, 1xűen visszamásolod az egyetlen VHD-t és kész.

Snapshotok kezelését backup oldalon FS szinten oldjuk meg, tehát minden merge előtt készül egy ZFS snapshot. Ha elő kell venni 5 nappal ezelőtti backupot, 1xűen mount ZFS snapshot, és ott az egy darab 5 nappal ezelőtti konzisztens VHD.

Ez kb. az amit kerestünk, hiszen VHD merge az előző és az aktuális állapotot összerakja egy fájlba úgy hogy elvileg csak a különbözetet fogja mozgatni hálózaton.

( debtamas88 | 2020. 04. 18., szo – 00:00 )

Szia!

ZFS alapú ISCSI diszket adsz a Hyper-V -nek.
SQL-t menteni snapshottal nem jó megoldás, ott SQL alatt a full-tranzakció loggolást be kell kapcsolni - különben érni fognak furcsa meglepetések visszaállításkor.

Igen, SQL, DC, kerberos, etc ... egyiknek sem jó, ha nem tud arról hogy éppen snapshotolják. (de többségnek lehet szólni)
SQL-ekről mindig külön készítünk dump-ot, már csak azért is mert abból táblák is egyszerűen, gyorsan visszaállíthatóak, nem csak az egész DB.

ISCSI nagyon jó lenne, de az külön hardver, bejön a hálózati réteg, sebesség, etc ... Illetve ott ahol storage-van, ott szintén nem játszik.

CBT lenne a legjobb, érdekes mert Hyper-V Azure-ban tudja, tehát csak az a kérdés hogy "normál" környezetben hogyan lehet használni, illetve milyen Hyper-V verziótól létezik.
De erre egyenlőre csak információ morzsákat találtunk.
VHD merge is kb. ez, még nem teszteltük le.

Illetve ami még érdekes lehet VSS oldalról megközelíteni a dolgot, ezt is nézzük még.

Esetleg próbáld meg a wimlib-et ( https://wimlib.net/ ), tud VSS snapshotot. Deployment mellett használtuk backupra is (1 év napi mentései kerultek 1 WIM fájlba).
* VSS snapshot support. On Windows, wimcapture or wimappend with the --snapshot option will automatically create a temporary VSS snapshot and capture the image from it. This can be used to image a "live" Windows system.

--
Légy derűs, tégy mindent örömmel!