Vi på Veeam älskar stockar. Och eftersom de flesta av våra lösningar är modulära, skriver de många loggar. Och eftersom omfattningen av vår aktivitet är att säkerställa säkerheten för dina data (dvs. vilsam sömn), bör loggarna inte bara registrera varje nysning, utan också göra det i detalj. Detta är nödvändigt så att det i händelse av något är tydligt hur detta "vad" hände, vem är skyldig och vad som behöver göras härnäst. Det är som i rättsmedicin: du vet aldrig vilken liten sak som hjälper dig att hitta Laura Palmers mördare.
Därför bestämde jag mig för att ta en sväng på en serie artiklar, där jag sekventiellt kommer att prata om vad vi skriver till stockarna, var vi lagrar dem, hur man inte blir galen med deras struktur och vad man ska leta efter inuti dem.
Varför en serie artiklar och varför inte beskriva allt på en gång?
Att bara lista ut vilken logg som finns var och vad som finns lagrad i den är ett ganska katastrofalt åtagande. Och det är läskigt att ens tänka på att hålla den här informationen uppdaterad. En enkel lista över alla möjliga typer av loggar i Veeam Backup & Replication är en tabell på flera ark med finstilt. Ja, och det kommer att vara relevant endast vid tidpunkten för publicering, eftersom. när nästa patch släpps kan nya loggar dyka upp, logiken för den lagrade informationen i de gamla kommer att ändras, etc. Därför kommer det att vara mycket mer lönsamt att förklara deras struktur och kärnan i informationen som finns i dem. Detta kommer att tillåta dig att bättre navigera på platserna än den banala proppningen av namn.
Därför, för att inte rusa handlöst in i poolen av textblad, låt oss göra lite förberedande arbete i den här artikeln. Därför kommer vi idag inte att komma in på själva loggarna, utan kommer att gå på avstånd: vi kommer att sammanställa en ordlista och diskutera Veeam-strukturen lite när det gäller generering av loggar.
Ordlista och jargong
Här är det först och främst värt att be om ursäkt till förkämparna för det ryska språkets renhet och vittnen i Ozhegovs ordbok. Vi älskar alla vårt modersmål väldigt mycket, men den förbannade IT-branschen fungerar på engelska. Tja, vi kom inte på det, men det hände historiskt. Det är inte mitt fel, han kom själv (c)
I vår verksamhet har problemet med anglicismer (och jargong) sina egna detaljer. När hela världen under oskyldiga ord som "värd" eller "gäst" länge har förstått mycket specifika saker, så fortsätter på ⅙ av landet heroisk förvirring och häpnadsväckande med att peta i ordböcker. Och det strikt obligatoriska argumentet "Men på vårt arbete ...".
Dessutom finns det enbart vår terminologi, som är inneboende i Veeam-produkter, även om vissa ord och fraser har gått till folket. Därför kommer vi nu överens om vilken term som betyder vad, och i framtiden, under ordet "gäst", kommer jag att mena exakt vad som står i det här kapitlet, och inte vad du är van vid på jobbet. Och ja, detta är inte mitt personliga infall, det här är väletablerade termer i branschen. Att bekämpa dem är lite meningslöst. Även om jag alltid är för att chilla i kommentarerna.
Tyvärr finns det många termer i vårt arbete och våra produkter, så jag ska inte försöka lista dem alla. Endast den mest grundläggande och nödvändiga informationen om backuper och loggar för överlevnad i havet. För den som är intresserad kan jag också kollegor om band, där han också gav en lista med termer relaterade till den delen av funktionaliteten.
Värd (värd): I virtualiseringsvärlden är detta en maskin med hypervisor. Fysiskt, virtuellt, moln - det spelar ingen roll. Om något kör en hypervisor (ESXi, Hyper-V, KVM etc), så kallas detta "något" en värd. Oavsett om det är ett kluster med tio rack eller din bärbara dator med ett labb för en och en halv virtuell maskin – om du lanserade en hypervisor blev du en värd. Eftersom hypervisorn är värd för virtuella maskiner. Det finns till och med en historia om att VMware en gång ville uppnå en fast association av ordet värd med ESXi. Men det gjorde hon inte.
I den moderna världen har begreppet "värd" praktiskt taget smält samman med begreppet "server", vilket skapar en viss förvirring i kommunikationen, särskilt när det kommer till Windows-infrastruktur. Så vilken maskin som helst som är värd för någon tjänst av intresse för oss kan säkert kallas en värd. Till exempel, i WinSock-loggarna är allt markerat med ordet värd. Klassikern "Host not found" är ett exempel på detta. Så vi utgår från sammanhanget, men kom ihåg - i virtualiseringens värld är en värd det som är värd för gäster (mer om detta på två rader nedan).
Från lokal jargong (snarare till och med akronymer, i det här fallet) påminns det här om att VMware är VI, vSphere är VC och Hyper-V är HV.
Gäst (Gäst): Den virtuella maskinen som körs på värden. Det finns inget att förklara här, allt är så logiskt och enkelt. Många drar dock flitigt hit några andra betydelser.
För vad? jag vet inte.
Guest OS, respektive gästdatorns operativsystem. Och så vidare.
Backup/replikeringsjobb (jobbA): Ren Wim-jargong, som betecknar några av uppgifterna. Backup jobb == Backup jobb. Ingen har kommit på hur man översätter det vackert till ryska, så alla säger "JobA". Med betoning på sista stavelsen.
Ja, de tar det helt enkelt och säger "joba". Och även i brev skriver de så, och allt är bra.
Alla typer av säkerhetskopieringsjobb, säkerhetskopieringsuppgifter, etc., tack, men inget behov. Bara ett jobb, och du kommer att bli förstådd. Det viktigaste är att betona den sista stavelsen.
Säkerhetskopiering (Backup, backup. För true-oldfags är backup tillåten): Förutom det uppenbara (en säkerhetskopia av data som ligger någonstans), betyder det också själva jobbet (tre rader ovan, om du redan har glömt), vilket gör att själva säkerhetskopian dyker upp. Förmodligen är herrar som talar engelska som modersmål för lata för att säga att jag körde mitt backup-jobb varje gång, så de säger bara att jag körde min backup, och alla förstår varandra perfekt. Jag föreslår att stödja detta underbara initiativ.
Konsolidera (konsolidering): En term som förekom i ESXi 5.0 Ett alternativ i ögonblicksbildsmenyn som startar processen att ta bort så kallade föräldralösa ögonblicksbilder. Det vill säga ögonblicksbilder som är fysiskt tillgängliga, men som föll ur den visade logiska strukturen. Teoretiskt sett bör denna process inte påverka filerna som visas i ögonblicksbildshanteraren, men allt kan hända. Kärnan i konsolideringsprocessen är att data från ögonblicksbilden (underdisken) skrivs till huvuddisken (förälder). Processen att kombinera diskar kallas sammanfogning. Om ett konsolideringskommando har utfärdats kan ögonblicksbildsposten tas bort från databasen innan ögonblicksbilden slås samman och tas bort. Och om ögonblicksbilden av någon anledning inte kunde raderas, visas samma föräldralösa ögonblicksbilder. Om att arbeta med ögonblicksbilder har VMware . Och vi också på något sätt om dem .
Datalager (Stora eller lagring): Ett mycket brett begrepp, men i virtualiseringsvärlden förstås det som en plats där virtuella maskinfiler lagras. Men i alla fall, här måste du förstå sammanhanget mycket tydligt och, med minsta tvivel, klargöra vad din samtalspartner hade i åtanke.
Proxy (Proxy): Det är viktigt att omedelbart förstå att Veeam Proxy inte riktigt är detsamma som det vi är vana vid på Internet. Inom Veeam-produkter är detta en sorts enhet som sysslar med att överföra data från en plats till en annan. Om du inte går in på detaljer så är VBR en kommando- och kontrollserver, och proxyservrar är dess arbetshästar. Det vill säga en proxy är en maskin genom vilken trafik flyter och på vilken VBR-komponenter är installerade som hjälper till att styra denna trafik. Till exempel för att överföra data från en kanal till en annan, eller helt enkelt att fästa diskar till sig själv (HotAdd-läge).
Repository (Repository): Tekniskt sett är detta bara en post i VBR-databasen, som anger platsen där säkerhetskopiorna lagras och hur man ansluter till denna plats. I själva verket kan det antingen bara vara en CIFS-boll eller en separat disk, server eller hink i molnet. Återigen, vi är i sammanhanget, men vi förstår att ett arkiv bara är en plats där dina säkerhetskopior finns.
Ögonblicksbild (SnapshOt): Grammatikfantaster i Oxford föredrar att säga vem som är ögonblicksbild och vem som är ögonblicksbild, men den analfabeta majoriteten drar nytta av den större massan. Om någon inte vet är detta en teknik som gör att du kan återställa tillståndet för en disk vid en viss tidpunkt. Detta görs antingen genom att tillfälligt omdirigera I/O-operationer bort från huvuddisken - då kommer det att kallas RoW (Redirect on Write) ögonblicksbild - eller genom att flytta omskrivbara block från din disk till en annan - detta kommer att kallas CoW (Copy on Write) ) ögonblicksbild. Det är tack vare de breda möjligheterna att använda dessa funktioner som Veeam kan göra sin backup-magi. Strängt taget, inte bara dem, utan det här är frågan om nästa släpp.
Det råder kaos kring denna term i ESXi-dokumentationen och loggar, och i samband med att nämna ögonblicksbilder kan du hitta själva ögonblicksbilder och göra om logg, och till och med deltadisk. Veeam-dokumentationen innehåller inte en sådan rivning, och en ögonblicksbild är en ögonblicksbild, och en redo-logg är exakt en REDO-fil skapad av en oberoende icke-persistent disk. REDO-filer raderas när den virtuella maskinen stängs av, så att förväxla dem med ögonblicksbilder är en väg till misslyckande.
Syntet (syntet): Syntetiska säkerhetskopior är omvända inkrementella och forever forward backups. Om du inte har stött på den här termen är det bara en av mekanismerna som används för att bygga en backup-kedjetransformation. Men i loggarna kan du också hitta konceptet Transform, som används inom ramen för att skapa hela kopior från inkrement (syntetisk full).
Uppgift (uppgift): Detta är processen för att bearbeta varje enskild maskin i jobbet. Det vill säga: du har ett backupjobb, som inkluderar tre maskiner. Det innebär att varje bil kommer att behandlas som en del av en separat uppgift. Totalt kommer det att finnas fyra loggar: den huvudsakliga för jobb och tre för uppgifter. Det finns dock en viktig nyans här: med tiden har ordet "uppgift" blivit onödigt tvetydigt. När vi pratar om allmänna loggar menar vi att en uppgift är exakt en virtuell dator. Men det finns "uppgifter" både på proxyn och på förvaret. Där kan det betyda en virtuell disk, en virtuell maskin och hela jobbet. Det vill säga att det är viktigt att inte tappa sammanhanget.
Veeam %name% tjänst: Till förmån för framgångsrika säkerhetskopieringar fungerar flera tjänster samtidigt, en lista över dessa finns i standardutrustningen. Deras namn återspeglar ganska transparent deras väsen, men bland jämlikar finns det den viktigaste - Veeam Backup Service, utan vilken resten inte kommer att fungera.
VSS: Tekniskt sett bör VSS alltid stå för Microsoft Volume Shadow Copy Service. Faktum är att det används av många som en synonym för Application-Aware Image Processing. Vilket förstås är kategoriskt fel, men det här är en historia från kategorin "Var som helst SUV kan kallas en jeep, och du kommer att bli förstådd."
Fantastiska stockar och var de bor
Jag vill börja det här kapitlet med att avslöja den stora hemligheten - vilken tid visas i loggarna?
Kom ihåg:
- ESXi skriver alltid loggar i UTC+0.
- vCenter håller loggar enligt tiden för dess tidszon.
- Veeam för loggar efter tid och tidszon för servern den är på.
- Och bara Windows-händelser i EVTX-format lider inte av bindning till någonting. Vid öppning räknas tiden om för bilen som de öppnades på. Det mest bekväma alternativet, även om det finns svårigheter med det. Den enda påtagliga svårigheten är skillnaden i lokaler. Detta är en praktiskt taget garanterad väg till oläsbara loggar. Ja, det finns alternativ för hur man ska hantera detta, men låt oss bara inte argumentera med det faktum att allt inom IT fungerar på engelska, och går med på att alltid ställa in den engelska språkversionen på servrarna. Men snälla.
Låt oss nu prata om platserna där stockarna bor och hur man får tag i dem. När det gäller VBR finns det två tillvägagångssätt.
Det första alternativet är lämpligt om du inte är sugen på att leta efter filer i den allmänna högen som är specifikt relaterade till ditt problem. För att göra detta har vi en separat guide, till vilken du kan ange ett specifikt jobb och en specifik period för vilken du behöver loggar. Sedan går han själv igenom mapparna och lägger allt du behöver i ett arkiv. Var man kan leta efter det och hur man arbetar med det beskrivs i detalj i .
Guiden samlar dock inte in loggarna för alla uppgifter och om du till exempel behöver studera loggarna för återställningen, failover eller failback, ligger din sökväg i mappen %ProgramData%/Veeam/Backup. Detta är den huvudsakliga VBR-logobutiken och %ProgramData% är en dold mapp och det är bra. Förresten, standardplatsen kan omtilldelas med hjälp av registernyckeln REG_SZ: LogDirectory i grenen HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Backup and Replication.
På Linux-datorer bör arbetaragentloggar sökas i /var/log/VeeamBackup/om du använder ett root- eller sudo-konto. Om du inte har sådana privilegier, leta efter inloggningar /tmp/VeeamBackup.
För Veeam-agent för %OS_name% bör loggar sökas in %ProgramData%/Veeam/Endpoint (eller %ProgramData%/Veeam/Backup/Endpoint) Och /var/log/veeam respektive.
Om du använder Application-Aware Image Processing (och troligen är du det), så blir situationen något mer komplicerad. Du behöver loggar från vår hjälpreda, som lagras i själva den virtuella maskinen, och VSS-loggarna. Om hur och var man kan få denna glädje, är det skrivet i detalj i . Och visst finns det för att samla in nödvändiga systemloggar.
Windows-händelser samlas bekvämt enligt . Om du använder Hyper-V blir saker mer komplicerade, eftersom du också kommer att behöva alla dess loggar från Applications and Service Logs > Microsoft > Windows-grenen. Även om du alltid kan gå den dummaste vägen och bara plocka upp alla objekt från %SystemRoot%System32winevtLogs.
Om något går sönder under installationen/uppgraderingen finns allt du behöver i mappen %ProgramData%/Veeam/Setup/Temp. Även om jag inte kommer att dölja det faktum att du i OS-händelser kan hitta mer användbar information än i dessa loggar. Resten av det intressanta ligger i %Temp%, men det finns främst installationsloggar för relaterad programvara, såsom basen, .Net-bibliotek och annat. Observera att Veeam är installerat från msi och alla dess komponenter installeras också som separata msi-paket, även om detta inte visades i GUI. Därför, om installationen av en av komponenterna misslyckas, kommer hela VBR-installationen att stoppas. Därför måste du gå in i loggarna och se exakt vad som gick sönder och vid vilken tidpunkt.
Och slutligen, ett livhack: om du får ett fel under installationen, skynda dig inte att klicka på OK. Först tar vi loggarna och klickar sedan på OK. På så sätt får du en logg som slutar vid tidpunkten för felet, utan skräp i slutet.
Och det händer att du behöver komma in i vSphere-loggarna. Sysselsättningen är mycket otacksam, men efter att ha kavt upp ärmarna måste man göra något annat. I den enklaste versionen behöver vi loggar med virtuella maskinhändelser vmware.log, som ligger bredvid dess .vmx-fil. I ett svårare fall, öppna Google och fråga var loggarna för din värdversion finns, eftersom VMware älskar att ändra denna plats från release till release. Till exempel, , men för . För vCenter-loggar, upprepa proceduren . Men i allmänhet kommer vi att vara intresserade av värdhändelseloggar hostd.log, värdhändelser som hanteras av vCenter vpxa.log, kärnloggar vmkernel.log och autentiseringsloggar auth.log. Tja, i de mest försummade fallen kan SSO-loggen, som ligger i SSO-mappen, komma till användning.
Besvärlig? Förvirrad? Skrämmande? Men det här är inte ens hälften av informationen som vår support arbetar med dagligen. Så de är riktigt, riktigt coola.
Veeam-komponenter
Och som en avslutning på den här inledande artikeln, låt oss prata lite om komponenterna i Veeam Backup & Replication. För när man letar efter orsaken till smärtan vore det trevligt att förstå hur patienten fungerar.
Så som alla säkert vet är Veeam Backup en så kallad SQL-baserad applikation. Det vill säga alla inställningar, all information och i allmänhet allt som bara behövs för normal funktion - allt detta finns i dess databas. Eller snarare, i två databaser, om vi pratar om ett gäng VBR och EM: VeeamBackup respektive VeeamBackupReporting. Och så blev det: vi lade en annan applikation - en annan databas dyker upp. För att inte förvara alla ägg i en korg.
Men för att all denna ekonomi ska fungera smidigt behöver vi en uppsättning tjänster och applikationer som knyter ihop alla komponenter. Bara som ett exempel, så här ser det ut i ett av mina labb:
Fungerar som chefsdirigent Veeam Backup Service. Det är han som ansvarar för informationsutbytet med baserna. Han är också ansvarig för att lansera alla uppgifter, orkestrera tilldelade resurser och arbeta som ett slags kommunikationscenter för en mängd olika konsoler, agenter och allt annat. Med ett ord, det finns definitivt ingen väg utan honom, men det betyder inte alls att han gör allt själv.
Hjälper honom att uppfylla hans plan Veeam Backup Manager. Detta är inte en tjänst, utan en enhet som lanserar jobb och övervakar processen för deras genomförande. Säkerhetskopieringstjänstens arbetande händer, med vilka den ansluter till värdar, skapar ögonblicksbilder, övervakar retention, och så vidare.
Men tillbaka till listan över tjänster. Veeam mäklartjänst. Dök upp i v9.5 (och det här är inte en kryptominer, som vissa trodde då). Samlar information om VMware-värdar och upprätthåller dess relevans. Men spring inte direkt för att skriva arga kommentarer om att vi spionerar på dig och läcker alla inloggningar/lösenord till taschmajor. Allt är något enklare. När du kör en säkerhetskopia är det första du behöver göra att ansluta till värden och uppdatera all data om dess struktur. Det här är en ganska långsam och krånglig historia. Kom bara ihåg hur lång tid det tar för dig att logga in via webbgränssnittet, och kom ihåg att endast det översta lagret räknas där. Och då behöver du fortfarande öppna hela hierarkin till rätt plats, förresten. Med ett ord, skräck. Om du kör ett dussin säkerhetskopior måste varje jobb göra den här proceduren. Om vi pratar om stora infrastrukturer kan denna process ta tio minuter eller mer. Därför beslutades att tilldela en separat tjänst för detta, genom vilken det ska vara möjligt att få alltid aktuell information. Vid uppstart kontrollerar och skannar den all tillagd infrastruktur, och försöker sedan endast arbeta på nivån för inkrementella ändringar. Så även om du kör hundra säkerhetskopior samtidigt kommer de alla att begära information från vår mäklare, och kommer inte att plåga värdarna med sina förfrågningar. Om du är orolig för resurser, så behöver 5000 virtuella maskiner enligt våra beräkningar bara cirka 100 Mb minne.
Nästa har vi Veeam konsol. Han är Veeam Remote Console, han är Veeam.Backup.Shell. Detta är samma GUI som vi ser i skärmdumparna. Allt är enkelt och självklart – konsolen kan startas var som helst, så länge det är Windows och det finns en anslutning till VBR-servern. Det enda som kan sägas är att FLR-processen kommer att montera punkter lokalt (dvs på maskinen där konsolen körs). Tja, diverse Veeam Explorers kommer också att köras lokalt, eftersom de är en del av konsolen. Men det har redan fört mig ut i vildmarken ...
En annan intressant tjänst är Veeam Backup Catalog Data Service. Känd som Veeam Guest Catalog Service i listan över tjänster. Han är engagerad i att indexera filsystem på gästdatorer och fyller VBRCatalog-mappen med denna kunskap. Den används endast när kryssrutan för indexering är aktiverad. Och det är bara vettigt att aktivera det om du har Enterprise Manager. Därför ett råd från djupet av mitt hjärta: slå inte på indexering bara sådär om du inte har EAT. Spara dina nerver och stödtid.
Även från andra viktiga tjänster är det värt att notera Veeam Installer Service, med hjälp av vilken de nödvändiga komponenterna levereras och installeras på proxyservrar, repositories och andra gateways. Faktum är att det tar de nödvändiga .msi-paketen till servrarna och installerar dem.
Veeam Data Mover - med hjälp av hjälpagenter som lanseras på fullmakter (och inte bara) är den engagerad i att flytta data. Till exempel, när du säkerhetskopierar, kommer en agent att läsa filer från värddataarkivet, och den andra kommer noggrant att skriva dem till säkerhetskopian.
Separat skulle jag vilja notera en viktig sak som kunder ofta reagerar på - det här är skillnaden i versioner av tjänster och information i program och funktioner snap-in. Ja, listan kommer att vara densamma, men versionerna kan vara helt disharmoniska. Det är inte särskilt coolt ur visuell synvinkel, men det är helt normalt om allt fungerar stabilt. Till exempel för tjänsten Installer är versionsnumret långt efter de närliggande. Skräck och mardröm? Nej, eftersom det inte är helt ominstallerat, utan dess DLL uppdateras helt enkelt. I patch v9.5 U4 inträffade en mardröm för teknisk support: under uppdateringen fick alla tjänster nya versioner, förutom den viktigaste. I U4b-patchen gick transporttjänsten om alla andra med så mycket som två versioner (av siffrorna att döma). Och detta är också normalt - en allvarlig bugg hittades i den, så den fick en bonusuppdatering i förhållande till resten. Så för att sammanfatta det: versionsskillnader KAN vara ett problem, men om det finns en skillnad och allt fungerar korrekt, så borde det förmodligen vara det. Men ingen förbjuder dig att förtydliga detta i teknisk support.
Dessa var de så kallade obligatoriska eller obligatoriska tjänsterna. Och det finns en hel drös med extra sådana, som Tape Service, Mount Service, vPowerNFS Service och så vidare.
För Hyper-V, i allmänhet, är allt sig likt, bara det finns en specifik Veeam Backup Hyper-V Integration Service och din egen drivrutin för att arbeta med KBT.
Och i slutändan, låt oss prata om vem som arbetar på virtuella maskiner under säkerhetskopieringen. Att köra skript före och efter frysning, skapa en skuggkopia, samla in metadata, arbeta med SQL-transaktionsloggar, etc. Veeam Guest Helper. Och om filsystem indexeras, Veeam Guest Indexer . Dessa är tillfälliga tjänster som distribueras under säkerhetskopieringen och tas bort efter den.
När det gäller Linux-maskiner är allt mycket enklare på grund av närvaron av ett stort antal inbyggda bibliotek och kapaciteten hos själva systemet. Till exempel görs indexering genom mlocate.
Det var allt tills vidare
Jag vågar inte skada dig längre kort Jag anser att introduktionen till Veeam-motorrummet är över. Ja, vi har inte ens kommit i närheten av själva hålorna, men tro mig, så att informationen som presenteras i dem inte verkar som en osammanhängande ström av medvetande, är en sådan introduktion absolut nödvändig. Jag planerar att gå till själva loggarna först i den tredje artikeln, och planen för nästa är att förklara vem som genererar loggarna, exakt vad som visas i dem och varför exakt, och inte annars.
Källa: will.com