A Veeam szereti a naplókat. Mivel a megoldásaink többsége moduláris, ezért sok naplót generálnak. Mivel pedig tevékenységünk célja az adatok biztonságának garantálása (azaz a nyugodt alvás), a naplóknak nemcsak minden apróságot rögzíteniük kell, hanem ezt részletesen is kell tenniük. Erre azért van szükség, hogy ha bármi történik, tudjuk, mi is pontosan történt, ki a felelős, és mit kell tennünk ezután. Itt, akár a kriminológiában: sosem tudhatod, milyen apróság segít megtalálni Laura Palmer gyilkosát.
Ezért úgy döntöttem, hogy elindítok egy cikk sorozatot, ahol fokozatosan bemutatom, mit rögzítünk a naplókban, hol tároljuk őket, és hogyan ne őrüljünk meg a struktúrájuk miatt, valamint mit is keressünk bennük.
Miért cikk sorozat és miért nem írjuk le mindent egyszerre?
Csak felsorolni, hogy melyik napló hol található és mit tartalmaz — eléggé értelmetlen vállalkozás. Arról nem is beszélve, hogy ennek az információnak a naprakészen tartása rémálom. A Veeam Backup & Replication összes lehetséges naplótípusának egyszerű felsorolása egy több oldalas, apró betűs táblázat lenne. Ráadásul ez csak a közzététel időpontjában lenne aktuális, mivel a következő verzió megjelenésekor új naplók léphetnek életbe, vagy megváltozhat a korábbiakban tárolt információ logikája, stb. Ezért sokkal előnyösebb lesz elmagyarázni a struktúrájukat és a bennük lévő információ lényegét. Ez lehetővé teszi, hogy jobban tájékozódjunk a helyszíneken, mint a puszta nevekre való memorizálás.
Ezért, hogy ne ugorjunk fejest a szöveges óceánba, némi előkészítő munkát végezzünk ebben a cikkben. Tehát ma nem merülünk el magukban a naplókban, hanem távolabbról közelítünk: létrehozunk egy szószedetet és egy kicsit beszélgetünk a Veeam struktúrájáról a naplók generálásának szempontjából.
Szószedet és zsargon
Itt először is elnézést kérek az orosz nyelv tisztaságáért aggódóktól és Oжегов szótárának tanúitól. Mindannyian nagyon szeretjük anyanyelvünket, de a átkozott IT ipar angolul működik. Hát, ezt nem mi találtuk ki, így alakult történelem folyamán. Nem én vagyok a hibás, ő jött magától (c)
A szakmánkban az anglicizmusok (és zsargon) problémája sajátossággal bír. Amikor ártatlan szavak, mint a „host” vagy a „guest”, már egyértelmű dolgokat jelentenek a világ egyhatod részén, addig itt egy hősi zűrzavar és kapkodás zajlik, ahol a szótárakra mutogatnak. És a kötelezően beadott érv: „Nálunk a munkahelyen…”.
Emellett létezik egy tisztán a Veeam termékekre jellemző terminológia is, noha egyes szavak és fordulatok széles körben elterjedtek. Ezért most megállapítjuk, hogy melyik kifejezés mit jelent, és a jövőben a „guest” szó alatt én pontosan azt fogom érteni, ami ebben a fejezetben van, nem pedig azt, amit ti a munkahelyeteken megszoktál. És igen, ez nem az én személyes kívánságom, ezek ipari standardok. Harcolni ellenük némileg értelmetlen. Bármikor örömmel kommentelném a dolgot.
Sajnos a munkánkban és a termékekben rengeteg kifejezés létezik, így nem próbálkozom az összes felsorolásával. Csak a legalapvetőbb és legszükségesebbeket említem, amelyek az információábrázolás ezernyi tengerében való túléléshez kellenek a biztonsági mentésekről és a naplókról. Az érdeklődőknek tudom ajánlani, hogy a kollégák írnak a szalagról, ahol egy lista található a funkciókhoz kapcsolódó kifejezésekről is.
Host (Host): A virtualizáció világában ez egy gépet jelent hypervisorral. Legyen az fizikai, virtuális, vagy felhőalapú — nem számít. Ha valamin hypervisor fut (ESXi, Hyper-V, KVM stb.), akkor ez a „valami” hostnak nevezik. Legyen az egy tíz rackes klaszter vagy a laptopod másfél virtuális géppel — ha hypervisort futtatsz, akkor hostként működsz. Mert a hypervisor hosztolja a virtuális gépeket. Még az is közszájon forog, hogy a VMware valaha a „host” szót szeretné egyértelműen az ESXi-hez társítani. De végül nem sikerült nekik.
A modern világban a „host” fogalma szinte összeolvadt a „server” fogalmával, ami zavart okoz a kommunikációban, különösen a Windows infrastruktúra esetében. Így bármely gép, amelyen valamilyen érdekes szolgáltatás található, bátran nevezhető hostnak. Például a WinSock naplókban a host szó mindent jelöl. A klasszikus „Host not found” egy példa erre. Tehát a kontextusból indulunk ki, de ne feledjük — a virtualizáció világában a host az, ami a guesteket hosztolja (erről két sorral lejjebb).
A helyi zsargonokból (inkább akronimokból, ebben az esetben) itt emlékezzünk meg, hogy a VMware a VI, a vSphere a VC, a Hyper-V pedig HV.
Vendég (Guest): Egy virtuális gép, amely a hoszton fut. Itt tulajdonképpen nincs mit magyarázni, minden olyan logikus és egyszerű. Azonban sokan igyekeznek itt valami más értelembe kényszeríteni ezt.
Miért? Nem tudom.
A Guest OS pedig a vendéggép operációs rendszere. És így tovább.
Backup/Replikációs Feladat (Job): Tiszta VMware zsargon, amely valamilyen feladatot jelöl. Backup job == Bekerült Feladat. Hogyan lehet ezt szebben lefordítani — senki nem találta ki, ezért mindenki azt mondja 'job'. A hangsúly az utolsó szótagra esik.
Igen, így egyszerűen mondják, hogy 'job'. És még a levelekben is így írják, és minden rendben van.
Mindenféle Bekerült Feladatok, Bekerülési Feladatok stb., köszönöm, de nem kell. Csak 'job', és megértenek. A lényeg, hogy a hangsúlyt az utolsó szótagra kell helyezni.
Backup (Bébackup, bekerülés. Az igazi veteránoknak helyt adva: bákuppal): A nyilvánvalón kívül (egy valahol létező tartalék másolat), ezt a feladatot is jelenti (három sorral fentebb, ha már elfelejtetted), aminek eredményeként létrejön az a bizonyos backup fájl. Valószínűleg az angol anyanyelvűek túl lusták ahhoz, hogy minden alkalommal azt mondják: 'Futtattam a backup jobomat', ezért egyszerűen azt mondják: 'Futtattam a backupot', és mindenki jól megérti egymást. Javaslom, hogy támogassuk ezt a nagyszerű kezdeményezést.
Konszolidáció (Consolidate): Egy kifejezés, amely az ESXi 5.0-ban jelent meg. Az opció a pillanatképek kezelésének menüjében, amely elindítja a legyengült pillanatképek eltávolításának folyamatát. Tehát azok a pillanatképek, amelyek fizikailag léteznek, de kiestek a megjelenített logikai struktúrából. Elméletileg ez a folyamat nem érintheti a menedzserben megjelenített pillanatképeket, azonban bármi történhet. A konszolidáció lényeg az, hogy a pillanatképből (child disk) származó adatok a fő (parent) lemezre íródnak. A lemezek egyesítésének folyamata a mërge (merge). Ha parancsot adtak a konszolidációra, akkor a pillanatkép nyilvántartása korábban eltávolítható az adatbázisból, mint ahogy a pillanatképet egyesítik és eltávolítják. Ha pedig a pillanatképet bármilyen okból nem sikerült eltávolítani, akkor megjelennek ezek a legyengült pillanatképek. A VMware-nek van Mi is írtunk róluk .
Adatközpont (Datastore): Nagyon széles értelemben, azonban a virtualizáció világában azt értik alatta, hogy hol tárolják a virtuális gépek fájljait. De mindenképpen nagyon világosan meg kell érteni a kontextust, és a legkisebb kétség esetén tisztázni, hogy pontosan mit is értett a beszélgetőpartnere.
Proxy (Proxikiszolgáló): Fontos azonnal megérteni, hogy a Veeam Proxy nem egészen ugyanaz, amit az interneten megszoktunk. A Veeam termékein belül ez egy olyan entitás, amely az adatok áthelyezésével foglalkozik egyik helyről a másikra. Ha nem mélyedünk bele a részletekbe, a VBR egy parancs szerver, míg a proxik a munkásai. Tehát a proxy egy gép, amelyen keresztül a forgalom áramlik, és amelyre a VBR komponensei vannak telepítve, amelyek segítenek irányítani ezt a forgalmat. Például adatokat áthelyezni egy csatornából a másikba, vagy egyszerűen diskeket csatlakoztatni magához (HotAdd mód).
Repository (Tárhely): Technikailag ez egyszerűen egy bejegyzés a VBR adatbázisban, amely megmutatja, hol tárolják a biztonsági mentéseket és hogyan lehet kapcsolódni ehhez a helyhez. Valójában ez lehet akár egy egyszerű CIFS megosztás is, de lehet egy külön lemez, szerver vagy tároló az felhőben. Ismétlem, kontextusban vagyunk, de megértjük, hogy a repository csupán az a hely, ahol a biztonsági mentéseid találhatók.
Snapshot (Instantkép): Az Oxfordi nyelvtan kedvelői azt mondják, hogy valaki snApShotot, mások snEpShotot használnak, azonban a tudatlan többség nyer a nagy számban. Ha valaki nem tudná – ez egy olyan technológia, amely lehetővé teszi a lemez állapotának visszaállítását egy adott időpontban. Ezt vagy a fő lemezre irányított I/O műveletek ideiglenes elterelésével végzik – ez esetben RoW (Redirect on Write) snapshotnak hívják – vagy az átkonfigurálásra használt blokkok áthelyezésével a lemezelhelyezésről egy másik helyre – ezt CoW (Copy on Write) snapshotnak hívják. Pontosan ezeknek a funkcióknak a széleskörű alkalmazási lehetőségei révén tudja a Veeam megvalósítani biztonsági másolati varázslatát. Szigorúan véve nem csak ő, de ez a legközelebbi kiadások ügye.
Az ESXi dokumentációjában és naplójában káosz uralkodik e kifejezés körül, és a pillanatképek említésekor találkozhatunk magukkal a pillanatképekkel, a redo logokkal és akár a delta lemezekkel is. A Veeam dokumentációjában ilyen zűrzavar nincs, a pillanatkép az pillanatkép, míg a redo log pontosan a REDO fájl, amelyet egy független, nem tartós lemez hozott létre. A REDO fájlok eltűnnek a virtuális gép leállításakor, így összekeverni őket a pillanatképekkel a kudarc útja.
Szintrikus (Synthetic): A szintrikus biztonsági mentések a visszafelé inkrementális és a folyamatos előremutató biztonsági mentések közé tartoznak. Ha esetleg még sosem találkoztál ezzel a kifejezéssel, akkor ez egy a biztonsági mentés láncának felépítésére használt mechanizmus. Azonban a naplókban találkozhatunk a Transform kifejezéssel is, amelyet a növekményekből történő teljes másolatok (synthetic full) létrehozásakor használnak.
Feladat (Task): Ez a folyamat minden egyes gép feldolgozása egy munka keretein belül. Tehát: ha van egy biztonsági mentési állásodból három gépet tartalmazó munka. Ez azt jelenti, hogy minden gép külön feladatként kerül feldolgozásra. Összesen négy naplót kapunk: egy főt a munkához és hármat a feladatokhoz. Fontos azonban, hogy itt van egy fontos árnyalat: idővel a "feladat" szó túlzottan sokértelművé vált. Amikor az általános naplókról beszélünk, akkor az „feladat” alatt pontosan a virtuális gépet értjük. De vannak saját „feladataink” a proxyban és a tárolóban is. Ott ez jelentheti a virtuális lemezt, a virtuális gépet és az egész munkát is. Tehát fontos, hogy ne veszítsük szem elől a kontextust.
Veeam %name% Szolgáltatás (Service): A sikeres biztonsági mentések érdekében számos szolgáltatás dolgozik, amelyek listáját a szabványos eszközkészletben találod. Ezek nevei elég világosan tükrözik a lényegüket, ugyanakkor a legfontosabb közöttük a Veeam Backup Service, anélkül hogy a többi nem működik.
VSS: Technikailag a VSS mindig a Microsoft Volume Shadow Copy Service-t jelenti. Gyakorlatilag sokan alkalmazás-tudatos képfeldolgozás szinonimájaként használják. Ami természetesen kategorikusan téves, de ez egy olyan történet, mint hogy „Bármilyen terepjárót hívhatsz dzsipnek, és megértenek”.
Fantáziadús naplók és a hely, ahol laknak
E fejezetet szeretném a nagy titok felfedésével kezdeni – milyen időt mutatnak a naplók?
Vedd észre:
- Az ESXi mindig UTC+0 időben írja a naplókat.
- A vCenter a saját időzónájának megfelelő időben vezeti a naplókat.
- A Veeam a szerver idejének és időzónájának megfelelően vezeti a naplókat.
- Csak a Windows események az EVTX formátumban nem kötődnek semmihez. Amikor megnyitják őket, az időzítés a gépre kerül át, ahol megnyitják őket. Ez a legkényelmesebb lehetőség, bár ezzel is akadnak nehézségek. Az egyedüli érezhető nehézség a lokális különbségek. Ez szinte garantáltan olvashatatlan naplókhoz vezet. Igen, vannak megoldások ennek kezelésére, de ne vitatkozzunk azzal, hogy minden az IT-ben angolul működik, és állapodjunk meg abban, hogy mindig angol lokációt állítunk be a szervereken. Kérlek.
Most pedig beszéljünk a helyekről, ahol a naplók élnek, és hogyan lehet hozzájuk jutni. A VBR esetében két megközelítést létezik.
Az első lehetőség az, ha nem égető vágyad, hogy a tömegből keresd meg azokat a fájlokat, amelyek a te problémádhoz kapcsolódnak. Erre van egy külön varázslónk, amelynek megadhatod a konkrét feladatot és az adott időszakot, amelyre a naplókat keresed. Ezt követően ő magától végigfut a mappákon, és mindent szükségeset egy archívumba gyűjt össze. Arról, hogy hol találod és hogyan dolgozz vele, részletesen írtunk .
Azonban a varázsló nem gyűjti össze minden feladat naplóit, és például ha szükséges a restaurálás, failover vagy failback naplóinak átnézése, akkor az utad a %ProgramData%/Veeam/Backup. Ez a VBR fő naplóhelye, a %ProgramData% pedig egy rejtett mappa, ami teljesen normális. Egyébként az alapértelmezett helyet át lehet nevezni a REG_SZ típusú bejegyzés segítségével: LogDirectory a HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication ágon.
Linux gépek esetében a munkafolyamat ügynökök naplóit a következő helyen kell keresni:/var/log/VeeamBackup/, ha root vagy sudo fiókot használsz. Ha nincsenek ilyen jogosultságaid, akkor keresd a naplókat a /tmp/VeeamBackup.
A Veeam ügynök számára a %OS_name% a naplókat a következő helyen kell keresni: %ProgramData%/Veeam/Endpoint SysWOW64 %ProgramData%/Veeam/Backup/Endpoint, ennek eredményeként a lekérdezések olyan formát öltenek, mint a fent említett. /var/log/veeam vagy.
Ha az Application-Aware Image Processing-t használod (ami valószínűleg is így van), akkor a helyzet kissé bonyolódik. Szükséged lesz a segédprogramunk naplóira, amelyek a virtuális gépen belül találhatók, és a VSS naplókra. Arról, hogyan és hol szerezheti meg ezt a boldogságot, részletesen írtunk . És természetesen van a szükséges rendszer naplók összeállításához.
A Windows események kényelmesen gyűjthetők a . Ha Hyper-V-t használsz, a helyzet bonyolultabbá válik, mivel szükséged lesz az összes naplójára az Applications and Service Logs > Microsoft > Windows ágból. Bár mindig lehet egy kicsit fájdalmasabb utat választani, és egyszerűen elvenni az összes objektumot a %SystemRoot%\System32\winevt\Logs-ból.
Ha valami elromlik a telepítés vagy frissítés során, akkor minden szükséges információt megtalál a %ProgramData%/Veeam/Setup/Temp mappában. Bár nem titkolom, hogy a Windows eseménynaplókban hasznosabb információkat lehet találni, mint ezekben a naplókban. A további érdekes dolgok a %Temp% mappában találhatók, de ott főleg a kísérő szoftver telepítési naplói vannak, mint például az adatbázis, a .Net könyvtárak és egyéb. Vegye figyelembe, hogy a Veeam msi-ből települ, és minden komponens is külön msi csomagként települ, még ha ez a GUI-ban nem is látható. Következésképpen, ha egy komponens telepítése meghiúsul, az egész VBR telepítést leállítják. Tehát érdemes megnézni a naplókat, hogy pontosan mi romlott el és mikor.
És itt van egy életmentő tipp a végére: ha telepítés közben hibát kap, ne siessen megnyomni az OK-t. Először gyűjtse be a naplókat, majd nyomja meg az OK-t. Így egy olyan naplót kap, amely a hiba pillanatában ér véget, anélkül, hogy a végén szemét lenne.
Előfordulhat, hogy bele kell bújni a vSphere naplókba. Ez igen hálátlan feladat, de ha felgöngyölítjük az ujjainkat, ilyen is előfordul. A legegyszerűbb esetben a vmware.log eseménynaplókra lesz szükségünk, amelyek a .vmx fájl mellett találhatók. Bonyolultabb esetben nyissuk meg a Google-t, és kérdezzük meg, hogy a vendéglátó verziójához hol találhatók a naplók, mert a VMware imádja ezt a helyet változtatni a különböző frissítések alatt. Például, , és itt van a . A vCenter naplókhoz ismételjük meg az eljárást a . De általánosságban a hostd.log eseménynaplókra, a vCenter irányítása alatt álló hostok vpxa.log eseménynaplókra, a vmkernel.log kernel naplókra és az auth.log hitelesítési naplókra lesz szükségünk. A legrosszabb esetben hasznos lehet az SSO napló is, amely az SSO mappában található.
Bonyolult? Összezavaró? Ijesztő? Pedig ez még nem is a fele annak az információnak, amivel a támogatásunk naponta dolgozik. Szóval valóban nagyon ügyesek.
A Veeam komponensei
És a bevezető cikk lezárásaként beszéljünk egy kicsit a Veeam Backup & Replication komponenseiről. Mivel ha a fájdalom okát keressük, nem árt tudni, hogyan működik a páciens.
Tehát, ahogy mindenki számára egyértelmű, a Veeam Backup egy úgynevezett SQL-alapú alkalmazás. Ez azt jelenti, hogy minden beállítás, minden információ és lényegében minden, ami a megfelelő működéshez szükséges—mindez az adatbázisában található. Pontosabban, két adatbázisban, ha a VBR és EM kapcsolatra gondolunk: VeeamBackup és VeeamBackupReporting, ennek megfelelően. Így alakult: egy további alkalmazás telepítésekor egy új adatbázis is megjelenik. Nem akarom, hogy az összes tojás egy kosárban legyen.
De ahhoz, hogy mindez a rendszer zökkenőmentesen működjön, szükségünk lesz egy szolgáltatáskészletre és alkalmazásokra, amelyek összekapcsolják az összes komponenst. Példa gyanánt, így néz ki az egyik laborom:
A fő dirigensként szerepel Veeam Backup Service. Ő felel az információcseréért az adatbázisokkal. Emellett felelős az összes feladat elindításáért, az allokált erőforrások orkesterálásáért, és kommunikációs központként működik a különböző konzolok, ügynökök és minden egyéb számára. Szóval nélküle semmiképpen sem működne, de ez egyáltalán nem jelenti azt, hogy mindent ő csinál egyedül.
A megvalósítását segíti Veeam Backup Manager. Ez nem egy szolgáltatás, hanem egy entitás, amely a feladatok elindításával foglalkozik, és figyelemmel kíséri a végrehajtásuk folyamatát. A backup service munkáskezében dolgozik, amelyeken keresztül csatlakozik a hosztokhoz, létrehozza a pillanatfelvételeket, figyelemmel kíséri a megőrzést, és így tovább.
De térjünk vissza a szolgáltatások listájához. Veeam Broker Service. Megjelent a v9.5-ben (és ez nem egy kriptobányász, ahogy akkor néhányan gondolták). Információt gyűjt a VMware hosztokról, és karbantartja annak naprakészségét. De ne rohannyatok azonnal dühös kommenteket írni, hogy megfigyelünk titeket és ellopjuk az összes jelszót. Mindenkicsit egyszerűbb. Amikor elindítjátok a biztonsági mentést, először is csatlakozni kell a hoszthoz, és frissíteni kell az összes adatodat a struktúrájáról. Ez elég lassú és körülményes folyamat. Csak gondolj arra, mennyi időt vesz igénybe a bejelentkezési művelet a webes felületen, és ne feledd, hogy ott csak a legfelső réteget számolják. Aztán még meg kell nyitni az összes hierarchiát a szükséges helyig egyébként. Szóval, borzalom. Ha tucatnyi biztonsági mentést indítasz, akkor minden egyes feladatnak meg kell csinálnia ezt a procedúrát. Ha nagy infrastruktúrákról van szó, akkor ez a folyamat akár tíz percig is eltarthat vagy tovább. Ezért döntöttünk úgy, hogy külön szolgáltatást hozunk létre, amelyen keresztül mindig aktuális információkat lehet szerezni. Indításkor ellenőrzi és beolvassa az összes hozzáadott infrastruktúrát, majd csak az inkrementális változásokat próbálja kezelni. Így ha egyszerre száz biztonsági mentés indul, mindegyik a mi brókerünknél fog információt kérni, nem pedig feleslegesen terheli a hosztokat a kéréseikkel. Ha aggasztanak az erőforrások, akkor a számításaink szerint 5000 virtuális géphez körülbelül 100 Mb memória szükséges.
Továbbá következik Veeam Console. Ő a Veeam Remote Console, valamint a Veeam.Backup.Shell. Ez az a GUI, amelyet a képernyőfotókon látunk. Minden egyszerű és nyilvánvaló — a konzolt bárhonnan el lehet indítani, csak Windowsnak kell lennie, és kapcsolatban kell lennie a VBR szerverrel. Az egyetlen, amit elmondhatunk: a FLR folyamat helyben fogja csatolni a pontokat (tehát azon a gépen, ahol a konzol fut). Nos, és a különféle Veeam Explorerek is helyben fognak futni, mivel ők a konzol részei. De ez már mélyebb vizekre vezetett…
A következő érdekes szolgáltatás — Veeam Backup Catalog Data Service. A szolgáltatási listán Veeam Guest Catalog Service néven ismert. A vendéggépek fájlrendszereinek indexelésével foglalkozik, és ezeket az ismereteket a VBRCatalog mappába tölti. Csak ott használják, ahol be van jelölve az indexelés. Érdemes csak akkor bekapcsolni, ha rendelkezik Enterprise Manager-rel. Tehát a szívünk szerint azt tanácsoljuk: ne kapcsolja be az indexelést csak úgy, ha nincs EM-je. Kímélje meg az idegeit és a support idejét.
Emellett más fontos szolgáltatások is említésre érdemesek. Veeam Installer Service, amellyel a szükséges összetevők szállítása és telepítése történik a proxykon, a tárolókon és egyéb gatewayeken. Valójában .msi csomagokat szállít a szerverekre és telepíti azokat.
Veeam Data Mover — a proxykon (és nemcsak ott) futó segédügynökökkel foglalkozik az adatok áthelyezésével. Például, biztonsági mentés során egy ügynök a gazdaszerek fájljait olvassa, míg a másik gondosan rögzíti azokat a biztonsági mentésbe.
Külön érdemes megemlíteni egy fontos dolgot, amire a kliensek gyakran reagálnak – a szolgáltatások verzióinak eltérése és az Osztályozások és funkciók eszközben lévő információk. Igen, a lista ugyanaz lesz, de a verziók között teljes zűrzavar lehet. Ez vizuálisan nem túl szép, de teljesen normális, ha minden stabilan működik. Például az Installer szolgáltatás verziószáma jelentősen lemarad a szomszédosaktól. Szörnyű és rémisztő? Nem, mert nem telepítik újra teljesen, csak a DLL-je frissül. A v9.5 U4 javítócsomagban a technikai támogatás rémálma valósult meg: frissítéskor minden szolgáltatás új verziót kapott, kivéve a legfontosabbat. Az U4b javítócsomagban a szállító szolgáltatás két verzióval megelőzte az összes többit (ha a számokat nézzük). És ez is rendben van – komoly hibát találtak benne, ezért bónusz frissítést kapott a többiekhez képest. Tehát, összefoglalva: a verziókülönbség PROBLÉMÁT jelenthet, de ha a különbség fennáll, és minden megfelelően működik, akkor valószínűleg így kell lennie. De senki sem tiltja meg, hogy ezt a technikai támogatásnál pontosítsa.
Ezek voltak az úgynevezett kötelező vagy Mandatory services. Van még egy csomó segédszolgáltatás is, mint például a Tape Service, Mount Service, vPowerNFS Service és így tovább.
A Hyper-V esetében is nagyjából ugyanaz a helyzet, csak van egy specifikus Veeam Backup Hyper-V Integration Service és saját illesztőprogramja a CBT kezelésére.
A végén pedig arról fogunk beszélni, hogy kik dolgoznak virtuális gépeken a biztonsági mentés során. A pre- és post-freeze szkriptek futtatásához, árnyékképek létrehozásához, metainformációk gyűjtéséhez, SQL tranzakciós naplók kezeléséhez és egyéb feladatokhoz használják Veeam Guest Helper. És ha a fájlrendszerek indexelése történik, Veeam Guest Indexer . Ezek ideiglenes szolgáltatások, amelyeket a biztonsági mentés idejére telepítenek, majd azt követően eltávolítanak.
Linux gépek esetében mindez sokkal egyszerűbb a rengeteg beépített könyvtár és a rendszer kedvező lehetőségei miatt. Például az indexelés mlocate-on keresztül történik.
Ennyit egyelőre
Nem akarom tovább kínozni Önöket, és a rövid bevezetőmet a Veeam háttérvilágába befejezettnek tekintem. Igen, még közel sem értünk el a naplókhoz, de higgye el, hogy ahhoz, hogy az ezekben bemutatott információ ne tűnjön összefüggéstelen tudatlanságnak, ilyen bevezetés határozottan szükséges. A naplókhoz való áttérést csak a harmadik cikkben tervezem, a következő cikkem pedig arra fog kitérni, hogy ki generálja a naplókat, mi pontosan szerepel bennük és hogy miért éppen így, és nem másképp, ahogyan az a naplókban látható.
Forrás: habr.com
