[Szakmai] TIL: Már van Proxmox VE támogatás a Veeam-ben

Még nyáron lamentáltunk arról, hogy jó a Proxmox, szuper, de amíg nincs hozzá egy rendes mentési megoldás, addig szóba se jöhet sok helyen. Akkor már voltak hírek arról, hogy a Veeam roadmap-jént ott a Proxmox VE támogatás, de pontos kiadási dátum nem volt. Viszont a kezembe került a Veeam Community Edition 12.2-es verziója és örömmel láttam, hogy már élesben használható a Proxmox támogatás:

1   3

Hozzászólások

Hát, vzdump-nál maradok inkább, heti 4x 4 fizikailag is külön helyre.

Azért a Veeam egy kicsit más kávéház.

Ahol vegyesen kell VMware, Hyper-V, fizikai szerverek és most akár még pluszban Proxmox infrát _is_ (pl. átmenet egy VMware -> Proxmox irányba akárcsak teszt jelleggel) üzemeltetni, ott kell egy közös nevező, amivel mindegyikbe belelátsz mentésileg és tudod is ipari standardok (CBT stb.) szerint menteni. Mivel ezek a mentőmegoldások nem két forintba kerülnek, nem biztos, hogy az az irány, hogy mindegyikből tartasz egyet. Ráadásul az adminisztrálásuk is több helyen csak az overhead-et növeli.

A Veeam eddig is a #1 mentési megoldás volt ilyen helyeken, de ezzel a lépéssel már jobban elhúzott a követőktől.

F1-es hasonlattal élve vezeti a futamot és a másodiknak adott fél kört.

trey @ gépház

Tudom, használunk Veeam-et, igaz már csak DR oldal kezeléséhez. Mielőtt nem migráltunk Netbackup-ra, akkor a Veeam-ről mentek az OS mentések is Vmware-en. Proxmoxaink már nagy sajnálatomra csak pár darab van, azok is infra sandbox gépek, melyeket simán vzdump-al mentjük.

Itthon szinte csak Proxmoxaim vannak, azokra tökéletes a vzdump, bár nagyon ajánlották a Proxmox Backup termékét is, ami nekem ágyúval verébre. Cégnél nem tervezik a Proxmox komolyabb bevetését, helyette kényszerből OLVM-et kell majd az Oracle szaroknak használni, többi vm pedig marad Vmware-en. Ezeknek közös nevezője nálunk mentés oldalról a Netbackup, melynek szintén meg van az oka, hogy miért lett lecserélve.

Ebből kimaradtam, mert a dbadminok és az architect-ek jutottak arra a döntésre, hogy átállnak. Szerintem a licensz ára volt inkább a döntő, egyszerűen a Netbackup olcsóbb. Illetve van egy nagy OVM clusterünk, állítólag az országban a legnagyobb, amit a Netbackup képes menteni meg snapshotolni. Ez manapság nem tűnhet nagy dolognak, de az OVM-et aki ismeri, az tudja, hogy mennyire elavult pusztulat... De a Netbackup kipróbáltan és üzembiztosan tudja menteni. Nem ez a tény volt szerintem a döntő, hanem mint említettem az ára.

Hát, az OLVM legalább van, szemben a RedHat EV-vel, amit ugye beszántottak és kb. tesztpilótát csináltak a fizetős ügyfelekből mondván h. az OpenShift ezt is tudja. Jah. Kubevirt-hez tákoltak valamit az OKD nevű sz.rban, de kva messze van az enterprise virtualisation-től. Oracle legalább tartja a támogatott oVirt-et a termékpalettán.

Ahol azon túl is számít a dolog h. mennyire punk a megoldás (értsd licenselhetőség, support, stb.), ott az OLVM nem is olyan szar alternatíva, hiszen a sima OracleLinux supportban kapod a támogatást és nem kell még proxmoxot v. vmware-t is vásárolni.

Nekem ez annyit mond (Proxmox Backup-ot használunk mindenhol jelenleg), hogy a Proxmox tényleg szintet lépett (üzletileg, ismertségben, stb.), és képbe kerül olyan cégeknél is, ahol a Veeam már jelen van, így igény jelentkezett a Veeam támogatásra. Nyilván nem a homelabberek kedvéért került bele ez a támogatás, hanem a fizetős ügyfelek igényei alapján. Szerintem ez jó dolog.

Sokan a Proxmox gyengéjének tartják, hogyha 2-3 gépes clustert akarnál, hogy ezeken fut a shared storage is, akkor erre nem ideális, production szinten. A Vmware Vmfs szintű megoldás nem volt régebben a Proxmoxhoz. Proxmox esetén a Ceph nem ideális 2-3 gépnél még mindig? Ott az Nfs vagy Drbd, ezekből vagy másból lett Vmfs szerű alternatíva már? Vagy van tervbe véve? Kérlek aki képben van ossza meg, hol tart ebből a szempontból a Proxmox a gyakorlatban. Hány gépes clustertől szokás élesben használni, shared storage használattal azonos gépeken? Vagy mi mást szoktak 2-3 gép esetén, ami free? Thx.

Csak 3+ gépes cluster a támogatott (már ha a HA clusterre gondolsz) és a 2 gép amin még storage is van, azt én nem annyira nevezném production szintnek. Úgyhogy ez nem a gyengéje, csóróknak ott van a replikáció.

Asszem Trey szokta mondogatni, aki majmot akar, annak legyen pénze banánra.

Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.

Ceph 3 géptől működőképes érdemben, replikációval (ahogy a Proxmox HA is 3 géptől HA). Erasure Coding esetén (RAID 5-6-hoz tudnám hasonlítani a működést, jobb helykihasználás mint a replikációnál) 7 node az indulási alap.

Mi használunk élesben 3 éve egy 4 node-os Proxmox-Ceph HCI rendszert, eddig semmi baj nem volt vele. Pont nemrég írtam le valami bejegyzés alá, hogy az élő, futó rendszert futó VM-ekkel hogyan frissítettem Proxmox 6-7-8 és Ceph 15-16-17-18 verziókra, probléma mentesen. A mentése a kezdetektól Proxmox Backup Server, azzal sincs gond.

Természetesen a replikációs mód miatt a tároló kapacitás bukó óriási. De ez nem a Proxmox-ból vagy a Ceph-ből fakad, hanem a tárolási módból és az elvárt megbízhatóságból. Lehetne utóbbiból engedni, akkor több hasznos kapacitás maradna, de akkor minek a HA, ha a tárolónál elengedjük. Ugyan olyan megbízhatósággal szerintem más sem oldja meg kevesebből.

VMware vSAN-nal sajna nem tud összehasonlítani, olyanhoz sose volt közöm, csak szóló ESXi telepítésekhez.

Két géphez a legjobb támogatott megoldás a ZFS replikáció, ami ugye nem szinkron, nem adatvesztés-mentes a node kiesése.
Támogatja még a GlusterFS-t, de az meg nem az igazi VM-ek alá.
Lehet kézzel DRBD-t használni, de két gépnél hogy dől el, hogy ki halt meg? Két node nem HA.

En meg varom A Dell NetWorker tamogatast, majd akkor elgondolodom rajta. A Veeam-et csak kis ,30-40 gepes infrakban hasznalunk, normalis, 7-800 gépes infrakban komolyabb cucc kell.

2024.08.28-án jelent meg a v12.2, onnantól van egy félkész Proxmox VE támogatás.

Nagy volt a nyomás, gyorsan ki kellett adni, ezért félkész, még nincs benne Instant VM recovery, File level recovery, talán még Application aware backup sem, stb. 

2024 decemberre ígérték a végleges változatot, amiben a fentiek is benne lesznek, de már ez is használható.

Az kemény.

Mondjuk nem lepődök meg, pipa szintjén sok mindent állitanak veeam-ról, aztán a gyakorlatban egy vicc.

MSSQL támogatás. Úgy hirdetik, hogy full extrás backup rá. Helyette vagy a mentett gépről(!) magad ütemezel(!) be egy tök külön program által kihányt parancssort, ami felnyomja a repository-ba a mentést, amiről aztán veeam management oldalról semmit(!) nem tudsz, mintha ott se lenne, ill. ez is pár naponta szétesett, amikor a szerver is csinált egy full backup-ot a VM-ről, mert a diff backup nem tudta lekezelni.

Hogy mondjuk eldöglött az egész bohóc-mentés és talán kéne róla központi alert? Ugyan minek. Majd felmész szépen a mentendő szerverre és megnézed mi lett a parancssoros bohózatnak az errorlevelje(!), mivel mint mondtam a központi management semmit nem tud erről, hogy itt készülne egy adatbázis mentés, igy a hiányáról sem tud.

Vagy használod Veeam server oldalról a Guest process-t, mikor is annyit tudsz beállitani, hogy hány percenként hozza el a logokat és hogy törölje vagy ne a szerverről. Hogy melyik adatbázist? Ugyan már, uri huncutság, MINDET bzmeg, ami csak létezik a szerveren, akárhány instance, akárhány adatbázisát folyamatosan menti. Természetesen ugyanazzal a schedule-al, ugyanannyi ideig megtartva stb-stb.

És ez nem egy most kijött funkció, sok év alatt jutott el idáig.

Én örülnék, ha valaki megcáfolna, hogy van normális támogatás, csak én nem találtam meg...

DPM-ről jöttem, ott természetes volt, hogy leküldöd az agent-et, megjelenik a szerver a management felületen, fastruktúrában ott látod az összes SQL instance-t, kivlasztod a mentendő adatbázist és egyenként úgy állitod be a mentési paramétereket ahogy akarod.

Gondoltam ez a minimum, de kiderült, hogy ez űrtechnika.

Nekem két kedvencem van a témában. Az egyik a natív Linux-os Veeam B&R, mióta az eszemet tudom azt nyomják a rendezvényeken és workshopokon, hogy de most már mindjárt itt van! (És ezt először 2010-ben hallottam :D).

A másik a rest API-juk, ami nem kezeli a tape és replication jobokat.

MSSQL támogatás. Úgy hirdetik, hogy full extrás backup rá. Helyette vagy a mentett gépről(!) magad ütemezel(!) be egy tök külön program által kihányt parancssort, ami felnyomja a repository-ba a mentést, amiről aztán veeam management oldalról semmit(!) nem tudsz, mintha ott se lenne, ill. ez is pár naponta szétesett, amikor a szerver is csinált egy full backup-ot a VM-ről, mert a diff backup nem tudta lekezelni.

Plusz egy PostregSQL support is jól jönne, mert az általuk javasolt "Pre-Freeze and Post-Thaw Scripts" használata a konzisztens mentéshez is leginkább csak egy vicc.

trey @ gépház

Szerintem 10+ éve nem láttam VSS-related problémát, ott valami más probléma is lesz. Számtalan MSSQL-t mentek Veeam-mel, Barracuda Backup-pal, CA ArcServe-vel, Windows Backup-pal, megy szépen az összes hiba nélkül application-aware módban. A tranzakciós logok megfelelő truncate-je mellett, ofkoz.

trey @ gépház

Igen, láttam ilyet, olyan képzett üzemeltetőknél, akiknél az ajánlásokkal ellentétben nem célszerverek voltak, hanem egy szerverre összehányva minden:

  • célszerver -> MSSQL szerver
  • összehányt szerver -> egy helyen AD, EXCH, MSSQL (billió instance), Sharepoint, fájlszerver és még a holdkóros fasz is :D

Mondjuk ez kb. akkor szűnt meg, amikor a Microsoft is belátta, hogy az SBS terméke, ami ezeket role-okat egy szerverre (később min. kettőre) szórta fel, egy saját lábon lövés. A VSS writer-ek meg nem győzték követni a hülyeséget :D

Na, ez kb. 10+ évvel ezelőtt volt. Azóta nem nagyon láttam ilyen frankenszervereket. :D

trey @ gépház

semmi frank nem kell ehhez, csak tobb vss backend. amibol a win alapbol ad egyet, mssql megegyet, backup SW (veeam) megegyet, hypervisor pedig neha beszol, h haver, FS freeze! :) aztan jol osszeakadnak. itt konkretan csak egy koszos sql szerver van a gepen kb. 100G ram, parszaz GB DB. w2022, alig fel eves install. szoval a frankenszarozasod nagyon melle ment :) de good try! :D
reboot X ideig gyogyitja, ahol X randomgeneralt :)

jajajajaja! kosz a helpet! mi is a help? a nagy lof*sz? :D

https://learn.microsoft.com/en-us/troubleshoot/windows-server/backup-an…
tudjuk milyen az effele segitseg :) MS is megmondta: shutdown. :D ez az ajanlott hivatalos gyartoi solution :D

addig meg nincs veeam mentes. ez van. ezet mentjuk storage alrendszer szinten is, ami ugyan nem konzisztens, a semminel viszont tobb. idonkent meg megy a dump.

hint: a vss ilyen (szar). valahol nem allithatsz meg csak ugy sqlservereket kedvedre karokozas nelkul... (7/24-es uzem) :D

LOL mint említettem, SQL szerverek tucatjait mentem, legalább 4 megoldással, diszkre, szalagra, kötvetlen szalagra, CA agent-tel, Veeam agent-tel, Barracuda agent-rel, agent nêlkül, VSS writer-rel stb. gond nélkül.

Minden tetves nap, van amelyiket többször, több irányból. Pl. Barracuda telibe menti virt. gép szinten, majd az SQL agent-tel akár naponta többször, éjjel meg kipörög szalagra Veeam-mel, vagy CA-val ami offline ba megy kifele ...

Van olyan gép, amin 3 3rd party agent is fent van. Gond nélkül

trey @ gépház

jaja, nalad soha nem fordult elo == nem letezik :D ezert is van rola MS hivatalos fix: https://learn.microsoft.com/en-us/troubleshoot/windows-server/backup-an…

linkeltem is fentebb, csakhat neked nem kell azt tudni, mer' nalad mukodik! :D (itt is, amig eppen nem sikerul dupla 6-ost dobni a kockaval :D)

ms szerint es a tapasztalatok alapjan ossze szokott akadni, szerinted meg nem. eldonthetem azert kinek hiszek, ugye? :P :)

csattints csak el egy veeam vss error guglikeresest, nezd a boldog sokadalmat! :D akiknel szinten osszeakad :) 8-10 eve is, meg azota is. \o/
semmivel nem masabb az SBS VSS-e, mint a veeam VSS-e [insert random vss provider here] ebbol a szempontbol. :) pont errol a fankenstein VSS-rol beszelek az elejetol fogva! nahat! :D

Amint érinteni fog, nem keresést fogok elcsattintani, hanem egy ticket-et meg egy "hama' hama' sürge legyen meg a javítás", de mint mondtam, számtalan helyen használjuk, nem tapasztalunk ilyen hibát.

pont errol a fankenstein VSS-rol beszelek az elejetol fogva! nahat!

Én meg arról, hogy ott, ahol betartják az ajánlásokat és nem használnak SBS retkeket, ott ilyen probléma nincs. Nahát! Loop.

trey @ gépház

A konkrét hibáidat írd ide, amik a te rendszereden jelentkeztek. Tényleg kíváncsi vagyok rájuk. Teljes leírás mellett: milyen szerver, mik futnak rajta, hogyan van mentve, mivel van mentve, milyen időközönként, mi app-aware beállítások mellett, milyen load van a mentés idején stb. stb.

Ne a bohóckodást csináld :D

trey @ gépház

leirtam. osszeakad a vss, onnantol minden ilyen veeam vss request fail. neha, epp csak olyan suruseggel, hogy ne erje meg utanamenni, kidebugolni, ezzel baszakodni (megjavitani ugysem tudod, max. nem csinalsz vss menteseket, es/vagy kerulod az mssql maintenance taskokat).
nem veeamspecifikus a dolog (es ha mar itt tartunk igazabol nem is mssql, csak jellemzoen ott jon elo), ne is vard az o oldalukrol a javitast, ez az implementacio ilyen. vannak hibai. szolg. leallitas (lustabbaknak: reboot, ami kevesebb ido fenti rendes vason, mint ezt az egyebkent a csokott ertetlenseged vegett full ertelmetlen kommentet ideirni) javitja. lasd MS doksik, veeam [insert random vss backed backup sw here] forum/ticketek.

a klasszik, 0x80042316. nem tudom mit ertetlenkedsz ezen :D mondom, keress ra. kibaszhatod a vss-t alola, ez a megoldas (csak az vinni fogja az mssql-t is). :)
eleg beszedes:
The flush and hold writes operation on volume \\?\Volume{####} timed out while waiting for a release writes command.
haladjunk tovabb :) faraszto, h nem akarod erteni.

https://forums.veeam.com/vmware-vsphere-f24/volume-shadow-copy-service-…

A reagálások számából nem úgy tűnik, mintha ez egy széles körű, ismert probléma lenne. Szerinted, ha ez széles kört érintene, ennyi komment lenne?

https://www.backupassist.com/support/en/knowledgebase/BA917-Volume-Shad…

Ott vannak a lehetséges problémák és a megoldások ^

trey @ gépház

nekem mondod mit kell csinalni? mint mondtam mssql alol nem fogod kibaszni csak ugy a vss-t, akkor meg mar a reboot hamarabb megvan. :)

mar reg megvolt a reboot, a kov. x nap/het/honap/evben nem kell ezzel foglalkoznom :) x == random generated.

a "segitseged" ennyit is er LOL:

Re: Volume shadow copy service running at backup start causing error Code:0x80042316

  •  

Post by robns » Aug 18, 2024 9:19 am

Wow, is it a strain typing those three words? LOL.

karsten123
Service Provider
Posts: 460
Liked: 114 times
Joined: Apr 03, 2019 6:53 am
Full Name: Karsten Meja
Contact:

Contact karsten123

Re: Volume shadow copy service running at backup start causing error Code:0x80042316

Post by karsten123 » Aug 18, 2024 12:35 pm

sure. no problem

jajajaja! vss error, please szalljkiszalljbe! :) ez tortent. az egyetlen szolgaltatast kell megallitani a gepen hozza.
a reboot hamarabb vegez. annyit nem er a kerdes, h kiadd, h vssadmin list writers, aztan elkezdd mazsolazni ki kicsoda.
aki talalkozott mar ezzel, tudja, hogy a fix: stop/start (hany kommenttel ezelott is mondam el? :D). haladjunk tovabb! :)

Elmondtam:

Építesz egy célszervert, rá MSSQL (nem telebaszva mindennel is), lemented virt. gép szinten, app-aware bekapcsolva, ennyi kb. a MSSQL mentése.

Vagy mented agent-en keresztül, CBT driver-t is felteszed.

Ha ez mindeninél megrohadna, a termék kb. nem létezne egy év múlva.

trey @ gépház

es ki a tokom mondta, h mindenkinel allandoan megrohad? ne farassz mar, direkt hulye vagy vagy mi van? :D
hint: random elojon X idonkent (lehet napok, lehet honapok telnek el) reboot 2 perc, vss debug (aminek a vege mssql stop/start) 10-vegtelen perc. valassz! :D

- Milyen végpontvédelmi megoldás van azon az MSSQL szerveren? > irrelevans. az nem hasznal vss backendet.
- Hogy néz ki a diszk alrendszer? Full HDD? Full SSD? Netalán SAN bootos? > full ssd zfs pool, ami szinten irrelevans. a vm nem lat ki maga alol. ugyanigy random elszarodik, mikor ssd hwraid van alatta meg mikor network storage. meg mikor masik hypervisor "hajcsa". been there, done that.

irrelevans. az nem hasznal vss backendet.

Láttam én már sok mindent összeakadni / leállni / összeomlani a "szuper" végpontvédelmi megoldás beállításai miatt.

full ssd zfs pool, ami szinten irrelevans. a vm nem lat ki maga alol.

Ez pusztán azért fontos, mert láttam már olyan rendszert, ahol az elfogyó IO rogyasztotta meg a VM-t. Hiába volt ZFS, hiába volt virtualizáció, a hiba tova terjedt a VM-ben futó alkalmazásokra is.

Szerkesztve: 2024. 10. 07., h – 15:22

Installált már valaki Proxmoxot (Entrerprise módon) HPE szerverre min. 2 HBA-val vagy Debian 12-vel 0 LUN(0 belső diszkkel)-ról bootolva(multipatht jól bekonfigurálva? :) ? Ha igen, hogyan :) Még a SLES/RedHaten se sikerül? :) Almalinuxon talán? Vannak az Enterprise Linuxokkal is gondok rendesen.