в какой папке лежат логи

Кроме этого поддерживается подсветка синтаксиса, дополнение по табу и разные полезности в статусной строке. К недостаткам можно отнести нестабильность поведения и зависания. Надеюсь lnav будет активно развиваться, очень полезная программа на мой взгляд.

Источник

Veeam Log Diving: компоненты и глоссарий

Мы в 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 есть неплохое KB. И мы тоже как-то про них писали на Хабре.

Datastore (Стора или сторадж): Очень широкое понятие, однако в мире виртуализации под ним понимают место, где хранятся файлы виртуальных машин. Но в любом случае тут надо очень чётко понимать контекст и при малейших сомнениях уточнять, что именно ваш собеседник имел в виду.

Proxy (Прокси): Важно сразу понять, что Veeam Proxy — это не совсем тоже самое, к чему мы привыкли на полях интернета. В пределах продуктов от Veeam это некая сущность, которая занимается перекладываем данных из одного места в другое. Если не вдаваться в подробности, то VBR — это командный сервер, а прокси — это его рабочие лошадки. То есть прокси — это машина, через которую течёт трафик и на которой установлены компоненты VBR, которые помогают этим трафиком рулить. Например, перекладывать данные из одного канала в другой или просто цеплять к себе диски (HotAdd mode).

Repository (Репозиторий): Технически это просто запись в базе VBR, указывающая на место, где хранятся бекапы, и как к этом месту подключиться. Фактически это может быть как просто CIFS шара, так и отдельный диск, сервер или бакет в облаке. Опять же, находимся в контексте, но понимаем, что репозиторий — это просто место, где лежат ваши бекапы.

В документации и логах 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. Что, конечно же, категорически неверно, однако это история из разряда «Любой внедорожник можно назвать джипом, и тебя поймут».

Фантастические логи и места, где они обитают

Хочу начать эту главу с раскрытия великой тайны — какое время отображается в логах?

Вариант первый подходит, если вы не горите желанием выискивать в общей куче файлы, относящиеся именно к вашей беде. Для этого у нас есть отдельный визард, которому можно указать конкретную джобу и конкретный период, за который вам нужны логи. Далее он сам пробежится по папочкам и сложит всё необходимое в один архив. О том, где его искать и как с ним работать, подробно написано в этой КВ.

Однако визард собирает логи не всех заданий и, например, в случае необходимости изучить логи рестора, фейловера или фейлбека путь ваш лежит в папку %ProgramData%/Veeam/Backup. Это главное логохранилище VBR, а %ProgramData% является скрытой папкой и это нормально. Кстати, место по умолчанию можно переназначить с помощью реестрового ключа типа REG_SZ: LogDirectory в ветке HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam 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%\System32\winevt\Logs.

И лайфхак напоследок: получив ошибку при установке, не торопитесь нажимать ОК. Сначала забираем логи, потом жмём ОК. Так вы получите лог, заканчивающийся в момент ошибки, без мусора в конце.

Громоздко? Запутано? Страшно? А ведь это даже не половина информации, с которой работает наш саппорт на ежедневной основе. Так что они действительно очень круты.

Компоненты 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 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.

В случае Linux машин всё намного проще из-за наличия большого количества встроенных библиотек и возможностей самой системы. Например, индексинг делается через mlocate.

Источник