Volumes and Disks

В рамках миграции данных с одной СХД на другую понадобилось мигрировать и разделы с репликами DPM. В самом DPM есть средства миграции, и они даже работают, но как я уже говорил - DPM = problem, поэтому надо бы как-то проконтролировать, а действительно ли все тома с данными переехали куда надо. Казалось бы, что может быть проще - открыть Disk Manager, да посмотреть, какой том на каком диске. Не в этот раз - DPM плодит тома самостоятельно, и их столько, что проверять это все в рукопашную рехнешься.
Что делать? Нужно как-то получить список вида VolumeID - DiskID. Встроенные средства Win2012 просто так это сделать не позволят, но есть интересная утилитка от SysInternals под названием DiskExt, которая и выдает нужные нам данные. Одна беда - вывод ее является голым текстом, который еще надо будет парсить. Кусок этого вывода ниже:

Volume: \\?\Volume{af0aef03-0821-11e7-80b4-806e6f6e6963}\
   Mounted at: unmounted
   Extent [1]:
       Disk:   0
       Offset: 1048576
       Length: 367001600
Volume: \\?\Volume{fc90d1ab-271d-4bf4-abef-9f6053e00b96}\
   Mounted at: Z:\
   Extent [1]:
       Disk:   2
       Offset: 135266304
       Length: 107236818944
Volume: \\?\Volume{816516e8-a6b7-11ed-810d-1c98ec18d20a}\
   Mounted at: C:\Program Files\Microsoft System Center 2012 R2\DPM\DPM\Volumes\Replica\File System\vol_514b32d1-b1d4-4a4e-b980-a5251c7b357f\
   Extent [1]:
       Disk:   6
       Offset: 61396860534784
       Length: 12719226880
   Extent [2]:
       Disk:   6
       Offset: 46517483208704
       Length: 13946060800000

Вывод прост - нужен парсер. Готовых нет, отсюда следует второй вывод - пишем самостоятельно. Код ниже,а еще ниже - описание того, что нам накодировано.

$output = @()
$datafile = "C:\diskext.txt"

$data = (get-content -path $datafile) -join ";"

$VolumeNamePattern = '^.+?(?=\<img src="/picture/1136.gif" alt=";)" class="smile_img">'
$VolumeMPPattern   = '(?<=Mounted at<img src="/picture/3.gif" alt=":)" class="smile_img">.+?(?=\<img src="/picture/1136.gif" alt=";)" class="smile_img">'
$Diskpattern       = '(?<=Disk<img src="/picture/3.gif" alt=":)" class="smile_img">.+?(?=\<img src="/picture/1136.gif" alt=";)" class="smile_img">'
$OffsetPattern     = '(?<=Offset<img src="/picture/3.gif" alt=":)" class="smile_img">.+?(?=\<img src="/picture/1136.gif" alt=";)" class="smile_img">'
$LengthPattern     = '(?<=Length<img src="/picture/3.gif" alt=":)" class="smile_img">.+?(?=\;|$)'

$VolumeBlocks = $data -split("Volume: ") | where {$_ -ne ""}

foreach ($Volumeblock in $VolumeBlocks) {
    $VolumeObject = ""
    $ExtentsObject = @()
    $VolumeObject = New-Object -TypeName PSCustomObject -Property @{
        VolumeName = [regex]::Match($VolumeBlock, $VolumeNamePattern).Value.Trim()
        VolumeMP   = [regex]::Match($VolumeBlock, $VolumeMPPattern).Value.Trim()
        Extents    = ""
    }
    
    $ExtentBlocks = ($Volumeblock -split "Extent \[.\]:" | select -Skip 1).trim()
    
    foreach ($ExtentBlock in $ExtentBlocks) {
        $ExtentsObject += New-Object -TypeName PSObject -Property @{
            Number = $ExtentBlocks.IndexOf($ExtentBlock)+1
            Disk   = [regex]::Match($ExtentBlock, $Diskpattern).Value.Trim()
            Offset = [regex]::Match($ExtentBlock, $Offsetpattern).Value.Trim()
            Length = [regex]::Match($ExtentBlock, $LengthPattern).Value.Trim()
        }
    }
    $volumeObject.Extents = $ExtentsObject
    $output += $VolumeObject
}
$output | select VolumeName, VolumeMP, Extents

Как это всё безобразие работает?

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

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

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

@музыка: Ronan Hardiman - Breakout

@темы: PowerShell, Scripting, DPM

---

DPM Error (?!)

DPM, ну ты и твааааааарь!

ИЧСХ, если в том окне перейти на вкладку Errors - она будет пустой.

Разгадка в том, что эта тварина считает, что если сервер, на который устанавливался агент DPM, после установки требует перезагрузку (а это происходит, наверное, всегда), то такая ситуация расценивается как ошибка во время установки. Много, очень много непечатного...

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

---

DPM is busy...

Что-то в последние недели количество записей про Data Protection Manager в единицу времени прямо зашкаливает. Ну а как иначе, если эта зараза подкидывает все новые и новые пляски с бубном. Или без него, как повезет.

Ситуация. Пытаюсь в консоли DPM добавить новый агент. Совершенно рутинная операция, в которой если что-то смогло пойти не так, то это целое событие. Так и случилось - консоль выдала "Ой, у вас нет соединения с контроллерами домена, на которых я могла бы проверить информацию о добавляемом агенте". ШТА?

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

В общем - пока работает этот скрипт, DPM больше ничего не может делать. Почему блокируется работа с AD - ума не приложу. Хорошо хоть, что на время работы скрипта не прерываются задачи по резервному копированию, это было бы уже совсем за гранью добра и зла.

@музыка: L'Avenue - Business Talk

@темы: DPM

---

DPM - SQL permissions

DPM = Problem. Хотя я не совсем справедлив. В этот раз проблема крылась не в самом DPM, а в другой сущности. Но обо всем по-порядку.

Задача - есть некая база данных, с которой нужно снимать бекап по всем правилам - и полный, и инкрементальный. Полный бекап проходит без проблем, а инкрементальный валится с ошибкой. Причем валится с ошибкой вида Unexpected error. Ну и само собой зубодробительный код 0х800....., по которому в поиске нет ничего.

Начинаем, как и всегда, ковырять логи. Логи сервера говорят о том, что, сюрприз, Logs was backed up. Но при этом у меня нет доступа до СУБД на этом сервере, и логи оттуда я посмотреть не могу. ОК, пинаем нашего DBA. По его словам все замечательно, логи бекапятся, в свойства базы данных в графе Date logs was backed up значится текущая дата. Получается интереснейшая ситуация - бекап проходит, но по каким-то причинам не передается в DPM!

Ок, открываем лог агента DPM этого сервера. И видим там просто прекрасное:

438C  4D1C  09/16 11:40:59.352      31    sqlbackuphelper.cpp(481)     [00000000035EF210]      97949482-4497-498A-A59F-8EEDACB91C9C     NORMAL      CSqlBackupHelper::BackupLogToDisk BACKUP LOG [%DBNAME%] TO DISK = N'%path_to_ldf%\Backup\Current.log'
438C  4D1C  09/16 11:40:59.493      03    sqlqueryhelper.cpp(194) [00000000035EE680]      97949482-4497-498A-A59F-8EEDACB91C9C     NORMAL      CoCreateInstance called with deafault SQLNCLI11, hr=0
438C  4D1C  09/16 11:40:59.508      31    sqlbackuphelper.cpp(406)     [00000000035EF210]      97949482-4497-498A-A59F-8EEDACB91C9C     NORMAL      Executing SQLQuery RESTORE VERIFYONLY FROM DISK = N'%path_to_ldf%\Backup\Current.log'
438C  4D1C  09/16 11:40:59.508      03    sqlqueryhelper.cpp(305) [00000000035EE680]      97949482-4497-498A-A59F-8EEDACB91C9C     WARNING     SQL - ICommandText::Execute of "RESTORE VERIFYONLY FROM DISK = N'%path_to_ldf%\Backup\Current.log'" - Failed 
438C  4D1C  09/16 11:40:59.508      03    sqlqueryhelper.cpp(349) [00000000035EE680]      97949482-4497-498A-A59F-8EEDACB91C9C     WARNING     SQL - Error Description "VERIFY DATABASE is terminating abnormally."
438C  4D1C  09/16 11:40:59.508      03    sqlqueryhelper.cpp(362) [00000000035EE680]      97949482-4497-498A-A59F-8EEDACB91C9C     WARNING     Failed: Hr: = [0x80040e14] SQL - sql code = 3013 (Errorlevel - 0)
438C  4D1C  09/16 11:40:59.508      03    sqlqueryhelper.cpp(370) [00000000035EE680]      97949482-4497-498A-A59F-8EEDACB91C9C     WARNING     SQL - Detailed Description "VERIFY DATABASE is terminating abnormally."
438C  4D1C  09/16 11:40:59.508      03    sqlqueryhelper.cpp(362) [00000000035EE680]      97949482-4497-498A-A59F-8EEDACB91C9C     WARNING     Failed: Hr: = [0x80040e14] SQL - sql code = 262 (Errorlevel - 1)
438C  4D1C  09/16 11:40:59.508      03    sqlqueryhelper.cpp(370) [00000000035EE680]      97949482-4497-498A-A59F-8EEDACB91C9C     WARNING     SQL - Detailed Description "CREATE DATABASE permission denied in database 'master'."
438C  4D1C  09/16 11:40:59.508      31    sqlbackuphelper.cpp(412)     [00000000035EF210]      97949482-4497-498A-A59F-8EEDACB91C9C     WARNING     Error executing SQL Query. Details: VERIFY DATABASE is terminating abnormally.
438C  4D1C  09/16 11:40:59.508      03    sqlqueryhelper.cpp(307) [00000000035EE680]      97949482-4497-498A-A59F-8EEDACB91C9C     WARNING     Failed: Hr: = [0x80040e14] : Encountered Failure: : lVal : hr
438C  4D1C  09/16 11:40:59.508      31    sqlbackuphelper.cpp(408)     [00000000035EF210]      97949482-4497-498A-A59F-8EEDACB91C9C     WARNING     Failed: Hr: = [0x80040e14] : RESTORE VERIFYONLY FROM DISK = N'%path_to_ldf%\Backup\Current.log': lVal : sqlQueryHelper.Execute(ssQuery, &sqlErrorInfo)
438C  4D1C  09/16 11:40:59.508      05    fsmtransition.cpp(111)  [000000000104ABB0]      97949482-4497-498A-A59F-8EEDACB91C9C     WARNING     Failed: Hr: = [0x80990d1b] HasEventErrorCode: completion: 0xa105, signature: 0xaabbcc00

Ключевыми в этой простыне будут следующие сообщения:

Executing SQLQuery RESTORE VERIFYONLY FROM DISK = N'%path_to_ldf%\Backup\Current.log'
Execute of "RESTORE VERIFYONLY FROM DISK = N'%path_to_ldf%\Backup\Current.log'" - Failed
SQL - Detailed Description "CREATE DATABASE permission denied in database 'master'."

Открываем мануал! (с) А в мануале на самом technet сказано, что начиная с SQL 2008 выполнение команды RESTORE VERIFYONLY требует наличия у выполняющего прав CREATE DATABASE, потому что проверка восстановимости из снятого бекапа идет как раз через создание временной таблицы.

Теперь прикидываем. Агент DPM работает от учетной записи Local System. Получается, что сама система не может в себе же базы создавать? В принципе, ничего из ряда вон выходящего, так бывает очень часто. Ладно, кидаем всю накопленную информацию тому самому DBA, он выдает учетной записи NT AUTHORITY\LOCAL SYSTEM право CREATE DATABASE...

И все заработало. Бекапы снимаются, проверяются, передаются в DPM. Всё как и должно быть.

Всегда бы так.

@музыка: E.S. Posthumus - Nara

@темы: DPM

---

DPM + SQL / T-logs = Problem

Недавно я отмечал, что DPM - синоним слова "проблема". Лишний раз убедился в этом, только на этот раз в связке с серверами SQL. Бекапить SQL-базы можно по-разному. Можно сделать полный бекап всего, и делать его раз за разом. Долго, много места. Можно делать полный бекап, а за ним цепочку инкрементов. По времени будет гораздо эффективнее, хотя процедура восстановления будет слегка сложнее, чем просто развернуть полный бекап. Запись немного о другом.

Мониторинг выкинул предупреждение - на SQL-сервере на системном диске кончается место. Посмотрели, реально заканчивается, 15% от всей емкости. При этом ничего нового на серваки не ставилось. Ок, windirstat в зубы и смотрим, куда место ушло. А ушло оно под базу данных. Оставлю вопрос о том, почему база была на системном разделе (сам прекрасно знаю, что так не делается). Смотрим, что там место скушало. Оказалось, распух ldf-файл. Но позвольте, у нас же бекапы настроены. Каждый день эти базы бекапятся, и без ошибок. Значит, логи должы были отсекаться.

И вот тут на сцену выходит DPM:

В терминологии DPM синхронизация - это и есть инкрементальный бекап, во время которого отсекается журнал транзакций. Любой, повторюсь, любой админ настройки синхронизации в этом окне читает следующим образом: мне дают выбор - делать инкрементальный бекап через равные промежутки времени, либо делать каждый раз прямо перед снятием полного бекапа (которым является Express Full Backup, но это в приближенном виде, на практике чуть сложнее). И проблема в том, что на самом деле работает все не так! Ни в одном абзаце документации по DPM не сказано, что если выбрать в данных настройках значение Just before recovery point, DPM не будет делать бекап логов транзакций. Вместо этого он стащит с сервера SQL изменившиеся блоки в файле самой БД, сольет их с репликой на сервере DPM, после чего на основе получившихся данных сделает очередную точку восстановления. Хотите нормальные инкрементальные бекапы - ставьте регулярную синхронизацию через определенные интервалы времени, это единственный вариант.

В сухом остатке проблему с распухшими логами решили так. Сняли полный бекап базы (бекапов много не бывает), затем саму базу перевели на использование модели восстановления Simple. Затем штатная операция Shrink на файле журналов, который тут же ужался до каких-то 4-5 мегабайт. После чего база снова переводится на обычную для нее модель восстановления Full, а в настройках DPM создается новая группа защиты, в которой указана синхронизация каждые 2 часа. После этого создается новая реплика базы, по расписанию проходит синхронизация логов, и вуаля - мониторинг радостно верещит, что проблем с местом больше нет. Ну и в идеале надо бы запланировать перенос базы на другой раздел. Негоже данным болтаться на системном диске.

Уважаемые сотрудники компании MS (хотя что это я, уважением там давно уже не пахнет). До каких пор вы будете плодить в своем хваленом ПО настолько обидные косяки, что просто диву даешься, как ЭТО проходит какой-либо контроль качества. Да ладно, я задам другой вопрос - у вас в принципе QA еще осталось хоть в каком-то виде? Или ваши пресловутые эффективные манагеры разогнали эти отделы окончательно? Вашу же гребаную американскую мать, одумайтесь!

@музыка: Midnight Danger - Terror by Night

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

---

DPM Replica is inconsistent

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

И вот где-то в апреле мне во время очередного разбора полетов попалась на глаза статья, где предлагалось чинить не сам файловик, а именно реплику. Потому что проблема может быть на ее стороне. DAFUQ?!, подумал я
тогда. Это же реплика, там ничего никогда не делается без ведома самого DPM, какие там могут быть проблемы? С другой стороны - во многих аспектах DPM это синоним слова "проблема", а поскольку других вариантов нет, почему-бы и не попробовать. Тем более, что админам это не стоит ничего, а пользователи вообще ничего не заметят, работа будет проходить на сервере резервного копирования, а не на файловике. Каково же было удивление, когда это сработало. Система, действительно, исправила ошибку внутри тома с репликой, после чего запуск задачи на синхронизацию реплики с источником данных дал нужный результат - Sync OK. Что ж, алгоритм действий был таким:

1. Определяем том, где лежит пораженная реплика. Для этого в DPM открываем свойства источника данных по ссылке Replica Path: Click to view details. Нам покажут окно с примерно следующей информацией:

D:\ on FS1.DOMAIN.COM c:\Program Files\Microsoft System Center 2012 R2\DPM\DPM\Volumes\Replica\File System\vol_48342fb3-5e1f-43b9-b1a3-641aea404c23\8b28e1f0-0e38-4c4c-a1b8-af5881f4a4bf\Full\

Из этого всего нам нужен путь. А если точнее - кусок пути от начала строки до конца сегмента vol_..., в нашем случае это будет выглядеть так:

c:\Program Files\Microsoft System Center 2012 R2\DPM\DPM\Volumes\Replica\File System\vol_48342fb3-5e1f-43b9-b1a3-641aea404c23

Именно по этому пути DPM будет искать реплику при любых операциях с оной.

2. Исходя из найденного пути нужно определить, на каком томе лежит нужная нам реплика. Тут все просто - mountvol. Выводим список всех точек подключения и смотрим, где появится найденный путь. Наша цель - идентификатор тома примерно такого вида:
\\?\Volume{GUID}

3. После того, как найден том с репликой, выполняем проверку этого тома на наличие ошибок и их коррекцию:
chkdsk /f \\?\Volume{GUID}
Процесс займет какое-то время, после чего в результате получаем стандартный вывод команды chkdsk о том, что система нашла проблемы в структуре файлов внутри реплики и исправила их.

4. Финальный шаг - синхронизация отремонтированной реплики с источником данных. Штатная команда самого DPM, расписывать которую здесь смысла нет.

В результате всего этого безобразия получаем рабочую реплику, восстановление работоспособности задач по резервному копированию и заслуженное право сказать "Я сегодня хорошо поработал, могу идти домой".

Однако, есть еще кое-что, чего хотелось бы избежать. Правильно, слишком много ручной работы. А потому пришла мысль обернуть все это (ну или почти все) в powershell-скрипт. На входе он принимает путь к файлам с репликой (все та же строка вида c:\Program Files\Microsoft System Center 2012 R2\DPM\DPM\Volumes\Replica\File System\vol_48342fb3-5e1f-43b9-b1a3-641aea404c23\8b28e1f0-0e38-4c4c-a1b8-af5881f4a4bf\Full\, а на выходе отдаст сообщение:
Use: chkdsk /f \\?\Volume{найденный GUID}

После чего уже запускаем проверку реплики и синхронизацию.

Скрипт ниже. Надеюсь, кому-то он будет полезен.

$ReplicaPath = read-host "Input replica path"

if ($ReplicaPath) {
    $ReplicaPath -match "^(.*?)vol_[a-zA-Z0-9-]+"
    if ($matches) {$ReplicaVolume = $matches[0]}
    else {"No replica path given";break}

    $Volume = ((get-wmiobject win32_volume | where {$_.name -like "*$ReplicaVolume*"}).DeviceID).trimend("\")

    Write-host "Use: chkdsk /f $volume"
} 
else {
    write-host "No replica path!"
    break
}

@музыка: Midnight Danger - The Last Day

@темы: PowerShell, DPM