A Veeam egy méltán népszerű megoldás rengeteg ügyfél adatvédelmi törekvéseinek kielégítésére és szerintem általánosan mindenki egyetért azokkal a mondásokkal, hogy “simán működik” vagy éppen a “egyszerűen telepíthető”. Utóbbi olyannyira jellemző, hogy igazából a tervezésre, a mentési rendszer architektúrájának kidolgozására néha nem is igazán kerül sor. Könnyen lehet korlátozott ismeretekkel valaki feltelepíti a VBR-t egy Windows szerverre és igazából a vCenter/SCVMM/HyperV klasztert megadva, már fut is a mentés. Arra gondoltam, ebben a cikkben foglalom össze azokat a részleteket, amelyeket néha-néha látok ügyfelek rendszerében és ezeket egy csokorba fogva talán segít másoknak is abban, hogy mit ne vagy éppen mit ne úgy csináljanak, ahogyan most teszik.
Mentési feladatok átnevezése/törlése
A VBR konzolban bármilyen feladatot hozunk létre, létre fog jönni egy, a job nevével egyező könyvtár és benne pár fájl. Futás alatt és után ebben a könyvtárban gyűlnek a napló és egyéb diagnosztikához használható fájlok. Ha egy feladatot a VBR konzolban átnevezünk, akkor a könyvtár attól még nem neveződik át, hanem mellé létrejön a job új nevével egyező könyvtár. A régi meg ott is marad. Ez nyilvánvalóan nem gond, de néha igen sok felesleges fájl és könyvtár tud felgyűlni egy egy már huzamosabb ideje használt és gyakorta változtatgatott Veeam telepítésben.
Az alábbi példában a job neve “VM Backup Job – PROD” és ez tükröződik is a C:\ProgramData\Veeam\Backup könyvtárban található azonos nevű mappában.
Ha ezt a feladatot átnevezem “VM Backup Job – PROD2”-re, lefuttatom a feladatot, máris világossá válik, hogy a ProgramData alatt nem neveződik át csak megjelenik az új.
Tudom javasolni a nem szükségesek törlését a C:\ProgramData\Veeam\Backup alól. Ami szintén érdekes, hogy a mentési célterületen – nem object storage/dedup storage stb-ről beszélek – a mentési könyvtár neve a repository-n, a job nevével egyezik. Ha átnevezem a job-ot, attól a repository-n a könyvtár neve nem fog változni!
Mentések törlése
Ha itt tartunk, akkor magukról a feladatok törléséről is meg kell emlékezni. A mentési célterület, azaz ahová a mentések kerülnek nyilvánvalóan értékes tároló, amit méretezni kell és szinte minden esetben ki van centizve. Azaz nem jellemző az, hogy mondjuk van egy 100TB-os mentési cél és abból csak 10TB felhasznált, sokkal jellemzőbb, hogy egyensúlyozni kell a maximális kihasználás és a még sikeres mentések között, mert ha elfogy a hely, akkor nem lesz sikeres mentés, sőt mi több, ideiglenesen, a mentések transzformációjára is kell némi terület – akár egy teljes mentésnyi.
Készítek egy mentést – a fenti példából – “VM Backup Job – PROD_TBD” néven és mentegetek is vele.
Látható is, hogy a repsitory-n létre is jött, sőt mi több, immáron van is benne mentés.
Akkor most le is törlöm a job-ot.
Mi törlődött? Hát semmi. A C:\ProgramData\Veeam\Backup-ban a job nevével egyező könyvtár örökre ott is marad ezután.
A mentési célterületen is ott marad az összes mentés.
Ami az ügyfél oldali adminisztrátorok figyelmét néha elkerüli, az az hogy a bal oldalon a Backups alatt megjelenik egy új elem, mégpedig a “Disk (Orphaned)”. Arra rákattintva látható, hogy mi volt a job neve ami a mentéseket előállította és látszanak maguk a mentések is.
Ezek nyilvánvalóan fogyasztják a helyet a mentési célterületen és automatikusan soha az életben nem törlődnek majd le onnan. Az idők végezetéig lehet őket kerülgetni vagy éppen időnként érdemes átnézni ezt a menüt, hogy van-e valami, ami már tényleg nem kell.
Ha nem kell, akkor a job nevére kattintva egy releváns opció jön elő – v11-nél még kettő volt. A “delete from disk” pont az amit akkor kell választani, ha az amúgy már job-bal nem rendelkező mentési kópiák már nem kellenek és fel kívánom szabadítani a helyet, amit könnyen lehet feleslegesen foglalnak.
Ha így járok el, akkor le is törli, hely is lesz újra.
Per VM backup job
Ennél a pontnál különbséget kell tenni egy v10/11-es rendszer és adott esetben annak v12-re történő frissítése vagy egy teljesen új v12 telepítés között. Utóbbi esetben a repository létrehozásakor alapértelmezett a “Use per-machine backup files” használata, ami korábbi verzióknál nem volt így. Ennek tekintetében az alábbi lehet releváns és irreleváns is rendszerről, rendszerre. Én alább egy v11-es kiépítést mutatok, bár v12-es telepítésben, azaz nem használok per machine backup fájlokat.
Arról van szó, hogy egy mentési feladatba, egyetlen VM-et teszek. Mikor egy Veeam rendszer tervezése/implementációja a feladatom, akkor a mentési feladatok szervezése és ütemezése a kedvenc részem, hiszen egyszerre kell figyelembe venni legalább négy jellemzőt.
- mikor történjen a mentés
- hová történjen a mentés
- milyen megőrzési idők szükségesek
- hogy lesz elegendő mentési sebesség
Ha a mentési időablak, a célterület és a megőrzési jellemzők azonosak több workload számára, akkor célszerű azokat egy mentési feladatba tenni. Ennek oka nagyon egyszerű: a Veeam a mentési kópiák deduplikációját és tömörítését a job-on belül teszi, azaz egy job-on belül szereplő workload-ok között végzi csak el. Tehát ha van egy mentési feladatom és abban szerepel 10 darab Microsoft Windows Server 2019 gép, akkor – kisarkítva persze – a C:\Windows könyvtárat jól lehet csak egyszer fogja letárolni a mentési célterületen.
De próbáljuk ki! Készítettem négy mentési feladatot:
- VM Backup Job – PROD – benne a DC1,CLIENT01,CLIENT02 gépekkel.
- VM Backup Job – PROD_CLIENT01 – benne csak a CLIENT01-el
- VM Backup Job – PROD_CLIENT02 – benne csak a CLIENT02-vel
- VM Backup Job – PROD_DC01 – benne csak a DC01-el
Kikapcsoltam az első mentés előtt az összes VM-et, hogy elkerüljem akár egy bit módosulását is a mentések között. Sikeres mentés után nézzük meg a feladat statisztikáit.
Az a mentés, amiben a három VM együtt volt. Látszik, hogy 7,7GB-ot tárolt végül le a repository-n.
Remek. Most nézzük meg azokat a feladatokat, azt a hármat, amiben egy-egy VM volt csak.
Az látszik, hogy abban a mentésben, ahol a három VM együtt volt, ott a mentési fájl 7,7GB lett, míg a három job, amelyekben csak 1-1 VM volt, igazából 19,8GB-ot eredményezett.
Mi következi ebből? Hogyha NEM per-VM backup file-t használ valaki a repository-n, akkor inkább tegye egy job-ba a VM-jeit, amelyek a mentési ablak, megőrzés stb. tekintetében azonos igényekkel bírnak, mert komoly mennyiségű helyet tud megspórolni.
De mi van akkor ha per-VM backup file-t használ? Ahogyan a v12-ben már javasolt is? Akkor is érdemes egy feladatba tenni több VM-et, mivel nem mindegy a menedzsment szempontjából, hogy 400 job-ot kell nézegetni és ütemezni – nagyon nem mindegy – vagy csak egyet/kettőt.
Guest file indexing
A mentési feladatoknál az “Enable guest file indexing” elég hívogató. Véleményem szerint egyenesen félrevezető. Nézzük meg ezt az alábbi képet. Írja-e ez azt, hogy akinek nincs Veeam Backup Enterprise Manager rendszere, annak ez teljesen felesleges? Nem írja, pedig így van.
De ha a Veeam dokumentációját nézzük, akkor ott persze nem spóroltak azzal a 20 karakterrel ami a fenti képen segítene ezt felismerni. https://helpcenter.veeam.com/docs/backup/vsphere/indexing.html?ver=120
Ha ilyen nem áll rendelkezésre, akkor ezt nem érdemes bekapcsolni ráadásul több igen jelentős okból:
- plusz terhet jelent a mentett workload-on – CPU/RAM
- plusz tárhelyet igényel a backup szerveren
- hosszabb mentési folyamat
Mindezt teljesen feleslegesen, ha nincs Enterprise Manager. Ha nincs, akkor a backup job-ban nem szükséges bekapcsolni ezt, mert nem csinál semmit.
Ha van Enterprise Manager, akkor pedig érdemes nem a C:\ meghajtót használni az index helyéül, bár az Enterprise Manager a feldolgozás során a backup server-en tárolt index-eket elviszi és törli.
Feladatok egymás után fűzése
Aka “job chaining”. Nem mondom nem szabad használni, de alaposan körül kell járni mi történik és mi a legrosszabb ami történhet. A job chainging azt, amikor több mentési feladat közül mondjuk csak egy van ütemezve és a többi, azok ettől az ütemezett feladattól kapják meg az indítási jelet és így tovább. Egy láncot alkotva ugye.
Példaként hozom az ismert rendszert.
Amennyiben a mentési feladatokban lévő mentendő workload-ok egymással semmiféle függőségi kapcslatban nem állnak olyan tekintetben, hogy pl az egyik feladatban lévő VM exportál egy adatbázist (azért ilyen hülye a példa, mert nem tudok értelmeset kitalálni) és a másik feladatban lévő VM azt a fájlt másolná magára és így mentenénk le, akkor nem érdemes a két job-ot egymástól függővé tenni. Miért?
Mert ha valamelyik feladatban lévő bármely workload mentése tovább tart vagy éppen nem sikerül, akkor tolódik az egész mentés a láncban az azt követő workload-ok számára is. Ha van mentési ablak, akkor abból nyilván így ki is lehet futni. Ha bármelyik feladatban ráadásul a retry be van kapcsolva, akkor szintén jó esély van arra, hogy perceket, órákat csússzon a mentés.
Ezért szinte soha sehol nem szoktam javasolni a láncolatot.
Összefoglaló
A Veeam bár egyszerű rendszer – is lehet – mégis fontos a jó beállítás, mert értékes helyet, időt és nem kevés vesződséget lehet megspórolni, lényegében költségek nélkül.
