A Veeamnél szeretjük a rönköket. És mivel a legtöbb megoldásunk moduláris, elég sok naplót írnak. És mivel tevékenységünk célja az Ön adatainak biztonságának biztosítása (azaz a pihentető alvás), ezért a naplók ne csak rögzítsenek minden tüsszentést, hanem részletesen is. Erre azért van szükség, hogy ha valami történik, világos legyen, hogyan történt ez a „mi”, ki a hibás, és mit kell tenni ezután. Ez olyan, mint a kriminalisztika: soha nem tudhatod, milyen apróság segít megtalálni Laura Palmer gyilkosát.
Ezért úgy döntöttem, hogy elindítok egy cikksorozatot, amelyben következetesen arról fogok beszélni, hogy mit írunk a naplókba, hol tároljuk, hogyan ne bolonduljunk meg a szerkezetükkel, és mit kell keresni bennük.
Miért cikksorozat, és miért nem ír le mindent egyszerre?
Egyszerűen felsorolni, hogy melyik napló hol található és mit tárolnak benne, meglehetősen katasztrofális ötlet. És még belegondolni is ijesztő, hogy ezeket az információkat naprakészen tartsuk. A Veeam Backup & Replication összes lehetséges naplótípusának egyszerű felsorolása egy több lapból álló táblázat, apró betűs betűkkel. És csak a megjelenéskor lesz aktuális, mert... A következő javítás megjelenésekor új naplók jelenhetnek meg, megváltozhat a régiekben tárolt információk logikája stb. Ezért sokkal előnyösebb lesz elmagyarázni felépítésüket és a bennük található információk lényegét. Ez lehetővé teszi, hogy jobban navigáljon a helyeken, mint a nevek banális összetömörítése.
Ezért, hogy ne rohanjunk hanyatt-homlok a szöveglapok készletébe, végezzünk néhány előkészítő munkát ebben a cikkben. Ezért ma nem elmélyülünk magukban a naplókban, hanem messziről megyünk: összeállítunk egy szójegyzéket, és egy kicsit megvitatjuk a Veeam felépítését a naplók generálása szempontjából.
Szószedet és szakzsargon
Itt mindenekelőtt érdemes bocsánatot kérni az orosz nyelv tisztaságának bajnokaitól és Ozhegov szótárának tanúitól. Mindannyian nagyon szeretjük az anyanyelvünket, de az átkozott IT-ipar angolul működik. Nos, ezt nem mi találtuk ki, de ez így történt történelmileg. Nem az én hibám, ő maga jött (c)
Vállalkozásunkban az anglicizmusok (és a zsargon) problémájának megvannak a maga sajátosságai. Amikor az olyan ártatlan szavakkal, mint a „házigazda” vagy a „vendég”, az egész világ már régóta nagyon konkrét dolgokat ért, akkor az ország ⅙ részén folytatódik a hősies zűrzavar és a szótárak böködésével való bolyongás. És a szigorúan kötelező érv „De a mi munkánkon...”.
Ráadásul ott van tisztán a mi terminológiánk, amely kifejezetten a Veeam termékekben rejlik, bár néhány szó és kifejezés népszerűvé vált. Ezért most megegyezünk abban, hogy mit jelent a kifejezés, és a jövőben a „vendég” szó alatt pontosan azt fogom érteni, ami ebben a fejezetben le van írva, és nem azt, amit a munkahelyén megszokott. És igen, ez nem az én személyes szeszélyem, ezek jól bevált kifejezések a szakmában. Kicsit értelmetlen harcolni velük. Bár én mindig amellett vagyok, hogy kedves legyek a kommentekben.
Sajnos nagyon sok kifejezés és termék szerepel a munkánkban, ezért nem próbálom meg mindet felsorolni. Csak a legalapvetőbb információk a biztonsági mentésekről és a naplókról, amelyek a tengeren való túléléshez szükségesek. Akit érdekel, azt is tudom kollégáinak a hírcsatornákról, ahol egy listát is közölt a funkció adott részéhez kapcsolódó kifejezésekről.
Házigazda: A virtualizáció világában ez egy hipervizorral rendelkező gép. Fizikai, virtuális, felhő – ez nem számít. Ha valami hipervizort futtat (ESXi, Hyper-V, KVM stb.), akkor ezt a „valamit” gazdagépnek nevezik. Legyen szó akár tíz rackből álló fürtről, akár másfél virtuális gépet befogadó laborral rendelkező laptopról, ha elindított egy hipervizort, gazdagép lett. Mivel a hypervisor virtuális gépeket tárol. Van még egy történet, hogy a VMware egy időben szerette volna elérni, hogy a host szót határozottan asszociálják az ESXi-vel. De nem tudta megtenni.
A modern világban a „gazda” fogalma gyakorlatilag összeolvadt a „szerver” fogalmával, ami bizonyos zavart okoz a kommunikációban, különösen, ha a Windows infrastruktúráról van szó. Tehát minden olyan gép, amelyen valamilyen számunkra érdekes szolgáltatás található, nyugodtan nevezhető hostnak. Például a WinSock naplókban minden a host szóval van jelölve. 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 házigazda az, ami a vendégeket fogadja (erről a két sorban lentebb).
A helyi zsargonból (jelen esetben még a mozaikszavakból) úgy emlékszem, hogy a VMware a VI, a vSphere a VC, a Hyper-V pedig a HV.
Vendég: Egy gazdagépen futó virtuális gép. Itt nincs is mit magyarázni, minden olyan logikus és egyszerű. Sokan azonban szorgalmasan húznak ide néhány más jelentést is.
Miért? Nem tudom.
A vendég operációs rendszer a vendéggép operációs rendszere. Stb.
Biztonsági mentés/replikációs feladat (jobA): Tiszta Wim-zsargon, amely az egyik feladatot jelöli. Biztonsági mentési feladat == Biztonsági mentési feladat. Senki nem találta ki, hogyan kell ezt szépen lefordítani oroszra, ezért mindenki azt mondja, hogy „jobA”. Az utolsó szótag hangsúlyozásával.
Igen, így mennek és mondják, hogy „joba”. És még levelekben is írnak így, és minden rendben.
Mindenféle mentési munka, mentési feladatok stb., köszönöm, de nem kell. Csak csinálj egy munkát, és meg fognak érteni. A lényeg az, hogy a hangsúlyt az utolsó szótagra helyezzük.
Biztonsági mentés (Biztonsági mentés, biztonsági mentés. A true-oldfags esetén a biztonsági mentés megengedett): A nyilvánvaló (valahol az adatok biztonsági másolata) mellett magát a munkát is jelenti (ha már elfelejtette három sorral fent), aminek eredményeként ugyanaz a biztonsági másolat jelenik meg. Valószínűleg, uraim, az angolul beszélők túl lusták ahhoz, hogy azt mondják, hogy minden alkalommal elvégeztem a tartalékmunkámat, ezért csak azt mondják, hogy lefuttattam a tartalékomat, és mindenki tökéletesen megérti egymást. Javaslom ennek a csodálatos kezdeményezésnek a támogatását.
Konszolidálás: Egy kifejezés, amely az ESXi 5.0-ban jelent meg A pillanatkép menüben található opció, amely elindítja az úgynevezett árva pillanatképek törlését. Azaz olyan pillanatképek, amelyek fizikailag elérhetőek, de kiestek a megjelenített logikai struktúrából. Elméletileg ez a folyamat nem érinti a pillanatkép-kezelőben megjelenített fájlokat, de bármi megtörténhet. A konszolidációs folyamat lényege, hogy a pillanatképről (gyermeklemezről) az adatok a fő (szülő) lemezre íródnak. A lemezek egyesítésének folyamatát egyesítésnek nevezik. Ha konszolidációs parancsot adtunk, a pillanatkép rekord törölhető az adatbázisból, mielőtt a pillanatképet egyesítené és törölné. És ha a pillanatfelvételt valamilyen okból nem lehetett törölni, akkor ugyanazok az árva pillanatképek jelennek meg. A VMware információkat tartalmaz a pillanatképekkel való munkavégzésről . És valahogy beszélünk is róluk .
Adattár (Stora vagy százaj): Nagyon tág fogalom, de a virtualizáció világában a virtuális gép fájlok tárolási helyére utal. De mindenesetre nagyon világosan meg kell értenie a szövegkörnyezetet, és ha a legkisebb kétsége is van, tisztázza, hogy a beszélgetőpartnere pontosan mire gondolt.
Meghatalmazott: Fontos, hogy azonnal megértsük, hogy a Veeam Proxy nem teljesen ugyanaz, mint amit az interneten megszoktunk. A Veeam termékeken belül ez egy bizonyos entitás, amely adatokat továbbít egyik helyről a másikra. Anélkül, hogy belemennénk a részletekbe, a VBR egy parancsszerver, és a proxyk a munkalovai. Vagyis a proxy egy olyan gép, amelyen keresztül a forgalom folyik, és amelyre a forgalom irányítását segítő VBR-komponensek vannak telepítve. Például adatokat vigyen át egyik csatornáról a másikra, vagy egyszerűen csatoljon lemezeket önmagához (HotAdd mód).
Adattár: Technikailag ez csak egy bejegyzés a VBR adatbázisban, amely jelzi a biztonsági másolatok tárolási helyét és az ehhez a helyhez való csatlakozás módját. Valójában ez lehet csak egy CIFS megosztás, vagy egy külön lemez, szerver vagy vödör a felhőben. Ismét kontextusban vagyunk, de megértjük, hogy a lerakat csak egy hely, ahol a biztonsági másolatok találhatók.
Pillanatkép: Az oxfordi nyelvtan szerelmesei szívesebben mondják, hogy ki a pillanatfelvétel, ki a pillanatfelvétel, de a nagyobb tömeg miatt az írástudatlan többség nyer. Ha valaki nem tudja, ez egy olyan technológia, amely lehetővé teszi a lemez állapotának visszaállítását egy bizonyos időpontban. Ez vagy az I/O műveletek ideiglenes átirányításával a fő lemezről - ekkor ezt RoW (Redirect on Write) pillanatképnek hívják - vagy az újraírható blokkok áthelyezésével a lemezről egy másikra - ezt CoW-nak (Copy on Írj) pillanatképet. A funkciók széles körű felhasználási lehetőségeinek köszönhetően a Veeam ki tudja dolgozni a biztonsági mentési varázslatot. Szigorúan véve nem csak nekik, de ez a közelgő kiadások kérdése.
A dokumentációban és az ESXi naplókban káosz van e kifejezés körül, és a pillanatképek említésével összefüggésben megtalálhatók maguk a pillanatképek, az újraírási napló és még a delta lemez is. A Veeam dokumentációjában nincs ilyen ellentmondás, és a pillanatkép pillanatkép, az újrakészítési napló pedig pontosan egy független, nem állandó lemez által létrehozott REDO fájl. A REDO fájlok törlődnek, amikor a virtuális gépet kikapcsolják, így összetévesztik őket a pillanatképekkel, ami a kudarc receptje.
Szintetikus: A szintetikus biztonsági mentések fordított növekményes és örökre előre történő biztonsági mentésekre utalnak. Ha még nem találkozott ezzel a kifejezéssel, akkor ez egyszerűen a tartaléklánc-átalakítás felépítéséhez használt mechanizmusok egyike. A naplókban azonban megtalálható a Transform fogalma is, amelyet a növekményből teljes másolatok létrehozásának részeként használnak (szintetikus teljes).
Feladat: Ez az egyes gépek feldolgozásának folyamata egy munkán belül. Azaz: van egy biztonsági mentési munkája, amely három gépet foglal magában. Ez azt jelenti, hogy minden gépet külön feladaton belül dolgoznak fel. Összesen négy napló lesz: a fő a munkához és három a feladatokhoz. Van azonban egy fontos árnyalat: az idő múlásával a „taska” szó túlságosan kétértelművé vált. Amikor általános naplókról beszélünk, akkor azt értjük, hogy a feladat egy virtuális gép. De mind a proxynak, mind a repository-nak megvannak a maga „feladatai”. Itt ez egy virtuális lemezt, egy virtuális gépet vagy a teljes munkát jelenthet. Vagyis fontos, hogy ne veszítsük el a kontextust.
Veeam %name% szolgáltatás: A sikeres mentés érdekében több szolgáltatás működik egyszerre, melyek listája a standard felszereltségben található. A nevük meglehetősen átláthatóan tükrözi a lényegüket, de az egyenlők között ott van a legfontosabb - Veeam Backup Service, amely nélkül a többi nem fog működni.
VSS: Technikailag a VSS-nek mindig a Microsoft Volume Shadow Copy Service kifejezést kell jelentenie. Valójában sokan az alkalmazás-tudatos képfeldolgozás szinonimájaként használják. Ami természetesen kategorikusan hamis, de ez egy történet a „Bármely terepjárót lehet dzsipnek nevezni, és megértenek téged” kategóriából.
Fantasztikus rönkök és azok a helyek, ahol élnek
Ezt a fejezetet azzal szeretném kezdeni, hogy felfedek egy nagy titkot – milyen idő jelenik meg a naplókban?
Emlékezik:
- Az ESXi mindig UTC+0-ban írja a naplókat.
- A vCenter naplókat vezet az időzónája alapján.
- A Veeam naplókat vezet annak a kiszolgálónak az idő és időzónája alapján, amelyre telepítve van.
- És csak az EVTX formátumú fúvós események nem szenvednek semmihez kötöttségtől. Nyitáskor az idő újraszámításra kerül aszerint, hogy melyik gépen nyitották ki. A legkényelmesebb lehetőség, bár nehézségek vannak vele. Az egyetlen észrevehető nehézség a területi különbségek. Ez egy szinte garantált út az olvashatatlan naplókhoz. Igen, vannak lehetőségek ennek kezelésére, de ne vitatkozzunk azzal a ténnyel, hogy az informatikában minden angolul működik, és fogadjuk el, hogy mindig az angol nyelvterületet állítjuk be a szervereken. Oh, kérlek.
Most beszéljünk a helyekről, ahol a rönkök élnek, és hogyan lehet beszerezni őket. A VBR esetében két megközelítés létezik.
Az első lehetőség akkor megfelelő, ha nem szeretne olyan fájlokat keresni az általános halomban, amelyek kifejezetten az Ön problémájához kapcsolódnak. Ehhez van egy külön varázslónk, amelyhez megadhat egy konkrét munkát és egy adott időszakot, amelyre naplózásra van szüksége. Ezután maga fogja átnézni a mappákat, és mindent egy archívumba helyez, amire szüksége van. Arról, hogy hol kell keresni és hogyan kell vele dolgozni, részletesen le van írva .
A varázsló azonban nem gyűjt naplókat minden feladatról, és például ha egy étterem naplóit, feladatátvételt vagy feladat-visszaállítást kell tanulmányoznia, az elérési út a mappában található. %ProgramData%/Veeam/Backup. Ez a fő VBR naplótároló, a %ProgramData% pedig egy rejtett mappa, és ez rendben van. Az alapértelmezett hely egyébként a HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam biztonsági mentési és replikációs ágban található REG_SZ: LogDirectory típusú beállításkulcs segítségével hozzárendelhető újra.
Linuxos gépeken a működő ügynökök naplóit a /var/log/VeeamBackup/, ha root vagy sudo fiókot használ. Ha nem rendelkezik ilyen jogosultságokkal, keresse meg a bejelentkezéseket /tmp/VeeamBackup.
A %OS_name% Veeam-ügynökéhez a naplókban kell keresni %ProgramData%/Veeam/Végpont (vagy %ProgramData%/Veeam/Backup/Végpont) És /var/log/veeam volt.
Ha alkalmazás-tudatos képfeldolgozást használ (és nagy valószínűséggel az is), akkor a helyzet némileg bonyolultabbá válik. Szüksége lesz segédnaplóinkra, amelyek magán a virtuális gépen belül vannak tárolva, és VSS-naplókra. Részletesen meg van írva, hogyan és hol szerezhető ez a boldogság . És persze van hogy összegyűjtse a szükséges rendszernaplókat.
Kényelmes a Windows események összegyűjtése szerint . Ha Hyper-V-t használunk, a dolog bonyolultabbá válik, mivel az összes naplójára is szüksége lesz az Alkalmazások és szolgáltatásnaplók > Microsoft > Windows ágból. Bár mindig választhat egy hülyébb utat, és egyszerűen átvesz minden objektumot a %SystemRoot%System32winevtLogsból.
Ha telepítés/frissítés közben valami eltörik, akkor a %ProgramData%/Veeam/Setup/Temp mappában mindent megtalál, amire szüksége van. Bár nem titkolom, hogy az operációs rendszer eseményeiben több hasznos információt találhat, mint ezekben a naplókban. A többi érdekesség a %Temp%-ban rejlik, de ott főleg a kapcsolódó szoftverek telepítési naplói vannak, mint például az adatbázis, .Net könyvtárak és egyéb dolgok. Kérjük, vegye figyelembe, hogy a Veeam msi-ről van telepítve, és minden összetevője különálló msi-csomagként is telepítve van, még akkor is, ha ez nem jelent meg a grafikus felhasználói felületen. Ezért, ha valamelyik összetevő telepítése meghiúsul, a teljes VBR telepítés leáll. Ezért el kell mennie a rönkökhöz, és meg kell néznie, hogy pontosan mi tört el és melyik pillanatban.
És még egy utolsó life hack: ha hibaüzenetet kap a telepítés során, ne rohanjon az OK gombra kattintva. Először vesszük a naplókat, majd kattintsunk az OK gombra. Így olyan naplót kap, amely a hiba pillanatában ér véget, a végén szemét nélkül.
És előfordul, hogy be kell lépnie a vSphere naplókba. Nagyon hálátlan munka, de ha feltűröd az ingujjat, mást kell csinálnod. A legegyszerűbb verzióban szükségünk lesz a vmware.log virtuális gép eseményeit tartalmazó naplókra, amelyek a .vmx fájl mellett találhatók. Bonyolultabb esetben nyissa meg a Google-t, és kérdezze meg, hol vannak a gazdagép verziójának naplói, mivel a VMware szereti ezt a helyet kiadásról kiadásra módosítani. Például, , de érte . A vCenter naplók esetében megismételjük az eljárást . Általában azonban a hostd.log eseménynaplók, a vCenter vpxa.log által kezelt események, a vmkernel.log kernelnaplók és az auth.log hitelesítési naplók érdekelnek bennünket. Nos, a legfejlettebb esetekben hasznos lehet az SSO napló, amely az SSO mappában található.
Nehézkes? Zavaros? Ijedős? De ez még a fele sem annak az információnak, amellyel a támogatásunk napi szinten dolgozik. Szóval nagyon-nagyon menők.
Veeam alkatrészek
A bevezető cikk befejezéseként pedig beszéljünk egy kicsit a Veeam Backup & Replication összetevőiről. Mert amikor a fájdalom okát keresi, jó lenne megérteni, hogyan működik a beteg.
Tehát, mint azt valószínűleg mindenki tudja, a Veeam Backup egy úgynevezett SQL-alapú alkalmazás. Vagyis az összes beállítás, minden információ és általában minden, ami a normál működéshez szükséges - mindez az adatbázisában található. Vagy inkább két adatbázisban, ha a VBR és az EM kombinációjáról beszélünk: VeeamBackup és VeeamBackupReporting. És így történt: telepítünk egy másik alkalmazást - megjelenik egy másik adatbázis. Hogy ne egy kosárban tárolja az összes tojást.
De ahhoz, hogy ez az egész vállalkozás zökkenőmentesen működjön, szükségünk lesz egy sor szolgáltatásra és alkalmazásra, amelyek összekapcsolják az összes összetevőt. Például az egyik laboratóriumomban így néz ki:
Főkarmesterként működik Veeam biztonsági mentési szolgáltatás. Ő a felelős az adatbázisokkal való információcseréért. Feladata továbbá az összes feladat elindítása, a kiosztott erőforrások összehangolása, valamint egyfajta kommunikációs központként működik a különféle konzolok, ügynökök és minden más számára. Egyszóval nélküle egyáltalán nem megy, de ez egyáltalán nem jelenti azt, hogy mindent maga csinál.
Segít neki tervei megvalósításában Veeam Backup Manager. Ez nem egy szolgáltatás, hanem egy entitás, amely feladatokat indít el és figyeli azok végrehajtásának folyamatát. A biztonsági mentési szolgáltatás dolgozó kezei, amelyekkel csatlakozik a gazdagépekhez, pillanatképeket készít, figyeli a megőrzést stb.
De térjünk vissza a szolgáltatások listájához. Veeam brókerszolgálat. A 9.5-ös verzióban jelent meg (és ez nem egy titkosító bányász, ahogy néhányan gondolták akkor). Információkat gyűjt a VMware gazdagépeiről, és naprakészen tartja azokat. De ne rohanj azonnal dühös kommenteket írni, hogy kémkedünk utánad, és kiszivárogtatjuk az összes bejelentkezési adataidat/jelszavadat a drag majornak. Minden egy kicsit egyszerűbb. Amikor elindít egy biztonsági mentést, először csatlakoznia kell a gazdagéphez, és frissítenie kell a szerkezetére vonatkozó összes adatot. Ez egy meglehetősen lassú és nehézkes történet. Ne feledje, mennyi ideig tart a bejelentkezési művelet a webes felületen keresztül, és ne feledje, hogy ott csak a felső réteg számít. És akkor még mindig ki kell terjesztenie a teljes hierarchiát a megfelelő helyre. Egyszóval horror. Ha tucatnyi biztonsági mentést indít, akkor minden feladatnak végig kell mennie ezen az eljáráson. Ha nagy infrastruktúrákról beszélünk, akkor ez a folyamat akár tíz percig is eltarthat. Ezért úgy döntöttek, hogy erre külön szolgáltatást jelölnek ki, amelyen keresztül mindig naprakész információkhoz lehet majd jutni. Indításkor ellenőrzi és átvizsgálja az összes hozzáadott infrastruktúrát, majd csak a fokozatos változtatások szintjén próbál működni. Tehát még ha száz biztonsági mentés is fut egyidejűleg, ezek mind információt kérnek brókerünktől, és nem gyötörni fogják kéréseikkel a hostokat. Ha aggódik az erőforrások miatt, akkor számításaink szerint 5000 virtuális géphez csak körülbelül 100 Mb memóriára van szüksége.
Következő nálunk Veeam konzol. Más néven Veeam Remote Console, más néven Veeam.Backup.Shell. Ez ugyanaz a grafikus felhasználói felület, amelyet a képernyőképeken látunk. Minden egyszerű és kézenfekvő – a konzol bárhonnan elindítható, feltéve, hogy Windows-ról van szó, és van kapcsolat a VBR szerverrel. Csak annyit lehet mondani, hogy az FLR folyamat lokálisan fogja felcsatolni a pontokat (tehát azon a gépen, ahol a konzol fut). Nos, a különböző Veeam Explorerek is helyben futnak majd, mert ezek a konzol részei. De ez már a vadonba vitt...
A következő érdekes szolgáltatás az Veeam biztonsági mentési katalógus adatszolgáltatás. A szolgáltatások listájában Veeam Vendégkatalógus szolgáltatásként ismert. Vendéggépeken a fájlrendszerek indexelésével foglalkozik, és ezzel a tudással tölti meg a VBRCatalog mappát. Csak akkor használatos, ha az indexelés jelölőnégyzet engedélyezve van. És csak akkor van értelme engedélyezni, ha rendelkezik Enterprise Managerrel. Ezért szívből jövő tanács: ne engedélyezze csak úgy az indexelést, ha nincs EM-je. Spórolja meg idegeit és támogatási idejét.
Más fontos szolgáltatásokról is érdemes megjegyezni Veeam telepítői szolgáltatás, melynek segítségével a szükséges komponensek leszállítása és telepítése történik proxykra, repositóriumokra és egyéb átjárókra. Valójában ő szállítja a szükséges .msi csomagokat a szerverekre, és telepíti azokat.
Veeam Data Mover — a proxykon (és nem csak) elindított segédügynökök segítségével adatot továbbít. Például a biztonsági mentés során az egyik ügynök beolvassa a fájlokat a gazdagép adattárból, a másik pedig gondosan beírja azokat a biztonsági másolatba.
Külön szeretném megjegyezni egy fontos dolgot, amelyre az ügyfelek gyakran reagálnak - a szolgáltatások és információk verzióinak különbségére a Programok és szolgáltatások beépülő modulban. Igen, a lista ugyanaz lesz, de a verziók teljesen ellentmondásosak lehetnek. Ez vizuálisan nem túl nagy, de teljesen normális, ha minden stabilan működik. Például a Telepítő szolgáltatás verziószáma messze elmarad a szomszédaitól. Horror és rémálom? Nem, mert nincs teljesen újratelepítve, hanem a DLL-je egyszerűen frissül. A v9.5 U4 patch-ben technikai támogatási rémálom történt: a frissítés során minden szolgáltatás új verziót kapott, kivéve a legfontosabbat. Az U4b patchben a közlekedési szolgáltatás (a számokból ítélve) akár két verzióval is megelőzte az összes többit. És ez normális is - komoly hibát találtak benne, így bónusz frissítést kapott a többihez képest. Összegezve tehát: a verziókülönbségek PROBLÉMÁT okozhatnak, de ha van eltérés, és minden megfelelően működik, akkor nagy valószínűséggel annak kell lennie. De senki nem tiltja, hogy ezt technikai támogatással tisztázza.
Ezek voltak az úgynevezett kötelező vagy kötelező szolgáltatások. És van egy egész csomag kiegészítő, mint például a Tape Service, a Mount Service, a vPowerNFS Service és így tovább.
A Hyper-V esetében általában minden ugyanaz, csak van egy konkrét Veeam Backup Hyper-V integrációs szolgáltatás és saját illesztőprogramja a CBT-vel való együttműködéshez.
A végén pedig arról fogunk beszélni, hogy kik dolgoznak a virtuális gépeken a biztonsági mentés során. Lefagyasztás előtti és utólagos szkriptek futtatására, árnyékmásolatok létrehozására, metaadatok gyűjtésére, SQL tranzakciós naplókkal való munkavégzésre stb. Veeam vendégsegítő. És ha a fájlrendszerek indexelve vannak, Veeam Vendégindexelő . Ezek ideiglenes szolgáltatások, amelyeket a biztonsági mentés idejére telepítenek, és utána törölnek.
A Linux gépek esetében minden sokkal egyszerűbb a nagyszámú beépített könyvtár jelenléte és magának a rendszernek a képességei miatt. Például az indexelés a mlocate segítségével történik.
Ez minden most
Nem merek tovább gyötörni és rövid A Veeam motortér bemutatását befejezettnek tartom. Igen, még a közelébe sem jutottunk maguknak a naplóknak, de higgyétek el, hogy a bennük közölt információk ne tűnjenek összefüggéstelen tudatfolyamnak, egy ilyen bevezetés feltétlenül szükséges. Magukra a naplókra csak a harmadik cikkben tervezek rátérni, a következőre pedig az, hogy elmagyarázzam, ki generálja a naplókat, pontosan mi jelenik meg bennük és miért pont így, és nem máshogy.
Forrás: will.com