Мы ў Veeam любім логі. А паколькі большасць нашых рашэнняў модульныя, то логаў яны пішуць дастаткова шмат. А раз сфера нашай дзейнасці - гэта забеспячэнне захаванасці вашых дадзеных (г.зн. спакойнага сну), то логі павінны не толькі фіксаваць кожны чых, але і рабіць гэта даволі падрабязна. Гэта неабходна, каб у выпадку чаго было зразумела, як гэта “чаго” здарылася, хто вінаваты, і што трэба рабіць далей. Тут як у крыміналістыцы: ніколі не ведаеш, якая дробязь дапаможа табе знайсці забойцу Лоры Палмер.
Таму я вырашыў замахнуцца на серыю артыкулаў, дзе паслядоўна раскажу пра тое, што мы пішам у логі, дзе іх захоўваем, як не звар'яцець ад іх структуры і што ж шукаць у іх усярэдзіне.
Чаму серыя артыкулаў і чаму не апісаць усё зараз?
Проста пералічыць, які лог дзе ляжыць і што ў ім захоўваецца - задума даволі гіблая. А пра падтрыманне гэтай інфармацыі ў актуальным выглядзе нават і думаць страшна. Просты пералік усіх магчымых відаў логаў у Veeam Backup & Replication - гэта табліца на некалькі лістоў дробным шрыфтам. Ды і актуальная яна будзе толькі на момант публікацыі, т.я. пры выхадзе наступнага патча могуць з'явіцца новыя логі, зменіцца логіка захоўваемай інфармацыі ў старых, і т.д. Таму значна больш выгадна будзе растлумачыць іх структуру і сутнасць інфармацыі, якая ў іх утрымліваецца. Гэта дазволіць лепш арыентавацца на месцах, чым банальная зубрэжка назваў.
Таму, каб не кідацца з галавой у вір тэкставых прасцін, давайце ў гэтым артыкуле правядзем нейкую падрыхтоўчую працу. Таму сёння мы не будзем залазіць у самі логі, а зойдзем здалёк: складзем гласарый і трохі абмяркуем структуру Veeam з пункта гледжання генерацыі логаў.
Гласарый і жарганізмы
Тут перш за ўсё варта папрасіць прабачэння ў прыхільнікаў чысціні рускай мовы і сведкамі слоўніка Ожагава. Мы ўсе вельмі любім сваю родную мову, але праклятая IT індустрыя працуе на англійскай. Ну вось не мы гэта прыдумалі, а так склалася гістарычна. Не вінаватая я, ён сам прыйшоў (з)
У нашай справе праблема англіцызмаў (і жаргону) мае сваю спецыфіку. Калі пад нявіннымі словамі накшталт «хост» ці «госць» увесь свет ужо даўно разумее зусім канкрэтныя рэчы, то на ⅙ частцы сушы працягваецца гераічны разброд і хістанне з тыканнем у слоўнікі. І строга абавязковы аргумент "А вось у нас на працы…".
Плюс ёсць чыста наша тэрміналогія, якая ўласцівая менавіта прадуктам Veeam, хаця некаторыя словы і абароты сышлі ў народ. Таму зараз мы дамовімся, які тэрмін што значыць, і ў далейшым пад словам "госць" я буду мець на ўвазе менавіта тое, што напісана ў гэтым раздзеле, а не тое, што вы прывыклі ў сябе на працы. І так, гэта не асабіста мая капрыз, гэта ўстояныя ў індустрыі тэрміны. Ваяваць з імі крыху бессэнсоўна. Хоць пахаліварыць у каментах я заўсёды за.
Нажаль, тэрмінаў у нашай працы і прадуктаў вельмі шмат, так што спрабаваць пералічыць іх усё я не буду. Толькі самыя базавыя і неабходныя для выжывання ў моры інфармацыі аб бекапах і логах. Для тых, хто цікавіцца, магу таксама калегі пра стужкі, дзе ён таксама прыводзіў спіс тэрмінаў, якія адносяцца да той часткі функцыянальнасці.
Host (Хост): У свеце віртуалізацыі гэта машына з гіпервізарам. Фізічная, віртуальная, хмарная - усё роўна. Калі на чымсьці запушчаны гіпервізор (ESXi, Hyper-V, KVM etc), тое гэта "нешта" завецца хастом. Будзь гэта кластар на дзесяць стоек або ваш ноўтбук з лабай на паўтары віртуалкі - калі запусцілі гіпервізор, то сталі хастом. Бо гіпервізор хосціць віртуальныя машыны. Ёсць нават байка, што VMware у свой час жадала дамагчыся цвёрдай асацыяцыі слова хост менавіта з ESXi. Але не здужала.
У сучасным свеце паняцце "хост" практычна злілося з паняццем "сервер", што ўносіць пэўную смуту ў зносіны, асабліва калі гаворка пра Windows інфраструктуру. Так што любая машына, на якой знаходзіцца нейкі цікавы нам сэрвіс, можа быць смела названа хастом. Напрыклад, у логах WinSock словам host пазначаецца ўсё запар. Класічнае "Host not found" таму прыкладам. Так што зыходзім з кантэксту, але памятаем - у свеце віртуалізацыі хост - гэта тое, што хосціць гасцей (пра гэта двума радкамі ніжэй).
З лакальных жарганізмаў (хутчэй нават акронімаў, у дадзеным выпадку) тут успамінаецца, што VMware – гэта VI, vSphere – гэта VC, а Hyper-V – гэта HV.
Guest (Госць): Віртуальная машына, якая працуе на хасце. Тут нават і тлумачыць няма чаго, настолькі ўсё лагічна і проста. Аднак многія старанна цягнуць сюды нейкія іншыя сэнсы.
Навошта? Я не ведаю.
Guest OS, адпаведна, аперацыёнка гасцёўні машыны. І гэтак далей.
Backup/Replication Job (джобА): Чыста вімаўскі жарганізм, які абазначае нейкае з заданняў. Backup job == Бекапная Джоба. Як гэта прыгожа перавесці на рускую - ніхто не прыдумаў, таму ўсе кажуць «джобА». З націскам на апошні склад.
Так, вось так проста бяруць і кажуць "джоба". І нават у лістах так пішуць, і ўсё добра.
Усякія Бекапныя працы, Заданні Бекапа і г.д., дзякуй, але не трэба. Проста джоба, і вас зразумеюць. Галоўнае - націск ставіць на апошні склад.
Backup (Бэкап, бекап. Для труЪ-олдфагаў дапушчаецца бакУп): Апроч відавочнага (якая ляжыць дзесьці рэзервовая копія дадзеных), азначае яшчэ і саму джобу (тры радкі вышэй, калі ўжо забыліся), у выніку якой і з'яўляецца той самы бекапны файл. Верагодна, спадары носьбіты ангельскай занадта лянівыя, каб кожны раз казаць I ran my backup job, таму яны проста кажуць I ran my backup, і ўсе адзін аднаго выдатна разумеюць. Прапаную падтрымаць гэтае выдатнае пачынанне.
Consolidate (Кансалідацыя): Тэрмін, які з'явіўся ў ESXi 5.0 Опцыя ў меню працы са снапшотамі, якая запускае працэс выдалення так званых orphaned снапшотаў. Гэта значыць снапшотаў, якія фізічна маюцца, але выпалі з якая адлюстроўваецца лагічнай структуры. Тэарэтычна, дадзены працэс не павінен закрануць якія адлюстроўваюцца ў мэнэджары снапшотаў файлы, аднак бывае ўсякае. Сутнасць працэсу кансалідацыі ў тым, што дадзеныя з снапшота (child disk) запісваюцца ў асноўны (parent) дыск. Працэс аб'яднання дыскаў называецца мёржам (merge). Калі была аддадзена каманда на кансалідацыю, то запіс аб снапшоце можа быць выдалены з базы раней, чым снапшот будзе смержен і выдалены. І калі снапшот не ўдалося выдаліць па любой прычыне, то з'яўляюцца гэтыя самыя orphaned снапшоты. Пра працу са снапшотамі ў VMware ёсць . І мы таксама неяк пра іх .
Datastore (Стара ці стородж): Вельмі шырокае паняцце, аднак у свеце віртуалізацыі пад ім разумеюць месца, дзе захоўваюцца файлы віртуальных машын. Але ў любым выпадку тут трэба вельмі выразна разумець кантэкст і пры найменшых сумневах удакладняць, што менавіта ваш суразмоўца меў на ўвазе.
Proxy (Проксі): Важна адразу зразумець, што Veeam Proxy – гэта не зусім тое самае, да чаго мы прывыклі на палях інтэрнэту. У межах прадуктаў ад Veeam гэта нейкая сутнасць, якая займаецца перакладаным дадзеных з аднаго месца ў іншае. Калі не ўдавацца ў падрабязнасці, то VBR – гэта камандны сервер, а проксі – гэта яго працоўныя конікі. Гэта значыць проксі - гэта машына, праз якую цячэ трафік і на якой устаноўлены кампаненты VBR, якія дапамагаюць гэтым трафікам руліць. Напрыклад, перакладаць дадзеныя з аднаго канала ў іншы ці проста чапляць да сябе дыскі (HotAdd mode).
Repository (Рэпазіторы): Тэхнічна гэта проста запіс у базе VBR, якая паказвае на месца, дзе захоўваюцца бекапы, і як да гэтага месца падлучыцца. Фактычна гэта можа быць як проста CIFS шара, так і асобная кружэлка, сервер або бакет у воблаку. Зноў жа, знаходзімся ў кантэксце, але разумеем, што рэпазітар - гэта проста месца, дзе ляжаць вашыя бекапы.
Snapshot (СнапшОт): Аматары оксфардскай граматыкі аддаюць перавагу казаць хто снепшот, хто снепшот, аднак непісьменная большасць выйграе за кошт большай масы. Калі хто не ведае - гэта тэхналогія, якая дазваляе аднавіць стан дыска на пэўны момант часу. Робіцца гэта або за кошт часовага перанакіравання I/O аперацый у бок ад асноўнай кружэлкі - тады гэта будзе звацца RoW (Redirect on Write ) снапшот - ці за рахунак вынясення перазапісвальных блокаў з вашага кружэлкі на іншы - гэта будзе звацца CoW (Copy on Write) снапшот. Менавіта дзякуючы шырокім магчымасцям па ўжыванні гэтых функцый Veeam і можа тварыць сваю бекапную магію. Строга кажучы, не толькі ім, але гэта справа найблізкіх рэлізаў.
У дакументацыі і логах ESXi вакол гэтага тэрміна робіцца хаос, і ў кантэксце згадвання снапшотаў можна сустрэць і самі снапшоты, і redo log і нават delta disk. У дакументацыі Veeam такога раздрая няма, і снапшот - гэта снапшот, а рэда лог гэта менавіта REDO файл, створаны незалежным non-persistent дыскам. REDO файлы выдаляюцца пры выключэнні віртуалкі, так што блытаць іх са снапшотамі - шлях да правалу.
Synthetic (Сінтэтыка): Сінтэтычныя бекапы адносяцца да reverse incremental і forever forward бекапам. Калі вы раптам не сутыкаліся з гэтым тэрмінам, то гэта проста адзін з механізмаў, якія выкарыстоўваюцца для пабудовы пераўтварэння бекапной ланцужкі. Аднак у логах таксама можна сустрэць паняцце Transform, якое выкарыстоўваецца ў рамках стварэння поўных дзід з інкрэмэнтаў (synthetic full).
Task (Таска): Гэта працэс апрацоўкі кожнай асобнай машыны ў рамках джобы. Гэта значыць: маеце вы бекапную джобу, куды ўключана тры машыны. Значыць, кожная машына будзе апрацоўвацца ў рамках асобнай цягі. Разам будзе чатыры лога: асноўны на джобу і тры на цягі. Аднак тут ёсць важны нюанс: з часам слова "цяга" стала залішне шматзначным. Калі мы гаворым пра агульныя логі, то маем на ўвазе, што цяга - гэта менавіта ВМ. Але свае "таскі" ёсць і на проксі, і на рэпазітары. Там гэта можа азначаць і віртуальную кружэлку, і віртуальную машыну, і ўсю джобу. Гэта значыць, важна не страціць кантэкст.
Veeam %name% Service (Сэрвіс): На балазе паспяховых бекапаў працуе адразу некалькі сэрвісаў, спіс якіх можна знайсці ў стандартным абсталяванні. Іх імёны дастаткова празрыста адлюстроўваюць іх сутнасць, аднак сярод роўных ёсць самы важны – Veeam Backup Service, без якога астатнія працаваць не будуць.
VSS: Тэхнічна VSS заўсёды павінен абазначаць Microsoft Volume Shadow Copy Service. Фактычна выкарыстоўваецца шматлікімі як сінонім Application-Aware Image Processing. Што, вядома ж, катэгарычна няправільна, аднак гэта гісторыя з разраду Любы пазадарожнік можна назваць джыпам, і цябе зразумеюць .
Фантастычныя логі і месцы, дзе яны насяляюць
Жадаю пачаць гэты раздзел з расчынення вялікай таямніцы - які час адлюстроўваецца ў логах?
Запамінайце:
- ESXi заўсёды піша логі ў UTC+0.
- vCenter вядзе логі па часе сваёй таймзоны.
- Veeam вядзе логі па часе і таймзоне сервера на якім стаіць.
- І толькі віндовыя івэнты ў EVTX фармаце не пакутуюць прывязкай ні да чаго. Пры адкрыцці час пералічваецца пад машыну, на якой іх адчынілі. Самы зручны варыянт, хаця бываюць складанасці і з ім. Адзіная адчувальная цяжкасць - розніца лакаляў. Гэта практычна гарантаваны шлях да нечытэльных логаў. Так, ёсць варыянты, як гэта лячыць, але давайце проста не будзем спрачацца з тым, што ўсё ў IT працуе на англійскай, і дамовімся заўсёды выстаўляць на серверах англійскую лакаль. Ну калі ласка.
Цяпер усё ж пагаворым аб месцах, дзе жывуць логі і як іх займець. У выпадку VBR ёсць два падыходы.
Варыянт першы падыходзіць, калі вы не гарыце жаданнем вышукваць у агульнай кучы файлы, якія адносяцца менавіта да вашай бяды. Для гэтага ў нас ёсць асобны візард, якому можна пазначыць канкрэтную джобу і канкрэтны перыяд, за які вам патрэбны логі. Далей ён сам прабяжыцца па татачках і складзе ўсё неабходнае ў адзін архіў. Аб тым, дзе яго шукаць і як з ім працаваць, падрабязна напісана ў .
Аднак визард збірае логі не ўсіх заданняў і, напрыклад, у выпадку неабходнасці вывучыць логі рэстара, фэйлавера ці фэйлбека шлях ваш ляжыць у тэчку %ProgramData%/Veeam/Backup. Гэта галоўнае лагасховішча VBR, а %ProgramData% з'яўляецца ўтоенай тэчкай і гэта звычайна. Дарэчы, месца па змаўчанні можна перапрызначыць з дапамогай рэестравага ключа тыпу REG_SZ: LogDirectory у галінцы HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Backup and Replication.
На лінуксавых машынах логі працоўных агентаў варта шукаць у /var/log/VeeamBackup/, калі выкарыстоўваецца рутавы або sudo рахунак. Калі такіх прывілеяў у вас няма, то шукайце логі ў /tmp/VeeamBackup.
Для Veeam agent for %OS_name% логі трэба шукаць у %ProgramData%/Veeam/Endpoint (Або %ProgramData%/Veeam/Backup/Endpoint) І /var/log/veeam адпаведна.
Калі вы карыстаецеся Application-Aware Image Processing (а хутчэй за ўсё вы яго карыстаецеся), то сітуацыя некалькі ўскладняецца. Вам спатрэбяцца логі нашага хелпера, якія захоўваюцца ўнутры самой віртуалкі, і логі VSS. Пра тое, як і дзе здабываць гэтае шчасце, падрабязна напісана ў . І, вядома ж, ёсць па зборы неабходных сістэмных логаў.
Падзеі Windows зручна збіраць паводле . Калі вы выкарыстоўваеце Hyper-V, справа ўскладняецца, бо вам спатрэбяцца яшчэ і ўсе яго логі з галіны Applications and Service Logs > Microsoft > Windows. Хоць заўсёды можна пайсці больш дубляломным шляхам і проста забраць усе аб'екты з %SystemRoot%System32winevtLogs.
Калі ў вас нешта ламаецца падчас усталёўкі/апгрэйду, тое ўсё неабходнае можна знайсці ў тэчцы %ProgramData%/Veeam/Setup/Temp. Хоць не буду хаваць, што ў івэнтах Восі можна знайсці больш карысную інфу, чым у гэтых логах. Пакінутае цікавае ляжыць у % Temp %, але там у асноўным логі ўсталёўкі спадарожнага софту, накшталт базы, бібліятэк. Net і іншага. Улічыце, што Veeam ставіцца з msi, і ўсе яго кампаненты таксама ўсталёўваюцца як асобныя пакеты msi, нават калі гэта не было адлюстравана ў GUI. Такім чынам, калі інсталяцыя аднаго з кампанентаў пацярпела няўдачу, уся інсталяцыя VBR будзе спынена. Таму трэба ісці ў логі і глядзець, што менавіта зламалася і ў які момант.
І лайфхак напрыканцы: атрымаўшы памылку пры ўсталёўцы, не спяшаецеся націскаць ОК. Спачатку забіраем логі, потым ціснем ОК. Дык вы атрымаеце лог, які сканчаецца ў момант памылкі, без смецця ў канцы.
І бывае так, што трэба залазіць у логі vSphere. Заняткі вельмі няўдзячныя, але, закасаўшы рукавы, даводзіцца рабіць і не такое. У найпростым варыянце нам спатрэбяцца логі з івэнтамі віртуалкі vmware.log, якія ляжаць побач з яе .vmx файлам. У больш складаным выпадку адчыняны гугл і пытаем, дзе ляжаць логі для вашай версіі хаста, бо VMware любіць гэтае месца змяняць ад рэлізу да рэлізу. Вось, напрыклад, , а вось для . Для логаў vCenter паўтараем працэдуру . Але ў агульным выпадку нам будуць цікавыя логі івэнтаў хаста hostd.log, івэнты хастоў пад кіраваннем vCenter vpxa.log, логі ядра vmkernel.log і логі аўтэнтыфікацыі auth.log. Ну і ў самых запушчаных выпадках можа спатрэбіцца лог SSO, які ляжыць у тэчцы SSO.
Грувастка? Заблытана? Страшна? А бо гэта нават не палова інфармацыі, з якой працуе наш сапарт на штодзённай аснове. Так што яны сапраўды вельмі крутыя.
Кампаненты Veeam
І ў якасці завяршэння гэтага ўступнага артыкула трохі пагаворым аб кампанентах Veeam Backup & Replication. Бо калі шукаеш прычыну боляў, нядрэнна было б разумець, як уладкованы пацыент.
Такім чынам, як напэўна вядома ўсім, Veeam Backup – гэта так званае SQL-based прыкладанне. Гэта значыць усе наладкі, уся інфармацыя і наогул усё, што толькі неабходна для нармальнага функцыянавання - усё гэта знаходзіцца ў яго базе. Дакладней, у двух базах, калі мы гаворым пра звязак VBR і EM: VeeamBackup і VeeamBackupReporting, адпаведна. Так і павялося: ставім яшчэ адно прыкладанне - з'яўляецца яшчэ адна база. Каб не захоўваць усе яйкі ў адной карыне.
Але каб уся гэтая гаспадарка працавала зладжана, нам спатрэбіцца набор сэрвісаў і прыкладанняў, якія звяжуць усе кампаненты разам. Выключна для прыкладу, вось так гэта выглядае ў адной з маіх лабараторый:
У ролі галоўнага дырыжора выступае Veeam Backup Service. Менавіта ён адказвае за абмен інфармацыяй з базамі. Таксама ён адказвае за запуск усіх заданняў, займаецца аркестрацыяй рэсурсаў і працуе гэткім цэнтрам камунікацый для разнастайных кансоляў, агентаў і ўсяго іншага. Словам, без яго сапраўды ніяк, але гэта зусім не значыць, што ён робіць усё сам.
У выкананні задуманага яму дапамагае Veeam Backup Manager. Гэта не сэрвіс, а сутнасць, якая займаецца запускам джоб і сачыльная за працэсам іх выканання. Рабочыя рукі backup service'a, якімі ён падлучаецца да хастаў, стварае снапшоты, сочыць за рэтэншэнам і гэтак далей.
Але вернемся да спісу сэрвісаў. Veeam Broker Service. З'явіўся ў v9.5 (і гэта не майнер крыпты, як тады падумалі некаторыя). Займаецца зборам інфармацыі аб VMware хастах і падтрыманнем яе актуальнасці. Але не бяжыце адразу пісаць гнеўныя каментары, што мы за вамі шпіёнам і зліваем усе лагіны/паролі тащмайору. Усё некалькі прасцей. Калі вы запускаеце бекап, то перш за ўсё трэба падлучыцца да хаста і абнавіць усе дадзеныя аб яго структуры. Гэта даволі павольная і грувасткая гісторыя. Проста ўспомніце, колькі ў вас доўжыцца аперацыя лагіна праз вэб інтэрфейс, і падушыце, што тамака лічыцца толькі верхні пласт. А потым яшчэ трэба ўсю іерархію расчыніць да патрэбнага месца, дарэчы. Словам, жах. Калі вы запускаеце дзясятак бекапаў, значыць, кожнай джобе трэба прарабіць гэтую працэдуру. Калі размова аб вялікіх інфраструктурах, то гэты працэс можа заняць хвілін дзесяць і больш. Таму было прынятае рашэнне вылучыць пад гэта асобны сэрвіс, праз які можна будзе атрымліваць заўсёды актуальную інфармацыю. Ён пры старце правярае і скануе ўсю дабаўленую інфраструктуру, а потым імкнецца працаваць толькі на ўзроўні інкрыментальных змен. Так што нават калі ў вас будзе запускацца адначасова сто бекапаў, яны ўсё запытаюць інфармацыю ў нашага брокера, а не будуць мучыць хасты сваімі запытамі. Калі хвалюецеся за рэсурсы, то па нашых падліках на 5000 віртуалак трэба ўсяго каля 100 Mb памяці.
Далей у нас ідзе Veeam Console. Ён жа Veeam Remote Console, ён жа Veeam.Backup.Shell. Гэта той самы GUI, які мы бачым на скрыншотах. Усё проста і відавочна – кансоль можна запускаць адкуль заўгодна, абы гэта быў Windows і была сувязь да VBR сервера. Адзінае, што можна сказаць: FLR працэс будзе мантаваць кропкі лакальна (г.зн. на машыну, дзе запушчана кансоль). Ну і разнамасныя Veeam Explorers таксама будуць запускацца лакальна, бо яны частка кансолі. Але гэта мяне ў нетры ўжо панесла...
Наступны цікавы сэрвіс - Veeam Backup Catalog Data Service. У спісе сэрвісаў вядомы як Veeam Guest Catalog Service. Займаецца індэксаванне файлавых сістэм на гасцявых машынах і напаўняе гэтымі ведамі тэчку VBRCatalog. Выкарыстоўваецца толькі там, дзе ўключана галачка індэксацыі. А уключаць яе ёсць сэнс, толькі калі ў вас ёсць Enterprise Manager. Таму рада ад усёй душы: не ўключайце індэксацыю проста так, калі ў вас няма ЯМ. Паберажыце свае нервы і час саппорта.
Таксама з іншых важных сэрвісаў варта адзначыць Veeam Installer Service, з дапамогай якога адбываецца дастаўка і ўстаноўка неабходных кампанентаў на проксі, рэпазітары і іншыя гейтвеі. Фактычна, ён адвозіць патрэбныя .msi пакеты на серверы і праводзіць іх усталёўку.
Veeam Data Mover - з дапамогай якія запускаюцца на проксях (і не толькі) дапаможных агентаў займаецца перакладваннем дадзеных. Напрыклад, пры бекапе адзін агент будзе чытаць файлы з датастары хаста, а другі - іх старанна запісваць у бекап.
Асобна хочацца адзначыць важную рэч, на якую часта рэагую кліенты - гэта рознасць версій сэрвісаў і інфармацыі ў аснастцы Programs and Features. Так, спіс будзе аднолькавы, а вось у версіях можа быць поўны раздрай. Гэта не вельмі выдатна з візуальнага пункту гледжання, аднак цалкам нармальна, калі ўсё працуе стабільна. Напрыклад, у Installer сэрвісу нумар версіі моцна адстае ад суседніх. Жах і кашмар? Не, бо ён не пераўсталёўваецца цалкам, а проста абнаўляецца яго DLL. У патчы v9.5 U4 адбыўся страшны сон тэхпадтрымкі: пры абнаўленні ўсе сэрвісы атрымалі новыя версіі, акрамя самага галоўнага. У патчы U4b транспартны сэрвіс абагнаў усе астатнія ажно на дзве версіі (калі судзіць па лічбах). І гэта таксама нармальна - у ім была знойдзена сур'ёзная бага, таму ён атрымаў бонуснае абнаўленне адносна астатніх. Таму, падводзячы вынік: розніца версій можа быць праблемай, але калі розніца прысутнічае, а ўсё працуе спраўна, то хутчэй за ўсё так і трэба. Але ніхто вам не забараняе ўдакладніць гэта ў тэхпадтрымцы.
Гэта былі так званыя абавязковыя ці Mandatory services. А ёсць яшчэ цэлы пачак дапаможных, такіх, як Tape Service, Mount Service, vPowerNFS Service і гэтак далей.
Для Hyper-V у цэлым усё тое ж самае, толькі ёсць спецыфічны Veeam Backup Hyper-V Integration Service і свой драйвер для працы з CBT.
І ў канцы пагаворым, хто працуе на віртуалка падчас бекапа. Для запуску pre- і post-freeze скрыптоў, для стварэння шэдаў копі, збору метададзеных, працы з логамі SQL транзакцый і іншага выкарыстоўваецца Veeam Guest Helper. І калі адбываецца індэксацыя файлавых сістэм, Veeam Guest Indexer . Гэта часовыя сэрвісы, якія разгортваюцца на час бекапа і выдаляныя пасля яго.
У выпадку Linux машын усё нашмат прасцей з-за наяўнасці вялікай колькасці ўбудаваных бібліятэк і магчымасцяў самой сістэмы. Напрыклад, індэксінг робіцца праз mlocate.
На гэтым пакуль усё
Не смею вас больш мучаць і кароткае уводзіны ў подкапотное прастору Veeam лічу скончаным. Так, мы нават блізка не дайшлі да саміх логаў, але паверце, каб інфармацыя, прадстаўленая ў іх, не здавалася няскладным струменем прытомнасці, такі ўступ цалкам сапраўды неабходна. Перайсці да саміх логаў я планую толькі ў трэцім артыкуле, а план на наступны - растлумачыць, хто генеруе логі, што менавіта ў іх адлюстравана і чаму менавіта так, а не неяк інакш.
Крыніца: habr.com