• ↓
  • ↑
  • ⇑
 
Записи с темой: dpm (список заголовков)
16:02 

DPM - Available Tapes #3 - Case Closed

Stance Dance

В топку. В топку тот скрипт, который мне дался таким потом и кровью. А все почему - потому что с точки зрения управления лентами чере Powershell DPM еще та дрянь. Простой пример: лента с одной (всего одной) точкой восстановления, для которой назначено больше чем одна Recovery Goal (ну то есть для данной точки восстановления есть бекап бекапа - вторая копия этой информации). Powershell для этой ленты говорит: Recovery Point status - Expired. Открываем содержимое той же самой ленты в GUI-консоли - бааа, да эта лента сдохнет только через пару недель. И самое паскудное - верная информация все же в консоли.

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

@музыка: Iron maiden - Heaven can wait

@настроение: не самое безоблачное, столько сил впустую

@темы: Scripting, PowerShell, DPM

20:34 

DPM - Restore job failure

Stance Dance

Понадобилось тут восстановить случайно грохнутую папку на DFS-шаре. Shadow Copy использовать по некоторым причинам возможности нет, стало быть, придется обращаться к старым добрым бекапам. Сказано, сделано. DPM - Консоль - Восстановление - выбрать сервер - выбрать объект - восстановить в исходное расположение. Казалось бы - все просто. А вот ничерта не просто:

An existing connection was forcibly closed by the remote host (0x80072746)

И так каждый хренов раз. Ни перезапуск задания, ни перезапуск бекапера, ни перезапуск целевого сервера, чтобы обрубить "висящие" коннекты, если такие есть... Ничего не спасает. Интернет просто ломится от рекомендаций по редактированию реестра в случае такого сообщения при бекапе. Но не при восстановлении. Ожидаемо, что эти игры с реестром тоже ни к чему не привели. Ладно, шара эта лежит на DFS, а в DFS не один сервер, пробуем восстановить с резервной копии сервера-партнера. Восстановилось. Поскольку дело было ночью, а голова уже туго соображала, отложил до утра.

С утра начали мозговой штурм. Заметили странность. При первой попытке восстановления на целевой сервер удалось переслать чуть больше 2 Гб инфы, после чего соединение тушилось, но во всех последующих - десяток килобайт, и гуляйте, друзья-товарищи. Коллега, который больше моего возился с целевым файловиком тут-то и предположил - а что у нас с квотами на раздел, где эта папка лежала? Проверили - так и есть. Срабатывала жесткая квота, и сервер просто отрубал все коннекты для записи новый файлов на шару. Да твою же..... материнскую плату! Подняли квоту, дождались DFS-репилки с сервера-партнера. Case closed.

@музыка: The Offspring - Cruising California (Bumpin' In My Trunk)

@темы: DPM

02:32 

DPM - Available Tapes #2 - In depth

Stance Dance

Попробую собрать в кучу все свои мысли по поводу давешнего скрипта подсчета доступных лент на серверах Data Protection Manager.
Итак, что у нас имеется. Имеется жутко тормозная консоль, которая представляет в сводной таблице сведения о доступных лентах в неудобном формате: Free Tapes и Expired Tapes. Штука в том, что Free Tapes отражает общее количество доступных лент, включая просроченные (expired). И в то же время если докапываться до подробностей - сам же DPM различает эти сущности - Free и Expired. Для именно свободных лент целый пул есть, который так и называется - Free. В скрипте он фигурирует, там, где подсчитываются пустые ленты. Вот этот формат вывода информации тоже хотелось бы поменять на более вменяемый - X доступных лент, из которых Y пустых и Z просроченных.

Собственно, с подсчетом пустых лент сложностей никаких. Взять все ленты, которые есть в данный момент в библиотеке, да выбрать из них те, что принадлежат к пулу Free. Невеликого ума задача. С просроченными дело обстоит куда сложнее (ну и интереснее, теперь я уже могу это сказать).

Что такое просроченная лента? Это кассета, на которой истекло время хранения всех бекапов. Отдельного признака Tape Expired (или чего-то подобного) у объекта Tape не нашлось, стало быть, придется опрашивать непосредственно ленты. Ну, не сами ленты, конечно же, а сведения о них в базе данных DPM. ОК, выбираем все ленты, не принадлежащие к пулу Free, и относящиеся к типу "Архивная лента" (иначе в выборку попадут чистящие кассеты, а это нам не нужно). А потом в цикле просматриваем их содержимое:

Get-RecoveryPoint -Tape $Tape

С этого момента начался мой персональный ад. Когда-то давно использовался найденный на просторах интернета скриптик, который и занимался подсчетом лент, как свободных, так и просроченных. Да вот беда, неделю назад нашлось расхождение между тем, что показывает этот скрипт, и тем, что показывает сам DPM. А именно - консоль показывает ленту как просроченную, а скрипт утверждает, что на ней еще есть "живые" бекапы, и затирать ленту нельзя. Более того, лента "сдохнет" только через месяц, который, к слову, уже почти истек. Вот эту чертовщину и нужно решить.

Хорошо, давай смотреть, что у нас на такой проблемной ленте лежит. Там лежат такие же бекапы, что и везде, они прекрасно видны через Get-RecoveryPoint. We need to go deeper... Берем один из таких бекапов (они называются точками восстановления в терминах DPM) и изучаем его под микроскопом:

Get-RecoveryPointLocation -RecoveryPoint $RP

Команда выдает нам тучу объектов, которые technet называет RecoveryPointLocation, в скрипте они обозваны как RSL- RecoverySourceLocation (и не спрашивайте, почему так, я сам не до конца разобрался, что меня заставило именно так их назвать). Как я понял - это карта размещения данных в точке восстановления на кассете. И уже с вот этими объектами связаны временные метки, когда точка восстановления была сделана, когда она сдохнет, там даже отдельное поле есть - Validity. Собственно, прошлый скрипт именно на это поле и смотрел, но делал это как-то странно: он смотрел только на первую такую запись. Если она просрочена - помечал всю точку восстановления как сдохшую. И шел себе дальше.

Казалось бы, все просто - исправив пару строк пройтись в цикле по всем этим записям, и если не найдется ни одного вхождения Validity = Valid, точка восстановления должна быть признана сдохшей. Как только попадется хоть одна запись вида Validity = Valid, точку восстановления помечаем как живую и прекращаем ее обработку, перейдя к следующей. Вот тут-то расхождение в показаниях и раскрылось: на ленте куча RSL, для которых поле Validity = Valid. Но консоль же эту ленту так же упорно видит как просроченную. И вот-вот ее затрет, лишив возможности разобраться окончательно.

В попытках рассмотреть под микроскопом уже сами RSL я себе чуть не сжег остатки мозга и глаз. Везде сплошные IDшники и ничего более, буквы и цифры чуть ли не снились. Подключил коллегу, который те бекапы и настраивал. Смотрим вместе с ним, видим поле Generation. Далее диалог двух уже основательно окосевших от обилия буквенно-цифровой информации людей:

- Стоп. Поколения, это что еще за хрень?
- Ыы, там отцы и сыновья. А может ли это быть бекапом бекапа?
- Хм. Может. У нас же настроено копирование с ленты на ленту. Давай сравним поколения и временные метки.


Эх, счастье было так возможно, так близко. Но нет, для разных RSL на той ленте были "живыми" и сыновья, и отцы. Нашлись все варианты комбинаций Father/Son, Valid/Expired. То есть так просто по полю Generation тоже не отфильтруешь. Но ведь консоль это как-то делает! Да и мысль о "бекапах бекапов" покоя все не дает.

$RSL | Get-member

Покажи мне, что еще есть у этих записей. Та же куча IDшников, но в свете обсуждения копий лент глаз резанул параметр MediaMapList. Это уже интереснее. Берем одну RSL и заглядываем в нее. А там... А там ни что иное, как список ID лент, на которых лежат копии этой самой точки восстановления. Вот оно! Картина вырисовывается такая:
- берется лента, на ней читаются точки восстановления.
- берется точка восстановления, читаются все объекты RSL.
- если во всех объектах RSL в поле Validity стоит Expired - проблемы нет, лента просрочена.
- если в какой-то RSL в поле Validity видим Valid, нужно определить, что именно еще не умерло: запись на этой самой ленте, или информация на совершенно другой ленте (тот самый бекап бекапа).
- смотрим на параметр MediaMapList и получаем оттуда ID всех лент, задействованных для этой RSL.
- если среди всего там имеется ID текущей ленты, "живая" информация лежит на именно этой ленте, и значит, всю ленту помечать как просроченную нельзя. Если же среди найденного нет ID текущей ленты, "живая" информация находится на других лентах, а значит, точку восстановления на текущей ленте можно пометить как просроченную.
Вот именно последних двух шагов ранняя версия скрипта и не делала. И именно этим обусловлены расхождения в результатах. Щелкание кнопок, дописывание соответствующего кода, тестовый прогон на нескольких "подозрительных" лентах - результаты что в скрипте, что в консоли - идентичны. Прогон на нескольких серверах - все прекрасно.

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

@музыка: Земля Ветров - Моя земля (для разнообразия)

@темы: PowerShell, DPM

16:42 

DPM - Available Tapes

Stance Dance

Когда-нибудь я распишу этот скрипт, и то, что он делает, очень подробно. Но не сейчас. Сейчас лишь ограничусь тем, что он собирает данные по доступным лентам в ленточных накопителях. Доступные - значит свободные для записи. В эту категорию попадают как пустые ленты, так и те, на которых истекло время хранения всех точек восстановления. Этот скрипт, вроде бы и небольшой, сожрал мне мозг начисто. Но он работает. Медленно, но работает, причем не вступает в противоречие с консолью DPM, а именно это меня и бесило больше всего.

Но как бы то ни было - задача выполнена.

@музыка: Nigel Stansord - Deep Space

@настроение: Бобер - выдыхай!

@темы: DPM, PowerShell

22:44 

DPM - Active Tasks List

Stance Dance

MS DPM - штука такая, за ней глаз да глаз нужен. Точнее, не за ней самой, а за одним типом задач - System State Protection. Частенько бывает так, что такая задача зависнет на пять-шесть часов, и только почем зря занимает ресурсы сервера. Обычно в таком случае мы просто прерываем ее и запускаем заново. Полчаса - и бекап состояния системы готов. Но для того, чтобы задачу перезапустить, ее надо увидеть. А для этого нужно зайти на сам сервер DPM. А... Согласен, слишком много "А", но тем не менее: а консоль DPM - штука очень неторопливая, да и самих серверов далеко не одна штука. Заходить на каждый и смотреть, что там творится - да проще убиться веником. Powershell to the rescue!

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

@музыка: E-Mantra - I shall not care

@настроение: Neutral

@темы: Scripting, PowerShell, DPM

10:56 

MS Data Protection Manager - System State Backup

Stance Dance

Windows backup cannot create the diff area file on the volume specified to store the backup
При попытке сделать System State бекап вот такая дрянь появляется уже не первый раз. И дело тут вовсе не в работоспособности защищаемого сервера, дело в самом DPM, точнее, в том, как он работает. А работает он так же, как и установщик обновлений. Для распаковки архивных файлов, которые установщик получает с серверов Windows Update/WSUS, нужно место. Что делает установщик, если в системе есть несколько логических дисков? Правильно, выбирает из них тот, где больше всего места, и именно там плодить времянки. DPM делает ровно то же самое - ищет диск с наибольшим свободным местом, и именно там пытается собрать временный образ, который и является бекапом состояния системы. И именно этот образ на именно этом диске он собрать не может. В то же время если выполнить system-state-backup напрямую через wsb защищаемого сервера с сохранением состояния на тот же диск, с которого снимается состояние системы:

все проходит на ура.
Ну и как тогда заставить DPM работать по тому же принципу? А очень просто. Открываем файл C:\Program Files\Microsoft Data Protection Manager\DPM\Datasources\PSDataSourceConfig.xml, ищем там следующее:

Вот в этом параметре и надо прописать тот диск, куда система должна сбрасывать временный образ, то есть диск C:
После этого в самом DPM открываем нужное задание и запускаем его повторно. Оно пройдет без ошибок.
Пора уже новый тег вводить под записи о Data Protection Manager. Мало ли что...

@музыка: Eluveitie - Setlon

@настроение: Работа-работа-работа...

@темы: Этот безумный мир, DPM

19:15 

Data Protection Manager - Backup Statistics

Stance Dance

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

Task Scheduler, все дела. Затем создается связь в Excel на полученный txt-файл, и дело сделано. При желании можно расширить и на несколько площадок, чтобы вообще всю статистику получить.

@музыка: Philippe Alexandre Belisle - Impovisation

@настроение: клац-клац-клац

@темы: PowerShell, DPM, Scripting

17:46 

DPM 2012 Data Source Migration

Stance Dance

KnV-программирование, говорите? Их есть у нас. Точнее, не у нас, а в Редмонде. А еще точнее - в каком-нибудь из Соединенных Штатов Индии.
Есть два файловика-виртуалки. Есть у них диск D:, где все данные и лежат. Этот диск имеет свойство пухнуть, как и всякая файлопомойка. Размер VHD-файла с этим диском уперся в свой потолок в 2 Тб (старый vhd). А расширять надо. Ну что же, процедура следующая.
Внутри виртуалки-файлопомойки переводим этот диск в состояние Offline.
В консоли Hyper-V выносим нафиг файл vhd и на его месте создаем новый vhdx с требуемым объемом (vhdx поддерживает файлы больше 2 Тб).
Снова переходим в виртуалку. Находим там свежий диск, переводим его в состояние Online, инициализируем, форматируем, даем прежнюю букву, и говорим развернутой на этом сервере DFSR - а теперь, родная, реплицируй все данные с сервера-партнера. DFSR козырнула и пошла жрать файлы.

А тем временем начинает вопить DPM. Суть в следующем. Когда в DPM в группу защиты добавляем сервер и его какой-либо диск, диск этот идентифицируется не по букве, а по своему GUID (да, опять GUID, снова GUID). Когда файлопомойке дали новый диск, естественно сменился GUID этого диска. И теперь встает вопрос - что делать с группой защиты, как в нее добавить новый диск.

Можно вынести оттуда старый и добавить новый. При попытке провернуть такой фокус DPM вопит, что бекапы, связанные со старым диском, станут невалидными (то есть придется снимать заново полный бекап в те 2 терабайта, а это время).
Можно попытаться связать запись в группе защиты об этом диске с новым GUID диска. Вот это нам и нужно.

Для такого переноса существует специальный скрипт, написанный где-то в недрах MS, который называется Migrate-Datasource.ps1. Вот статья, объясняющая, что это и как оно работает.

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

Exception calling "MigrateDataSource" with "2" argument(s): "The remote
procedure call failed. (Exception from HRESULT: 0x800706BE)"

At C:\Program Files\Microsoft System Center 2012
R2\DPM\DPM\bin\Migrate-DataSource.ps1:220 char:10
+ $dpmServer.MigrateDataSource($newDataSourceId, $oldDataSourceId)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : COMException

Error in Migration

Хм, все веселее и веселее. Ладно, а что ты мне покажешь в ручном режиме? А в ручном режиме оно мне предложило выбрать запись о диске, которую надо исправить, вывело список всех дисков (их GUIDов), которые можно к нашей многострадальной записи подцепить. Этих дисков оказалась ровно 1 штука. И я не знаю, что меня дернуло просмотреть, а кому этот GUID принадлежит, но увиденное заставило отменить скрипт от греха подальше. Дело в том, что предложенный GUID принадлежал MSR-разделу файлопомойки.

Даа, делаа... Поскольку дело было уже поздним вечером, решили эту проблему отложить до утра, чтобы окинуть ее потом свежим взглядом. Вернулись к ней только спустя дня эдак 4. И что бы мы ни делали с этим скриптом, результатом всегда было только одно - предложение связать запись в группе защиты с MSR-партицией. Черт с ним, все равно приближается время полного бекапа, так что уже были готовы убить старую запись и добавить новую. Да не тут-то было:
- Народ, а вы гляньте на последнюю точку восстановления!
- Вчера сделалась? Но ведь бекап не работал?
- Андрюха, походу после этого твоего скрипта бекап все же починился.
И действительно, бекап-то шел, как и полагалось, создалась новая точка восстановления. То есть, источник данных все же мигрировал на новый диск. А теперь поднимаем глаза выше, снова читаем надпись Error in Migration.
Становится понятным, почему провалилась попытка ручной миграции. Потому что новый диск уже был связан с записью в группе защиты и не был доступным для этой операции, только и осталось, что бедную мелкую MSR предложить.

Вот такие индийские скрипты пишутся для Data Protection Manager 2012. Хорошо еще, что хотя бы они есть, тут подсказывают, что в предыдущих версиях нужно было непосредственно базу данных DPM препарировать...

В поднятой в целях теста лаборатории этот же скрипт в такой же ситуации отработал на все сто. Далее много-много непечатного, потому печатать не буду.

Симантек, я, помнится, тебя материл безбожно. Как тут не вспомнить старое-доброе: "Вася! Если сможешь - прости!!!"

@музыка: Metal Gear Rising OST - Denver

@темы: Scripting, PowerShell, DPM, Этот безумный мир

Записная книжка

главная