Наверняка я вам не открою Америки рассказом о том, что логи назвали логами из-за судовых журналов, куда записывали всякое интересное (и не очень), что происходило на корабле во время плавания. (Возможно, некоторые из вас не знают, но по воде ходят именно корабли, а судно — это в больнице. Хотя тут показания расходятся.)

Но не об этом мы сегодня. Сегодня мы поговорим о структуре логов в Veeam Backup & Replication, об их названиях и ожидаемом содержимом. Список будет большим, но не исчерпывающим, ибо всё описать — задача практически невозможная.

Как же подойти к процессу описания? Как вариант, можно рассказать, что некоторые логи лежат в папочках, а некоторые без папочек. Но это и так понятно, стало быть - малоэффективно. Поэтому давайте начнём с незамысловатого факта, что мы в Veeam стараемся называть логи максимально прозрачно и придерживаться единой системы наименования. Так что начнём мы с не с грустных папочек, а с привязки логов к типам джоб. И первым делом рассмотрим довольно очевидный

Backup Job

Итак, логи любой уважающей себя джобы лежат в отдельной папке, повторяющей её название из GUI Veeam. Кстати, если в гуе это название изменить, то папка с логами не переименуется, ибо человекочитаемые названия — тлен, а id в базе вечны.

У любой джобы всегда и везде есть её самый главный лог, именуемый для простоты джобнОй лог (чистой воды жаргонизм, уж простите) Job.<job name>.Backup. В него уходит вся общая информация: когда запустилось, какие прокси назначены, что там с ретеншн, чем всё закончилось в конце, и всё такое прочее.

Любая добавленная в джобу виртуалка обрабатывается в рамках отдельной таски. Поэтому вся информация, относящаяся к обработке отдельной машины, пишется в отдельный лог Task.<vm name>.<vm id> Это позволяет избежать нечитаемого фарша в одном файле и разбираться с каждой отдельной машиной в случае провала. Из интересного можно отметить, что vm id сильно отличается от того, как машина была добавлена в джобу. Возможно, не все знают, но в инфраструктуре VMware каждый считает своим святым долгом выдать свой уникальный id виртуалке. Поэтому одна и та же машина будет иметь уникальный номер на уровне ESXi, другой уникальный номер — на уровне vCenter, третий уникальный номер — на уровне vCloud, и так далее. Поэтому понимать, на каком уровне абстракций вы находитесь, крайне важно. В случае Hyper-V всё проще — там всегда будет огромный GUID.

Далее идут агентские логи. Каждый агент выполняет свою некую маленькую задачу, позволяя в итоге случиться полноценному бекапу. Например, Agent.<job name>.Index - это логи агента, отвечающего за индексирование файлов, если в джобе была отмечена соответствующая опция. Если галочки нет, то лог файл создаваться не будет.

Немного примеров других агентских логов:

• Agent.VddkHelper В этом логе отмечаются API вызовы, запрещающие и разрешающие vCenter мигрировать машину во время бекапа. 

Сейчас самое время запомнить простое правило: если в названии лога есть слово Source, значит, это лог агента, который что-то откуда-то читает. Если видим в названии лога слово Target, значит, это лог агента, который что-то куда-то записывает. В большинстве случаев работают они в паре и позволяют однозначно идентифицировать, где именно болит. Если сорсной агент не может прочитать данные, то не надо искать проблему на стороне репозитория.

• Agent.<job name>.Source.<vm name> Логи агента, который занимается чтением файлов конфигурации машин участвующих в бекапе. VMX, VMXF, NVRAM - для VMware, или XML - для Hyper-V.

• Agent.<job name>.Source.<vm name>.Hotadd.Attacher Как намекает название, это логи агента, который работает с дисками в Virtual Appliance режиме. Причём, если в процессе бекапа будет принято решение о смене режима на сетевой (если выбрана соответствующая опция), название файла не изменится. Также стоит отметить, что в данный момент диски с одной машины обрабатываются последовательно, поэтому лог тоже последовательный, и сочинять отдельный файл для каждого диска нет смысла.

• Agent.<job name>.Source.<vm name>.<disk name> То же, что и выше, только про SAN/network режимы. Лог живёт непосредственно на машине с ролью прокси.

• Agent.<job name>.Target Очень важный лог таргетного агента, в котором фиксируются события, связанные с открытием, чтением, записью файлов бекапов во время работы джобы. Если используется опция Per-vm, то у каждой машины в джобе будет свой отдельный лог в формате

• Agent.<jobname>.Target.<vm name>.<vm id> Логи эти пишутся на репозитории и/или гейте.

• Agent.<job name>.CtpTransfer.Client/Server Логи агента, отправляющего/получающего Changed Block Tracking данные, полученные от нашего драйвера.

• Agent.<job name>.Target.Repair  Если в процессе прохода джобы она потерпела неудачу (по любой причине), необходимо удалить с репозитория всё, что она успела туда записать. Эти операции логируются здесь.

• Agent.<job name>.Client/Server или Agent.<job name>.Transform.<vm name>.Target/Source.<repo name>  Логи от любимых всеми синтетических операций. Rollback, transform и прочие synthetic full фиксируются здесь.

Также есть небольшая порция специфических логов, которые появляются при работе с Hyper-V:

• SnapshotCreator/SnapshotImporter Логи, связанные с VSS снапшотами. Есть смысл читать только вместе с Windows events.

• HvWmiProxy-<HV host name> Логи отправляемых WMI запросов

• Agent.<job name>.CtpTransfer.Client/Server  Если используется наш драйвер для отслеживания изменённых блоков, то его работа фиксируется здесь.

• Agent.<job name>.Source.<vm name>.CONFIGVMCX В Hyper-V 2016 произошёл уход от человекочитаемого XML формата при описании конфигурации машин в сторону бинарного VMCX. Однако со старым форматом тоже надо уметь работать. Агент делающих это отчитывается в этом файле.

• Agent.<job name>.Source.<vm name>.CONFIGVMRS Тоже реверанс в сторону 2016 года, когда VRMS хранил в себе данные о рантайме вируталок.

Replication Job

Это были бекапы. А что с репликами? С ними всё то же самое. Только лог джобы будет называться Job.<job name>.Replica, а не .Backup. В остальном логика и названия будут ровно такие же, как и у бекапов. Хотя будет лукавством говорить, что у реплик нет ничего своего. Конечно, есть:

• Например, появляется лог Agent.<job name>.Digests.Target, где содержится отчёт о создании метаданных реплики. Как вы, конечно же, помните, сама реплика хранится где-то на сторе вашего хоста. А вот метаданные от неё лежат уже в нашем репозитории.

• Agent.<job name>.Repair.log Как известно, Veeam периодически проводит внутренние проверки блоков данных — забекапленного и реплицированного. Если будут обнаружены какие-то повреждения, то последует попытка спасти потерянные блоки. Штука на самом деле важная и полезная, а лог её работы лежит в этом файле.

• Agent.<job name>.Target.<vm name>.<disk name> Лог таргетного агента, где хранится информация про запись данных на диски реплики.

• И закончим на Agent.<job name>.Digests.Repository, посвящённом хранению метаданных.

Уверен, что вы уже поняли идею общей структуры логов. Всегда есть общий лог джобы. У него есть саб-логи тасок, где ведутся записи про каждую отдельную машину из джобы. Без тени сомнения могу сказать, что логи тасок несут в себе максимум полезной информации для решения большинства проблем. Но “большинства” не значит “всех”. Поэтому рядом с ними будут лежать логи агентов, которые делятся на сорсные и таргетные. Понимание этой незамысловатой структуры позволит вам детально разобраться с происходящим в любой вимовской джобе. Другой вопрос, что информация в логах может быть технически сложной, но про это будет в следующей статье. И не забываем, что некая часть логов оставляется агентами на бекапируемой/реплицируемой машине. И если проблема была на передающей стороне, искать её надо в логах сорсных агентов на соответствующей машине (читай прокси).

Ну а мы продолжаем.

Restore/Failover

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

• IR.<vm name>.Mount/Dismount Нетрудно догадаться, IR означает Instant Recovery, а Mount/Dismount посвящены процессам монтирования машины из бекапа на продакшн сторадж и отпусканием бекапа в конце восстановления.

• Vm.<vm name>.FileRestore Соответственно, логи восстановления файлов виртуалки.

• Agent.<vm name>.FilesRestore.Client/Server Логи процесса копирования данных из бекапа в датастору. Опять же, разделены на два файла: один за источник, второй за приёмник.

• Vm.<vm name>.Restore Появится, когда нам надо восстановить всю машину целиком.

• А Vm.<vm name>.HddRestore - если восстановить нужно конкретный диск. И, по аналогии, рядом будет Agent.<vm name>.VmHardDisksRestore.Client/Server

Если речь идёт про фейловеры реплик, то самое интересное будет в следующих файлах со структурой Agent.<vm name>/<replicaname>.Failback.VddkAccessor. То есть главное — не перепутать, о чьём логе речь: реплики или оригинальной машины.

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

Standalone Logs

Как нетрудно догадаться, здесь поговорим про логи, не лежащие в какой-то особенной папочке, а расположенные прямо в корне логохранилища Veeam. Сделано это в основном по причине того, что они несут в себе информацию про какие-то общие процессы, и делать под каждый такой лог свою папку — занятие странное. Хотя, положа руку на сердце, иногда всё же хочется подумать над группировкой, ибо если просто начать перечислять всё, что может лежать в папке C:\ProgramData\Veeam\Backup, то это будет больше двух страниц (проверено). Поэтому давайте самостоятельно немного сгруппируем логи по смыслу. 

Вот есть целая группа логов, начинающихся с Svc. Это логи наших сервисов.

• Svc.VeeamBackup.log  Лог того самого Veeam Backup Service, без которого ничего работать не будет. Поэтому в него приходит довольно много информации: расписание джоб, распределение ресурсов, отслеживание внутренней коммуникации между модулями, и так далее, и тому подобное. Тот редкий случай, когда в лог что-то постоянно пишется без перерывов на обед и сон.

• Svc.VeeamBES.log То же самое, но это самый важный лог уже для Veeam Enterprise Manager

Дальше всё просто и понятно. 

• Svc.VeeamInstaller.log Фиксирует все действия Veeam Installer Service (aka Veeam Deployment service) 

• Svc.VeeamCatalog.log Содержит в себе записи о работе сервиса индексации гостей. 

• Svc.VeeamInstallerDll.log Поскольку Installer Service также проводит некоторые операции с файловой системой (проверка свободного места, поиск файлов, создание VBM и т.д.), было решено записывать эти события в отдельный лог. К слову, это единственный сервис, который приходится разворачивать через админскую шару и SCM. Все остальные устанавливаются уже с его помощью.

• Svc.VeeamHvIntegration В этом логе фиксируется информация об операциях создания VSS снапшотов и взаимодействия с нашим проприетарным драйвером. Часть про VSS снапшоты одинакова  с VeeamVssSupport.log файлом на гостевой машине. А поскольку у Hyper-V Integration сервисы работают в пассивном режиме, от них остаются только ответы на запросы.

• Svc.VeeamWANSvc.log Логи WAN Accelerator сервиса. Лог пишется на обеих сторонах канала связи.

• Svc.VeeamTransport.log Фиксирует работу Veeam Backup Proxy сервиса.

• Svc.VeeamTape.log Здесь находится всё что связано с Remote Tape Server.

• Svc.VeeamRestAPI.log Лог RESTfullAPI реквестов.

• Svc.VeeamNFS.log. Та самая магия, которая позволяет ESXi хостам монтировать виртуалки прямо из бекапов. Используется для FLR, IR, SureBackups и прочих Other-OS File Recovery.

Есть сервис — должен быть отдельный лог. Или даже несколько, если так удобней.

Так же имеется плеяда агентских логов.

• Agent.<vm name>.DeleteVm Появляется если удалить из бекапа на репозитории машину. Backups>Disk>Выбрать джобу>Выбрать  VM>Delete from Disk 

• Agent.DynGroupMount  Агент отвечающий за монтирование динамических дисков.во время Windows FLR, например.

• Agent.NfcCommander.Client/Server В этом логе фиксируются операции c VMFS вольюмами: чтение конфигурации, удаление/создание директорий и файлов. Используется при IR, Failover и Other OS FLR.

• VeeamAgent.FileOperation.Client/Server.log В том или ином виде есть во многих подпапках. Хранит информацию о таких операциях как File Copy Job, экспорт логов и ещё нескольких.

А вот логи инструментов работающих с инфраструктурой убрали в отдельную папку \Utils\

• Util.CatCleanup  Лог, ведущийся тулой Catalog Synchronization. Проверяет соответствие информации в VBRCatalog и реальных бекапов.

• Util.HvCtpScanner Тула, проверяющая актуальность содержимого .ctp файлов, в которых содержится информация об измененных блоках внутри VHD дисков. Один файл на один диск. Адепты VMware vSphere могли видеть то же самое в .ctk файлах.

• Util.VeeamBackupConfiguration.Restore Логи восстановления базы данных самого VBR.

• Util.VmBackupValidate Этот лог создаётся, если руками запустить Veeam.Backup.Validator.exe. Проверяет целостность блоков данных на уровне хранилища.

• Util.DatabaseResynchronizer Это уже не отдельный лог, а полноценная папка с логами процесса синхронизации базы данных и фактического содержимого бекапных репозиториев.

• Util.VolumesHostDiscover Другая полноценная папка, где хранятся логи так называемых Volumes Discovery тасков. Этот процесс проверяет диски, подключенные к прокси серверам, на предмет возможности их использования в качестве точки монтирования при ресторе элементов приложений.

 И, конечно же, есть гора логов-одиночек.

• Job.DatabaseMaintenance Раз в неделю Veeam проводит обслуживание своей базы: дефрагментирует индексы, удаляет ненужные данные, и так далее. Завершается это всё перезапуском основного сервиса.

• VeeamBackupMksConsole Фиксирует информацию про открытие окна консоли машин, запущенных в рамках SureBackup.

•  RTS.ResourcesUsage.log Здесь хранятся записи планировщика ресурсов всех компонентов Veeam.

• VeeamShell Всё, что происходит в GUI, оставляет свой отпечаток здесь

• PowerShellInvokerWrapper<SCVMM FQDN> Лог связи между Veeam сервером и SCVMM

• VeeamBackupManager Логи менеджера, запускающего джобы и таски. Практически вся информация записывается в соответствующие логи, так что здесь мало чего остаётся. Однако, где-то это надо фиксировать.

Логи по папочкам

И есть ещё логи, которые напрямую к бекапам не относятся, однако свою отдельную папочку заслужили по разным причинам.

• %Something% Explorer Логи от одного из AIR (Application-Item restore) визардов. Active Directory, SQL, Oracle и так далее.

• ResourceScan, Чтобы поддерживать в актуальном виде информацию о состоянии бекапной инфраструктуры, Veeam с определённой периодичностью сканирует всё, что к нему было подключено. 

• BackupConfigurationJob Логи джобы, бекапящей конфиг самого Veeam сервера (по сути, делающей дамп базы).

• Console Информация о запусках консоли от разных пользователей. Информация внутри поделена на разные логины, однако учтите, что лог хранится на той машине откуда, запускалась консоль, а не на самом VBR сервере.

• EvacuateBackupsJob Появляется при эвакуации бекапов с SOBR репозитория.

• Exportlogs Логи визарда, собирающего логи для сапорта. Да, это логи на логи =)

• Filefromtaperestore Удивительно, но тут живут логи восстановления файлов с лент.

• FLRSessions Практически вся информация про FLR и Other OS ресторы.

• Import_job Логи процесса импорта бекапов

• NfsDatastore Всё, что связано с работой vPower NFS, фиксируется здесь

• Satellites Своих спутников на орбите, к сожалению, у нас пока нет, однако есть несколько вспомогательных процессов, разгружающих GUI. Следы этих процессов будут в этой папке.

На этом пока всё. Повторюсь: это даже приблизительно не полный список логов и папок с ними. Как вы могли убедиться, логи пишутся буквально на каждый чих. Такова уж специфика софта, обеспечивающего защиту ваших данных. А поскольку функционал Veeam Backup&Replication невероятно огромен, то и логи генерируются в олимпийских количествах. И помимо таких очевидных вещей, как простой запуск бекапа/реплики, есть ещё фоновые задачи, такие как Health Check, например. И они тоже генерируют свои логи, дабы в случае аварии всегда можно было максимально подробно восстановить картину мира и понять, что мешает успешной работе.

Поэтому основная цель, которую я перед собой ставил —  это показать на примерах, как происходит именование файлов и как выглядят логи самых часто используемых функций. Надеюсь, всё получилось, и если нелёгкая заставит вас открыть %ProgramData%/Veeam/Backups, то вы сможете сориентироваться в этом море названий. А в следующей статье мы уже наконец-то перейдём к азам чтения самих логов. Поговорим про общие правила, которых надо придерживаться, и научимся вычленять базовую информацию.