Noi, cei de la Veeam, iubim bustenii. Și deoarece majoritatea soluțiilor noastre sunt modulare, ele scriu o mulțime de jurnale. Și, deoarece scopul activității noastre este de a asigura siguranța datelor dvs. (adică, un somn odihnitor), atunci jurnalele nu ar trebui doar să înregistreze fiecare strănut, ci și să o facă în detaliu. Acest lucru este necesar pentru ca, în caz de ceva, să fie clar cum s-a întâmplat acest „ce”, cine este de vină și ce trebuie făcut în continuare. E ca în criminalistică: nu știi niciodată ce mic lucru te va ajuta să-l găsești pe ucigașul Laurei Palmer.
Prin urmare, am decis să fac un leagăn la o serie de articole, în care voi vorbi secvenţial despre ce scriem în buşteni, unde le depozităm, cum să nu înnebunim cu structura lor şi ce să căutăm în interiorul lor.
De ce o serie de articole și de ce să nu descrie totul deodată?
Pur și simplu enumerarea ce jurnal este unde și ce este stocat în el este o întreprindere destul de dezastruoasă. Și este înfricoșător să te gândești chiar să păstrezi aceste informații la zi. O listă simplă a tuturor tipurilor posibile de jurnale în Veeam Backup & Replication este un tabel pe mai multe foi cu litere mici. Da, și va fi relevant doar în momentul publicării, pentru că. la lansarea următorului patch, pot apărea noi jurnale, logica informațiilor stocate în cele vechi se va schimba etc. Prin urmare, va fi mult mai profitabil să le explicăm structura și esența informațiilor conținute în ele. Acest lucru vă va permite să navigați mai bine prin locuri decât înghesuirea banală de nume.
Prin urmare, pentru a nu vă grăbi cu capul în cap în fondul de foi de text, să facem niște lucrări pregătitoare în acest articol. Prin urmare, astăzi nu vom intra în jurnalele în sine, ci vom merge de departe: vom compila un glosar și vom discuta puțin structura Veeam în ceea ce privește generarea de jurnale.
Glosar și jargon
Aici, în primul rând, merită să ne cerem scuze campionilor purității limbii ruse și martorilor dicționarului lui Ozhegov. Cu toții ne iubim foarte mult limba noastră maternă, dar nenorocita industrie IT funcționează în engleză. Ei bine, nu am venit cu asta, dar s-a întâmplat istoric. Nu e vina mea, a venit el însuși (c)
În afacerea noastră, problema anglicismelor (și jargonului) are propriile ei specificități. Când sub cuvinte inocente precum „gazdă” sau „oaspeți”, întreaga lume a înțeles de mult lucruri foarte specifice, atunci pe ⅙ din pământ continuă confuzia eroică și zguduirea cu introducerea în dicționare. Și argumentul strict obligatoriu „Dar la munca noastră...”.
În plus, există doar terminologia noastră, care este inerentă produselor Veeam, deși unele cuvinte și expresii au ajuns la oameni. Prin urmare, acum ne vom pune de acord asupra termenului ce înseamnă, iar în viitor, sub cuvântul „oaspeți”, mă voi referi exact la ceea ce este scris în acest capitol și nu la ce ești obișnuit la locul de muncă. Și da, acesta nu este capriciul meu personal, aceștia sunt termeni bine stabiliți în industrie. A lupta cu ei este oarecum inutil. Deși sunt întotdeauna în favoarea relaxării în comentarii.
Din păcate, există o mulțime de termeni în munca și produsele noastre, așa că nu voi încerca să-i enumerez pe toți. Doar cele mai de bază și necesare informații despre copiile de rezervă și jurnalele pentru supraviețuirea în mare. Pentru cei interesati pot si eu colegii despre casete, unde a oferit și o listă de termeni legați de acea parte a funcționalității.
Gazdă (gazdă): În lumea virtualizării, aceasta este o mașină cu un hypervisor. Fizic, virtual, cloud - nu contează. Dacă ceva rulează un hypervisor (ESXi, Hyper-V, KVM etc), atunci acest „ceva” se numește gazdă. Fie că este un cluster cu zece rafturi sau laptopul tău cu un laborator pentru o mașină virtuală și jumătate - dacă ai lansat un hypervisor, ai devenit gazdă. Pentru că hypervisorul găzduiește mașini virtuale. Există chiar o poveste că VMware a vrut la un moment dat să obțină o asociere fermă a cuvântului gazdă cu ESXi. Dar ea nu a făcut-o.
În lumea modernă, conceptul de „gazdă” practic a fuzionat cu conceptul de „server”, ceea ce aduce o oarecare confuzie în comunicare, mai ales când vine vorba de infrastructura Windows. Deci, orice mașină care găzduiește un serviciu de interes pentru noi poate fi numită în siguranță gazdă. De exemplu, în jurnalele WinSock totul este marcat cu cuvântul gazdă. Clasicul „Gazdă nu a fost găsită” este un exemplu în acest sens. Așa că pornim de la context, dar amintiți-vă - în lumea virtualizării, o gazdă este cea care găzduiește oaspeții (mai multe despre asta în două rânduri de mai jos).
Din jargonul local (mai degrabă chiar acronime, în acest caz), se reamintește aici că VMware este VI, vSphere este VC și Hyper-V este HV.
Invitat (Invitat): Mașina virtuală care rulează pe gazdă. Nu este nimic de explicat aici, totul este atât de logic și simplu. Cu toate acestea, mulți trag aici cu sârguință alte semnificații.
Pentru ce? Nu știu.
Guest OS, respectiv, sistemul de operare al mașinii guest. Și așa mai departe.
Job de copiere de rezervă/replicare (jobA): Jargon pur Wim, care denotă unele dintre sarcini. Lucrări de rezervă == Lucrări de rezervă. Nimeni nu și-a dat seama cum să o traducă frumos în rusă, așa că toată lumea spune „JobA”. Cu accent pe ultima silabă.
Da, pur și simplu o iau și spun „joba”. Și chiar și în scrisori se scrie așa, și totul este în regulă.
Tot felul de joburi de backup, sarcini de backup etc., mulțumesc, dar nu este nevoie. Doar o slujbă și vei fi înțeles. Principalul lucru este să puneți accentul pe ultima silabă.
Backup (Backup, backup. Pentru true-oldfags, backup este permis): Pe lângă ceea ce este evident (o copie de rezervă a datelor aflate undeva), înseamnă și munca în sine (trei rânduri mai sus, dacă ați uitat deja), în urma căreia apare chiar fișierul de rezervă. Probabil, domnilor vorbitori nativi de engleză sunt prea leneși să spună că mi-am executat jobul de rezervă de fiecare dată, așa că spun doar că mi-am executat backup-ul și toată lumea se înțelege perfect. Vă invit să susțineți această minunată inițiativă.
Consolidare (consolidare): Un termen care a apărut în ESXi 5.0 O opțiune din meniul instantanee care începe procesul de ștergere a așa-numitelor instantanee orfane. Adică, instantanee care sunt disponibile fizic, dar au căzut din structura logică afișată. Teoretic, acest proces nu ar trebui să afecteze fișierele afișate în managerul de instantanee, dar se poate întâmpla orice. Esența procesului de consolidare este că datele din instantaneu (discul copil) sunt scrise pe discul principal (părinte). Procesul de combinare a discurilor se numește îmbinare. Dacă a fost emisă o comandă de consolidare, atunci înregistrarea instantaneului poate fi eliminată din baza de date înainte ca instantaneul să fie fuzionat și ștears. Și dacă instantaneul nu a putut fi șters din orice motiv, atunci apar aceleași instantanee orfane. Despre lucrul cu instantanee, VMware are . Și noi cumva despre ei .
Magazin de date (stocare sau stocare): Un concept foarte larg, dar în lumea virtualizării, este înțeles ca un loc în care sunt stocate fișierele mașinii virtuale. Dar, în orice caz, aici trebuie să înțelegeți foarte clar contextul și, cu cea mai mică îndoială, să clarificați ce anume a avut în vedere interlocutorul dvs.
Proxy (Proxy): Este important să înțelegem imediat că Veeam Proxy nu este chiar la fel cu ceea ce suntem obișnuiți pe Internet. În cadrul produselor Veeam, acesta este un fel de entitate care se ocupă cu transferul de date dintr-un loc în altul. Dacă nu intrați în detalii, atunci VBR este un server de comandă și control, iar proxy-urile sunt calai de lucru. Adică un proxy este o mașină prin care circulă trafic și pe care sunt instalate componente VBR care ajută la gestionarea acestui trafic. De exemplu, pentru a transfera date de pe un canal pe altul sau pur și simplu pentru a lipi discurile de sine (mod HotAdd).
Depozit (Depozit): Din punct de vedere tehnic, aceasta este doar o intrare în baza de date VBR, care indică locul în care sunt stocate backup-urile și cum să vă conectați la acest loc. De fapt, poate fi fie doar o minge CIFS, fie un disc, server sau găleată separat în cloud. Din nou, suntem în context, dar înțelegem că un depozit este doar un loc în care sunt copiile de rezervă.
Instantaneu (SnapshOt): Pasionații de gramatică Oxford preferă să spună cine este instantaneu și cine este instantaneu, dar majoritatea analfabeților beneficiază de masa mai mare. Dacă cineva nu știe, aceasta este o tehnologie care vă permite să restabiliți starea unui disc la un anumit moment în timp. Acest lucru se face fie prin redirecționarea temporară a operațiunilor I/O departe de discul principal - apoi se va numi instantaneu RoW (Redirect on Write) - fie prin mutarea blocurilor reinscriptibile de pe disc pe altul - aceasta se va numi CoW (Copy on Write). ) instantaneu. Datorită posibilităților largi de utilizare a acestor funcții, Veeam își poate funcționa magia de rezervă. Strict vorbind, nu numai ei, ci aceasta este problema următoarelor lansări.
Există haos în jurul acestui termen în documentația și jurnalele ESXi, iar în contextul menționării instantaneelor, puteți găsi instantanee în sine și redo log și chiar disc delta. Documentația Veeam nu conține o astfel de rupere, iar un instantaneu este un instantaneu, iar un jurnal de refacere este exact un fișier REDO creat de un disc independent nepersistent. Fișierele REDO sunt șterse atunci când mașina virtuală este oprită, așa că confundarea lor cu instantanee este o cale către eșec.
Sintetice (Sintetice): Backup-urile sintetice sunt backup incremental invers și pentru totdeauna înainte. În cazul în care nu ați întâlnit acest termen, este doar unul dintre mecanismele folosite pentru a construi o transformare în lanț de rezervă. Cu toate acestea, în jurnale puteți găsi și conceptul de Transformare, care este utilizat în cadrul creării de copii complete din incremente (complet sintetic).
Sarcină (sarcină): Acesta este procesul de procesare a fiecărei mașini individuale în cadrul lucrării. Adică: aveți o sarcină de rezervă, care include trei mașini. Aceasta înseamnă că fiecare mașină va fi procesată ca parte a unei sarcini separate. În total, vor fi patru jurnale: cel principal pentru joburi și trei pentru sarcini. Cu toate acestea, există o nuanță importantă aici: în timp, cuvântul „sarcină” a devenit inutil de ambiguu. Când vorbim despre jurnalele generale, ne referim la faptul că o sarcină este exact o VM. Dar există „sarcini” atât pe proxy, cât și pe depozit. Acolo poate însemna un disc virtual, o mașină virtuală și întreaga lucrare. Adică este important să nu pierdem contextul.
Serviciul Veeam %name%.: Pentru a beneficia de backup-uri de succes, funcționează simultan mai multe servicii, a căror listă poate fi găsită în echipamentul standard. Numele lor reflectă destul de transparent esența lor, dar printre egali există cel mai important - Veeam Backup Service, fără de care restul nu va funcționa.
VSS: Din punct de vedere tehnic, VSS ar trebui să fie întotdeauna pentru Microsoft Volume Shadow Copy Service. De fapt, este folosit de mulți ca sinonim pentru Procesarea imaginilor în funcție de aplicație. Ceea ce, desigur, este categoric greșit, dar aceasta este o poveste din categoria „Orice SUV poate fi numit jeep și vei fi înțeles”.
Bușteni fantastici și unde locuiesc
Vreau să încep acest capitol dezvăluind marele secret - ce oră este afișată în jurnalele?
Tine minte:
- ESXi scrie întotdeauna jurnalele în UTC+0.
- vCenter păstrează jurnalele în funcție de ora fusului său orar.
- Veeam păstrează jurnalele în funcție de oră și fus orar al serverului pe care se află.
- Și numai evenimentele Windows în format EVTX nu suferă de legare la nimic. La deschidere, ora este recalculată pentru mașina pe care au fost deschise. Cea mai convenabilă opțiune, deși există dificultăți cu ea. Singura dificultate tangibilă este diferența de locații. Aceasta este o cale practic garantată către jurnalele care nu pot fi citite. Da, există opțiuni pentru cum să tratăm acest lucru, dar să nu ne certăm cu faptul că totul în IT funcționează în engleză și să fim de acord să setăm întotdeauna limba engleză pe servere. Oh te rog.
Acum să vorbim despre locurile în care trăiesc buștenii și despre cum să le obținem. În cazul VBR, există două abordări.
Prima opțiune este potrivită dacă nu sunteți dornic să căutați fișiere în grămada generală care sunt legate în mod specific de problema dvs. Pentru a face acest lucru, avem un expert separat, căruia îi puteți specifica un anumit job și o anumită perioadă pentru care aveți nevoie de jurnale. Apoi va trece el însuși peste dosare și va pune tot ce aveți nevoie într-o arhivă. Unde să-l căutați și cum să lucrați cu el este descris în detaliu în .
Cu toate acestea, expertul nu colectează jurnalele tuturor sarcinilor și, de exemplu, dacă trebuie să studiați jurnalele de restaurare, failover sau failback, calea dvs. se află în folder %ProgramData%/Veeam/Backup. Acesta este magazinul principal de logo-uri VBR și %ProgramData% este un folder ascuns și este în regulă. Apropo, locația implicită poate fi reatribuită folosind cheia de registry de tip REG_SZ: LogDirectory în ramura HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Backup și replicare.
Pe mașinile Linux, jurnalele agenților de lucru ar trebui căutate în /var/log/VeeamBackup/dacă utilizați un cont root sau sudo. Dacă nu aveți astfel de privilegii, atunci căutați logare /tmp/VeeamBackup.
Pentru agentul Veeam pentru %OS_name% ar trebui căutate jurnalele %ProgramData%/Veeam/Endpoint (Sau, %ProgramData%/Veeam/Backup/Endpoint) Și /var/log/veeam respectiv.
Dacă utilizați Procesarea imaginilor în funcție de aplicație (și, cel mai probabil, utilizați), atunci situația devine oarecum mai complicată. Veți avea nevoie de jurnalele asistentului nostru, care sunt stocate în interiorul mașinii virtuale, și de jurnalele VSS. Despre cum și de unde să obțineți această fericire, este scris în detaliu în . Și bineînțeles că există pentru a colecta jurnalele de sistem necesare.
Evenimentele Windows sunt colectate convenabil conform . Dacă utilizați Hyper-V, lucrurile devin mai complicate, deoarece veți avea nevoie și de toate jurnalele sale din Jurnalele de aplicații și servicii > Microsoft > filiala Windows. Deși puteți merge întotdeauna pe calea mai stupidă și pur și simplu ridicați toate obiectele din %SystemRoot%System32winevtLogs.
Dacă ceva se întrerupe în timpul instalării/actualizării, tot ce aveți nevoie poate fi găsit în folderul %ProgramData%/Veeam/Setup/Temp. Deși nu voi ascunde faptul că în evenimentele OS puteți găsi mai multe informații utile decât în aceste jurnale. Restul lucrurilor interesante se află în %Temp%, dar există în principal jurnalele de instalare pentru software-ul aferent, cum ar fi baza, bibliotecile .Net și alte lucruri. Rețineți că Veeam este instalat din msi și toate componentele sale sunt, de asemenea, instalate ca pachete msi separate, chiar dacă acest lucru nu a fost afișat în GUI. Prin urmare, dacă instalarea uneia dintre componente eșuează, întreaga instalare VBR va fi oprită. Prin urmare, trebuie să intri în jurnale și să vezi ce anume s-a rupt și în ce moment.
Și, în sfârșit, un hack de viață: dacă primiți o eroare în timpul instalării, nu vă grăbiți să faceți clic pe OK. Mai întâi luăm jurnalele, apoi facem clic pe OK. În acest fel veți obține un jurnal care se termină în momentul erorii, fără gunoi la sfârșit.
Și se întâmplă că trebuie să intri în jurnalele vSphere. Ocupația este foarte ingrată, dar, după ce și-a suflecat mânecile, trebuie să faci altceva. În cea mai simplă versiune, avem nevoie de jurnalele cu evenimente de mașină virtuală vmware.log, care se află lângă fișierul său .vmx. Într-un caz mai dificil, deschidem Google și întrebăm unde se află jurnalele pentru versiunea gazdă, deoarece VMware îi place să schimbe acest loc de la o ediție la alta. De exemplu, , dar pentru . Pentru jurnalele vCenter, repetați procedura . Dar, în general, ne vor interesa jurnalele de evenimente gazdă hostd.log, evenimentele gazdă gestionate de vCenter vpxa.log, jurnalele kernelului vmkernel.log și jurnalele de autentificare auth.log. Ei bine, în cazurile cele mai neglijate, jurnalul SSO, care se află în folderul SSO, poate fi util.
Greuitor? Confuz? Infricosator? Dar aceasta nu este nici măcar jumătate din informațiile cu care suportul nostru lucrează zilnic. Deci sunt foarte, foarte cool.
Componentele Veeam
Și ca o concluzie a acestui articol introductiv, să vorbim puțin despre componentele Veeam Backup & Replication. Pentru că atunci când căutați cauza durerii, ar fi bine să înțelegeți cum funcționează pacientul.
Deci, după cum probabil toată lumea știe, Veeam Backup este o așa-numită aplicație bazată pe SQL. Adică toate setările, toate informațiile și, în general, tot ceea ce este necesar doar pentru funcționarea normală - toate acestea se află în baza sa de date. Sau mai degrabă, în două baze de date, dacă vorbim de o grămadă de VBR și EM: VeeamBackup și, respectiv, VeeamBackupReporting. Și așa s-a întâmplat: punem o altă aplicație - apare o altă bază de date. Pentru a nu depozita toate ouăle într-un singur coș.
Dar pentru ca toată această economie să funcționeze fără probleme, avem nevoie de un set de servicii și aplicații care să lege toate componentele împreună. Doar ca exemplu, așa arată într-unul dintre laboratoarele mele:
Acționează ca dirijor șef Serviciul de backup Veeam. El este responsabil de schimbul de informații cu bazele. El este, de asemenea, responsabil pentru lansarea tuturor sarcinilor, orchestrarea resurselor alocate și lucrul ca un fel de centru de comunicații pentru o varietate de console, agenți și orice altceva. Într-un cuvânt, cu siguranță nu există nicio cale fără el, dar asta nu înseamnă deloc că face totul singur.
Îl ajută să-și împlinească planul Veeam Backup Manager. Acesta nu este un serviciu, ci o entitate care lansează joburi și monitorizează procesul de execuție a acestora. Mâinile de lucru ale serviciului de backup, cu care se conectează la gazde, creează instantanee, monitorizează păstrarea și așa mai departe.
Dar să revenim la lista serviciilor. Serviciul de broker Veeam. A apărut în v9.5 (și acesta nu este un cripto miner, așa cum credeau unii atunci). Colectează informații despre gazdele VMware și își menține relevanța. Dar nu alergați imediat să scrieți comentarii supărate că vă spionăm și vă scurgem toate login-urile / parolele către taschmajor. Totul este ceva mai simplu. Când executați o copie de rezervă, primul lucru pe care trebuie să-l faceți este să vă conectați la gazdă și să actualizați toate datele despre structura acesteia. Aceasta este o poveste destul de lentă și greoaie. Amintiți-vă doar cât timp durează să vă conectați prin interfața web și amintiți-vă că numai stratul superior este numărat acolo. Și atunci mai trebuie să deschideți întreaga ierarhie la locul potrivit, apropo. Într-un cuvânt, groază. Dacă executați o duzină de copii de siguranță, atunci fiecare lucrare trebuie să facă această procedură. Dacă vorbim de infrastructuri mari, atunci acest proces poate dura zece minute sau mai mult. Prin urmare, s-a decis alocarea unui serviciu separat pentru aceasta, prin care să se poată primi informații mereu la zi. La pornire, verifică și scanează toată infrastructura adăugată și apoi încearcă să funcționeze numai la nivelul modificărilor incrementale. Deci, chiar dacă executați o sută de copii de siguranță în același timp, toți vor solicita informații de la brokerul nostru și nu vor chinui gazdele cu cererile lor. Dacă ești îngrijorat de resurse, atunci, conform calculelor noastre, 5000 de mașini virtuale au nevoie de doar aproximativ 100 Mb de memorie.
Mai departe avem Consola Veeam. El este Veeam Remote Console, el este Veeam.Backup.Shell. Aceasta este aceeași GUI pe care o vedem în capturile de ecran. Totul este simplu și evident - consola poate fi lansată de oriunde, atâta timp cât este Windows și există o conexiune la serverul VBR. Singurul lucru care se poate spune este că procesul FLR va monta puncte local (adică pe mașina pe care rulează consola). Ei bine, asortate Veeam Explorers vor rula și local, deoarece fac parte din consolă. Dar m-a purtat deja în sălbăticie...
Următorul serviciu interesant este Serviciul de date din catalog Veeam Backup. Cunoscut sub numele de Veeam Guest Catalog Service în lista de servicii. El este angajat în indexarea sistemelor de fișiere pe mașinile invitate și umple folderul VBRCatalog cu aceste cunoștințe. Este utilizat numai acolo unde caseta de selectare a indexării este activată. Și are sens să-l activați doar dacă aveți Enterprise Manager. Prin urmare, sfat din suflet: nu activați indexarea chiar așa dacă nu aveți EAT. Economisiți-vă nervii și timp de sprijin.
De asemenea, de la alte servicii importante este de remarcat Serviciul de instalare Veeam, cu ajutorul căruia sunt livrate și instalate componentele necesare pe proxy-uri, depozite și alte gateway-uri. De fapt, ia pachetele .msi necesare pe servere și le instalează.
Veeam Data Mover - cu ajutorul agenților auxiliari lansați pe proxy (și nu numai) se angajează în deplasarea datelor. De exemplu, atunci când face backup, un agent va citi fișierele din depozitul de date gazdă, iar al doilea le va scrie cu atenție în backup.
Separat, aș dori să remarc un lucru important la care clienții reacționează adesea - aceasta este diferența dintre versiunile de servicii și informații din snap-in-ul Programe și caracteristici. Da, lista va fi aceeași, dar versiunile pot fi complet discordante. Nu e foarte tare din punct de vedere vizual, dar este absolut normal dacă totul funcționează stabil. De exemplu, pentru serviciul de instalare, numărul versiunii este mult în urma celor vecine. Groază și coșmar? Nu, pentru că nu este complet reinstalat, dar DLL-ul său este pur și simplu actualizat. În patch-ul v9.5 U4, a avut loc un coșmar de suport tehnic: în timpul actualizării, toate serviciile au primit versiuni noi, cu excepția celei mai importante. În patch-ul U4b, serviciul de transport le-a depășit pe toate celelalte cu până la două versiuni (judecând după numere). Și acest lucru este, de asemenea, normal - a fost găsită o eroare gravă în el, așa că a primit o actualizare bonus față de restul. Deci, pentru a rezuma: diferențele de versiuni POATE fi o problemă, dar dacă există o diferență și totul funcționează corect, atunci probabil că ar trebui să fie. Dar nimeni nu vă interzice să clarificați acest lucru în suport tehnic.
Acestea erau așa-numitele servicii obligatorii sau obligatorii. Și există o mulțime de altele auxiliare, cum ar fi Serviciul de bandă, Serviciul de montare, Serviciul vPowerNFS și așa mai departe.
Pentru Hyper-V, în general, totul este la fel, doar că există un specific Serviciul de integrare Veeam Backup Hyper-V și propriul șofer pentru a lucra cu CBT.
Și, în final, să vorbim despre cine lucrează pe mașinile virtuale în timpul backup-ului. Pentru a rula scripturi înainte și după înghețare, pentru a crea o copie umbră, pentru a colecta metadate, pentru a lucra cu jurnalele de tranzacții SQL etc. Veeam Guest Helper. Și dacă sistemele de fișiere sunt indexate, Veeam Guest Indexer . Acestea sunt servicii temporare implementate pe durata copiei de rezervă și eliminate după aceasta.
În cazul mașinilor Linux, totul este mult mai simplu datorită prezenței unui număr mare de biblioteci încorporate și a capabilităților sistemului însuși. De exemplu, indexarea se face prin mlocate.
Asta este tot pentru acum
Nu îndrăznesc să te mai rănesc scurt Consider că introducerea în compartimentul motorului Veeam a luat sfârșit. Da, nici măcar nu ne-am apropiat de bârlogurile în sine, dar credeți-mă, pentru ca informațiile prezentate în ele să nu pară un flux incoerent de conștiință, o astfel de introducere este absolut necesară. Plănuiesc să merg la jurnalele în sine doar în al treilea articol, iar planul pentru următorul este să explic cine generează jurnalele, ce anume este afișat în ele și de ce exact, și nu altfel.
Sursa: www.habr.com