DPM: разбавим бекап скриптами.

Прекрасно, когда мы в состоянии использовать некоторые возможности DPM, чтобы сделать резервную копию приложения целиком (например, SharePoint или виртуальную машину Hyper-V). Однако, что делать, когда недостаточно просто взять system state, добавить к нему диск C, чтобы получить работоспособный бекап (например, OCS или Windows 2008 Bare Metal Recovery) или наша ферма MOSS 2007 сконфигурирована способом, делающим невозможным его бекап “в один клик” (некоторые сценарии SQL Mirroring ломают возможность такого бекапа)?

Что же… Именно здесь в игру могут вступить скрипты. Data Protection Manager позволяет, на самом деле, запускать скрипты до и/или после бекапа.Трудно ли это? Нет. Могу ли я рекомендовать для создания сложных, критических для бизнеса функций? Увы, тоже не стал бы рекомендовать это делать без крайней необходимости.

Давайте обсудим, почему:

1. Сложность. На самом-то деле, достаточно лишь разместить Ваши скрипты на локальном диске защищаемого компьютера и сделать правки в одном из конфигурационных файлов. причем скрипт может быть любым: шелл, VBS, PoSh, да хоть Perl. Например, скрипт для BMR-резервирования может выглядеть так:

@echo off
setlocal enabledelayedexpansion
set BACKUP_TARGET=\\BackupServer\ServerBackup
rd /s /q "%BACKUP_TARGET%\WindowsImageBackup\%computername%"
wbadmin start backup -backuptarget:"%BACKUP_TARGET%" -allcritical -quiet
if %ERRORLEVEL% == 0 (
rem    pushd "%BACKUP_TARGET%\WindowsImageBackup\%computername%"
rem    for /f "tokens=*" %%i in ('dir /b /s *.vhd') do move /Y "%%i"

)

(код почти из этого документа)

В любом случае, наиболее важная часть всей процедуры содержится в файле ScriptingConfig.xml, который обычно лежит в c:\Program Files\Microsoft Data Protection Manager\DPM\Scripting.

Содержимое этого файла по-умолчанию:

<?xml version="1.0" encoding="utf-8" ?>

  <ScriptConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.microsoft.com/2003/dls/ScriptingConfig.xsd">

   </ScriptConfiguration>

Что нам нужно, так это добавить немного дополнительных настроек внутрь тега <ScriptConfiguration>. В конечном счете файл будет выглядеть, например, вот так:

<?xml version="1.0" encoding="utf-8" ?>

<ScriptConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.microsoft.com/2003/dls/ScriptingConfig.xsd">

<DatasourceScriptConfig DataSourceName="c:">

  <PreBackupScript>"Path-To-Script or command line to run script"</PreBackupScript>

  <PostBackupScript />

  <TimeOut>90</TimeOut>

   </DatasourceScriptConfig>

  </ScriptConfiguration>

Все вполне очевидно, как можно видеть:

• DataSourceName – имя источника данных перед бекапом которого (или после него) нужно выполнить скрипт
• PreBackupScript – строка, которую необходимо выполнить перед резервным копированием
• PostBackupScript – строка, которую нужно выполнить после бекапа
• TimeOut – таймаут в минутах

Довольно несложно, не так ли?

2. Почему я не рекомендую использовать эту технику, если только Вы не нуждаетесь в ней чрезвычайно сильно? Ну… На самом деле, достаточно трудно судить, успешно ли было выполнение скрипта. Консоль DPM ничего не скажет Вам по этому поводу. Например, говоря о BMR для Windows Server 2008, мы можем бекапить, на самом деле, любой файл, присутствующий на файловой системе, предварив создание резервной копии скриптом, который запускает WBAdmin. Если сам файл будет скопирован успешно, то Вы получите зеленую галочку, невзирая на степень успешности резервирования BMR имиджа. Путями быть в курсе успешности бекапа могут быть:

• Сделать тестовое восстановление. (прекрасная идея, на самом деле, однако, предположите, что у Вас сотни серверов, с бекапом каждую неделю… Проверять их раз в 7 дней – mission impossible)
• Сделать скрипт достаточно сложным, чтобы он сам распознавал ошибки и рапортовал о них. Снова не самая худшая идея, однако, это полностью неуправляемая вещь, к тому же, превращающаяся в еще одну систему мониторинга, что не слишком хорошо сказывается на всяких там TCO
• Использовать сторонние инструменты третьих компаний

Впрочем, для некоторых задач это все еще великолепный инструмент.