Попробую собрать в кучу все свои мысли по поводу давешнего скрипта подсчета доступных лент на серверах 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 текущей ленты, "живая" информация находится на других лентах, а значит, точку восстановления на текущей ленте можно пометить как просроченную.
Вот именно последних двух шагов ранняя версия скрипта и не делала. И именно этим обусловлены расхождения в результатах. Щелкание кнопок, дописывание соответствующего кода, тестовый прогон на нескольких "подозрительных" лентах - результаты что в скрипте, что в консоли - идентичны. Прогон на нескольких серверах - все прекрасно.

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