В этой статье я приведу примеры методов сбора отладочной информации для HPE Data Protector.

Куда собираются отладочные данные

Начнем с определения того, куда складываются отладочные данные. Это очень важный вопрос, т.к. при использовании высокого уровня отладки их объем может запросто переполнить файловую систему. К тому же по умолчанию они не сжимаются и я на практике видел как для одной сессии резервного копирования их накапливается более 100 Гбайт за пару часов при уровне отладки равным пятиста.

То, куда будут складываться файлы отладки определяется переменной OB2DBGDIR, которая находится в файле конфигурации omnirc. Сам файл omnirc (или его шаблон, если никто ещё не менял значения системных переменных) находится вот здесь:

Итак, если в файле omnirc никто не менял значение переменной OB2DBGDIR, то отладочные файлы будут собираться сюда:

Также имейте ввиду, что отладочные данные собираются не только на сервере резервного копирования, но и на клиентах и media серверах задействованных в отладочной сессии. Т.е. если Вы запустили в режиме отладки сессию резервного копирования, то файлы отладки будут собраны на сервере резервного копирования, клиенте, media агенте. На каждом из серверов будут содержаться отладочные данные характерные для компонентов, которые на нём запускались.

Методы сбора отладочных данных

Существует как минимум три способа сбора отладочных данных в HPE Data Protector. Каждый из них по-своему удобен в различных ситуациях.

1. С использование Data Protector Manager (GUI).
2. Запуск сессии через консоль с указанием дополнительных опций отладки.
3. Добавление отладочных параметров в расписание резервного копирования.

Data Protector Manager (GUI)

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

Включается отладка следующим образом:

1. В GUI Data protector Manager выбираем пункт меню File > Preferences…
2. В окне настроек переходим на вкладку Debugging
3. Указываем уровни отладочных сообщений (например 1-500), указываем суффикс имен отладочных файлов.
4. Выбираем до какого момента данные опции должна действовать — постоянно или только на время работы следующей GUI сессии.

Данные изменения вступят в силу только с момента действия следующей GUI сессии, поэтому нажимаем кнопку «Relaunch GUI now…» и выполняем процедуру во время которой происходит нечто, требующее сбора отладочных данных.

Запуск сессии из консоли с указанием дополнительных опций

С подавляющем большинством консольных команд Data Protector, которые описаны в CLI Reference Guide можно использовать дополнительную опцию «-debug». Синтаксис этой опции следующий:

-debug 1-999[,gz][,C:n][,T:s][,U] postfix [host]

Приведу несколько примеров использования этой опции для запуска различных сессий резервного копирования:

Пример 1. Internal Database

Необходимо запустить в режиме отладки сессию полного резервного копирования (full) внутренней базы данных Data Protector. Спецификация сессии называется dpcm.demo.local_idb. Требуемый уровень отладки 1-500, максимальный размер одного файла отладки — сто мегабайт (102400 KiB). Для файлов отладки необходимо включить компрессию (gzip). Суффикс файлов отладки — idb_case_0.

omnib -idb_list "dpcm.demo.local_idb" -barmode full -debug 1-500,C:102400 idb_case_0.txt

Пример 2. СУБД Oracle

Необходимо запустить в режиме отладки сессию полного резервного копирования (full) внутренней базы данных СУБД Oracle. Спецификация сессии называется de-onec-db_ora. Требуемый уровень отладки 1-500, максимальный размер одного файла отладки — сто мегабайт (102400 KiB). Для файлов отладки необходимо включить компрессию (gzip). Суффикс файлов отладки — idb_case_0.

omnib -oracle8_list de-onec-db-ora -barmode=full -debug 1-500,gz oracle_case_0.txt "de-onec-db.demo.local dpma-de.demo.local"

Пример 3. Файловая система Windows

Необходимо запустить в режиме отладки сессию инкрементального резервного копирования файловой системы windows сервера. Имя сервера: win-prod-15, том с данными D:, метка тома «Data». Резервное копирование выполнить на устройство «FLN1_W2». Уровень отладочных сообщений «1-200», размер каждого отладочного файла до 10 MiB, точность временных метод выводить до миллисекунд. Отладочные данные собирать только на сервере win-prod-15.

omnib -winfs win-prod-15.local:"/D" "D: [Data]" -device "FLN1_W2" -mode incremental -protect none -debug 1-200,C:10240,T:1000 winfs_debug_0.txt win-prod-15

Добавление отладочных параметров в расписание

При большом желании опции отладки можно добавить в параметры планировщика заданий резервного копирования. Этот способ работает только для старого классического планировщика задач (legacy scheduler), он не работает для advanced scheduler и для нового планировщика, который появился в версии 10.0. Формат тот же, что и при использовании консольных утилит, поэтому сложностей возникнуть не должно. Достаточно добавить строку с отладочной опцией в качестве первой строки в файл с расписанием. Например так:

Сами файлы с расписанием для «старого» планировщика заданий находятся здесь: