Как преодолеть недостатки NTBackup с помощью сценариев

В Windows 2000 разработчики Microsoft усовершенствовали встроенную службу резервного копирования NTBackup и добавили возможности планирования и управления носителями. Хотя подобные обновления приветствуются, комментарии, обнаруженные мной на форумах поддержки и в сетевых конференциях, наводят на мысль, что многие администраторы и пользователи потерпели неудачу, пытаясь заставить службу NTBackup работать в своих сетях.

В нашей компании под Windows NT 4.0 изначально использовалась программа резервного копирования, созданная независимыми разработчиками, так как средство NTBackup, поставляемое с системой NT 4.0, не отвечало нашим потребностям. После того как мы перешли к работе с системами Windows Server 2003, я снова обратил внимание на службу NTBackup, пытаясь выяснить, является ли усовершенствованная версия достаточно мощной и можно ли автоматизировать ее работу, не прилагая больших усилий. В ходе этого исследования я обнаружил некоторые недостатки пакета NTBackup.

  • Не существует простого способа записать резервную копию на произвольную ленту, если не использовать параметр /um (unmanaged — неконтролируемый режим) в командной строке. Этот режим позволяет переписать произвольную ленту. Однако, когда служба NTBackup переписывает ленту в ходе резервного копирования, она всегда задействует новую метку устройства: или метку, указанную пользователем, или метку, сгенерированную на основе текущих даты и времени. Не существует встроенной возможности заставить службу NTBackup сохранить текущую метку и при этом переписать ленту.
  • Не существует простого способа добавить резервную информацию на установленную ленту, так как необходимо ввести в командной строке либо параметр /t (имя носителя), либо параметр /g (глобально-уникальный идентификатор, GUID). Неуправляемый режим не будет работать, так как можно добавлять информацию только на специальным образом указанную ленту.
  • Служба NTBackup не извлекает ленту после резервного копирования.
  • Служба NTBackup не может печатать или отправлять по почте отчеты о выполненной работе.

Чтобы избавиться от этих недостатков, я создал набор сценариев, состав которого отражен в табл. 1. Набор содержит основной сценарий и 13 вспомогательных.

Основной сценарий, Backup.cmd, использует службу NTBackup для выполнения резервирования, при котором происходит перезапись текущего носителя, но не меняется его метка тома. 13 вспомогательных сценариев реализуют различные функции для сценария Backup.cmd. Вместе эти сценарии составляют средство резервного копирования, с которым легко работать и которое легко настраивать по себя. Опыта написания сценариев для работы не требуется. Нужно просто пройти следующие этапы.

  1. Разобраться в предназначении каждого вспомогательного сценария, что позволит настраивать данное средство под свои потребности.
  2. Разобраться в том, как работает основной сценарий, чтобы иметь возможность настраивать его.
  3. Подготовить свое программное окружение и сценарии.

Этап 1. Функции вспомогательных сценариев

Сценарий Backup.cmd является скелетом процедуры резервирования, а 13 вспомогательных сценариев — это его мускулы. Рассмотрим особенности этих сценариев и оценим их вклад в конечный результат.

RSMView.cmd. Средство NTBackup управляет лентами и другими устройствами с помощью службы Removable Storage, которая опирается на базу данных в каталоге %SystemRoot%system32NtmsData. Вы можете использовать консоль RSM для управления службой Removable Storage. Одной из наиболее полезных команд RSM является команда Rsm View, которая позволяет просматривать объекты в базе службы Removable Storage.

Основной интерес здесь представляют объекты LIBRARY, PHYSICAL_MEDIA, PARTITION и LOGICAL_MEDIA, хотя объектная модель базы данных Removable Storage содержит и множество других типов объектов. Объект LIBRARY олицетворяет физическое устройство, использующее сменные носители. Нас интересуют ленточные приводы. Объект LIBRARY может содержать только объекты PHYSICAL_MEDIA, которые олицетворяют физические носители, в данном случае ленты. Объект PHYSICAL_MEDIA, в свою очередь, может содержать объект PARTITION, который символизирует раздел. В графическом интерфейсе пользователя чаще применяется термин сторона (side) чем раздел (partition), но оба термина означают одно и то же. Объект PARTITION может содержать лишь объекты LOGICAL_MEDIA, олицетворяющие логические разделы ленты.

Когда вы используете команду Rsm View для отображения содержимого объекта-контейнера (то есть объекта, содержащего другие объекты), необходимо указать этот объект посредством его идентификатора GUID. Сам идентификатор легко установить, используя одну из возможностей службы RSM. Когда применяется команда Rsm View с параметром /guiddisplay, служба RSM выдает список объектов с соответствующими идентификаторами GUID. Зная GUID, можно вырезать и вставлять идентификаторы в команду Rsm View. Вставка и вырезание множества идентификаторов не вызывает затруднений, но процесс многократной вставки и удаления идентификаторов может оказаться достаточно утомительным. Написание сценариев — отличный способ избавиться от этой задачи. Итак, сценарий RSMView.cmd управляет выполнением команды Rsm View в остальных сценариях. Вам не придется вставлять и вырезать отдельные идентификаторы GUID.

Library.cmd. Сценарий Library.cmd определяет имя ленточного привода и его GUID или только идентификатор ленточного привода. Когда запускается непосредственно сценарий Library.cmd, он выводит имя ленточного привода и его идентификатор. Эта информация полезна для отладки в случае сбоя в работе сценариев. Когда сценарий Backup.cmd запускает Library.cmd, последний возвращает лишь идентификаторы, так как сценарий Backup.cmd не использует имя привода.

PhysicalMedia.cmd. Сценарий Physica lMedia.cmd определяет имя рабочей ленты и идентификатор GUID физического носителя (то есть GUID физической ленты) или только идентификатор физического носителя. Когда пользователь запускает непосредственно сценарий Physical Media.cmd, он выводит имя ленты и ее идентификатор GUID. Когда сценарий Backup.cmd запускает Physical Media.cmd, PhysicalMedia.cmd возвращает только GUID.

Partition.cmd. Сценарий Partition.cmd определяет имя раздела и его GUID или только идентификатор раздела. Когда вы запускаете непосредственно сценарий Partition.cmd, он выводит имя раздела и идентификатор GUID. Когда сценарий Backup.cmd запускает Partition.cmd, Partition.cmd возвращает только GUID раздела.

MediaGUID.cmd. Сценарий Media GUID.cmd выводит GUID логического носителя рабочей ленты (то есть GUID локального раздела ленты), который используется параметром /g службы NTBackup. MediaGUID.cmd выводит идентификатор GUID в формате, необходимом службе NTBackup.

MediaName.cmd. Сценарий Media Name.cmd определяет метку тома ленты, которая появляется в поле Name панели Side диалогового окна Properties консоли Removable Storage. На экране 1 показан простой пример диалогового окна Properties. Backup.cmd использует метку тома, полученную сценарием MediaName.cmd, при работе с параметром /n службы NTBackup для повторного утверждения существующей метки тома при перезаписи ленты.

Нужно иметь в виду, что служба NTBackup использует поле Info, ссылаясь на ленты по их имени. Системы Windows 2003 и Windows XP автоматически записывают информацию из поля Name в поле Info. Однако в процессе тестирования Windows 2000 я обнаружил, что поле Name осталось пустым, и мне пришлось копировать метку из поля Info в поле Name. В любом случае, на панели Side поле Name должно совпадать с полем Info — иначе выполнение сценария MediaName.cmd будет прервано или приведет к ошибочным результатам.

Refresh.cmd. В зависимости от аппаратного обеспечения, служба RSM не всегда может определить наличие ленты в приводе. Таким образом, до запуска процесса резервного копирования важно выполнить операцию обновления, чтобы убедиться в актуальности того состояния ленточного привода, которое содержится в базе данных. Refresh.cmd определяет текущее состояние ленточного носителя. Если процесс обновления прошел успешно, сценарий Refresh.cmd использует приложение sleep.exe для приостановки выполнения, чтобы занести в базу данных актуальную информацию.

Eject.cmd. Сценарий Eject.cmd извлекает ленту после завершения резервирования. После этого сценарий запускает Refresh.cmd, чтобы убедиться в актуальности информации, содержащейся в служебной базе данных Removable Storage.

ShowLog.cmd. Сценарий ShowLog.cmd выводит на экран последний журнал службы NTBackup (то есть журнал, который вы видели в графическом интерфейсе GUI). Если запустить ShowLog.cmd с параметром /f, он выведет полный путь и имя файла журнала.

PrintLog.cmd. Сценарий PrintLog.cmd использует приложение Notepad для печати последнего журнала службы NTBackup. Перед запуском PrintLog.cmd необходимо настроить принтер, используемый по умолчанию. При использовании сценария PrintLog.cmd рекомендуется создавать сводные журналы.

MailLog.cmd. Сценарий MailLog.cmd использует приложение blat.exe для отправки по почте последнего журнала службы NTBackup определенному адресату (например, администратору). Программа Blat.exe является бесплатным служебным приложением, которое позволяет отправлять почтовые сообщения из командного сценария.

SetupVars.cmd. Сценарий Setup Vars.cmd определяет настройки ключевых переменных окружения в других сценариях. Такая схема позволяет с легкостью переносить сценарии на другие компьютеры. Требуется лишь изменить настройки в одном сценарии (то есть в сценарии SetupVars.cmd), а не во всех 13. На этапе 3 я расскажу о том, какие настройки необходимо поменять.

TapePrep.cmd. Когда у вас есть одна или несколько новых лент, которые нужно пометить и локализовать с помощью службы NTBackup, можно использовать сценарий TapePrep.cmd. Этот сценарий запускает службу NTBackup в бесконтрольном режиме. Сценарий создает метку ленты из заданного текста.

Вы запускаете TapePrep.cmd из командной строки, а не из другого сценария (например, сценария Backup.cmd), ведь его предстоит использовать для каждой ленты лишь один раз. Вот команда, запускающая сценарий TapePrep.cmd:

TapePrep media_label

где media_label — текст, используемый в качестве метки. Если текст содержит пробелы, необходимо заключить его в кавычки.

Этап 2. Принципы работы основного сценария

Как упоминалось выше, сценарий Backup.cmd запускает процесс резервирования, который переписывает рабочую ленту, не меняя при этом ее метку тома. Данный сценарий также напрямую или косвенно использует все остальные сценарии, за исключением TapePrep.cmd.

Листинг 1 включает текст сценария Backup.cmd. Метка A содержит переменные окружения, определяющие работу сценария. Чтобы использовать сценарий, необходимо настроить эти переменные, что и будет сделано на этапе 3.

После определения переменных Backup.cmd использует сценарий Refresh.cmd для обновления информации о ленточном приводе. Затем сценарий осуществляет три важные операции. Во-первых, Backup.cmd использует сценарий PhysicalMedia.cmd для контроля наличия ленты в приводе. Далее основной сценарий задействует MediaName.cmd для определения метки тома ленты. Наконец, Backup.cmd использует сценарий MediaGUID.cmd для определения идентификатора GUID логического раздела ленты.

Если все три операции выполнены успешно, сценарий Backup.cmd определяет переменную COMMAND, содержащую команду службы NTBackup, как показано в метке B листинга 1. Сценарий записывает команду службы NTBackup в файл журнала сценария (backup.log), после чего исполняет эту команду. После того как NTBackup закончит резервное копирование, Backup.cmd прописывает код завершения службы NTBackup в файл backup.log. Наконец, сценарий Backup.cmd проверяет переменные EJECT, MAILLOG и PRINTLOG, как видно из кода в метке C листинга 1. Если какая-либо из этих переменных имеет значение YES, Backup.cmd вызывает соответствующие сценарии.

Если какая-либо из трех операций не выполнена (то есть сценарий не может определить идентификатор GUID физического носителя, метку тома или идентификатор логического раздела), сценарий Backup.cmd вызывает подпрограмму :DIE, описанную в метке D листинга 1. Этот код выводит сообщение об ошибке, создает файл журнала ошибок error.log в каталоге данных службы NTBackup и прописывает выведенное сообщение в журналы error.log и backup.log. В зависимости от набора значений переменных MAILLOG и PRINTLOG, код также может отсылать по почте и/или выводить на печать файл журнала NTBackup, содержащий сообщение об ошибке.

Этап 3. Окружение и сценарии

Все 14 сценариев можно найти на сайте www.windowsitpro.ru в разделе downloads. После того как вы создали каталог, в котором будут содержаться сценарии (например, C:NTBackup), извлеките их в эту папку. Когда вы будете планировать процессы, использующие сценарии, не забудьте указать этот каталог в поле Start in для запланированной задачи.

Файл 44990.zip включает архив sleep.zip, содержащий приложение sleep.exe. Необходимо распаковать этот файл и поместить его содержимое в созданную папку. Чтобы иметь возможность после завершения процесса резервного копирования отправлять своему администратору по электронной почте файл журнала службы NTBackup, нужно приобрести приложение blat.exe. Этот файл можно загрузить с сайта http://www.blat.net. Данное средство не требует установки, записей в реестре или файлов поддержки. Следует просто поместить его в один каталог со сценариями.

После того как все файлы размещены, необходимо настроить сценарии SetupVars.cmd и Backup.cmd.

Настройка сценария SetupVars.cmd. Откройте сценарий SetupVars.cmd, приведенный в листинге 2, с помощью Notepad или другого текстового редактора. В коде по метке A (см. листинг 2) необходимо установить значения по меньшей мере двух переменных: RSM_LIBRARY и RSM_REFRESH. Если планируется использовать сценарий TapePrep.cmd, требуется также задать значение переменной RSM_POOL.

Значение переменной RSM_LIBRARY определяет имя вашего ленточного привода. Если вы не знаете или не уверены в этом имени, можно открыть окно командной оболочки и запустить команду

RSMView library

чтобы получить список библиотек системы. Потом нужно просто скопировать описательное имя (не путать с идентификатором GUID) в текст сценария SetupVars.cmd. Не нужно заключать описательное имя библиотеки в кавычки, если в нем присутствуют пробелы. Чтобы убедиться в правильности указанного имени, требуется набрать в командной строке следующую команду:

Library

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

( ) < > ^ & |

Если имя библиотеки содержит эти символы, их необходимо исключить. Для этого нужно сначала открыть консоль службы Removable Storage (в меню Start необходимо выбрать пункт Run и запустить файл ntmsmgr.msc, после чего щелкнуть OK). В левом окне нужно развернуть список Libraries (для систем Windows 2003 и XP) или список Physical Locations (для Windows 2000). Щелкните правой кнопкой мыши на ленточном приводе в левом окне и выберите пункт Properties. Удалите все запрещенные символы из текстового окна Name и нажмите OK.

В переменную RSM_REFRESH необходимо записать число секунд, на которое будет приостанавливать работу сценарий Refresh.cmd после обновления информации об устройстве. Это значение зависит от аппаратных характеристик системы — установите время, которое уходит на то, чтобы вставить и удалить ленту. Начать можно с 30 секунд.

Если планируется задействовать сценарий TapePrep.cmd, следует установить переменную RSM_POOL в значение, совпадающее с типом носителей, используемых имеющимся ленточным приводом. Например, если привод использует ленты Travan, в качестве значения переменной нужно ввести Travan:

Set RSM_POOL=Travan

Если значение содержит пробелы (например, 4mm DDS), не следует заключать его в кавычки.

Код по метке B листинга 2 определяет поведение системы после выполнения резервного копирования. Установка переменной EJECT в значение YES заставит сценарий Eject.cmd извлечь ленту. Установка переменной MAILLOG в значение YES приведет к отправке по почте сценарием MailLog.cmd журнала службы NTBackup определенному адресату. Установка переменной PRINTLOG в значение YES вызовет печать журнала NTBackup сценарием PrintLog.cmd на принтере, указанном по умолчанию.

Если переменная MAILLOG устанавливается в значение YES, необходимо также определить значения переменных в коде по метке C листинга 2. Если переменная MAILLOG устанавливается в значение NO, вам не нужно работать с этим кодом. В качестве значения переменной SMTPSERVER следует выбрать имя DNS или IP-адрес SMTP сервера в сети. В данном примере идентификация пользователей не применяется. Однако приложение blat.exe поддерживает механизм идентификации SMTP. Информацию о том, как организовать идентификацию, можно найти в документации к службе blat.exe. В переменной SENDER нужно задать почтовый адрес, который будет прописываться в поле From отсылаемых сообщений. В переменной RECIPIENTS следует указать адрес электронной почты, по которому необходимо отсылать сообщения. Можно указать более одного адресата, просто следует отделять адреса друг от друга запятой. Использование пробелов не допускается.

Не нужно ничего делать с оставшейся частью кода, в которой определяются константы ERR, переменные DTSTAMP и NTBACKUP_DATAPATH. Сценарий Backup.cmd использует переменную DTSTAMP для создания метки, на основе текущей даты и времени. Константы ERR определяют выходные коды сценариев. А переменная NTBACKUP_DATAPATH указывает на каталог данных службы NTBackup, содержащий файлы .bks (backup selection — списки резервного копирования) и файлы журналов.

Настройка сценария Backup.cmd. Откройте сценарий Backup.cmd с помощью Notepad или другого текстового редактора. В коде по метке A листинга установите в качестве значения переменной BACKUP имя каталога или список имен тех каталогов, с которых предстоит делать резервные копии. Имена каталогов разделяются пробелами. Если имя каталога содержит пробел, нужно заключить его в кавычки. С другой стороны можно указать файл .bks. Введите полное имя файла, предварив его префиксом ?@?, и, если имя содержит пробелы, заключите его в кавычки. Также для этой цели можно задействовать переменную NTBACKUP_DATAPATH. Например, если имя файла — Weekly full.bks, значение переменной BACKUP может выглядеть следующим образом:

«@%NTBACKUP_DATAPATH%Weekly full.bks»

В качестве значения переменной JOBNAME, которая используется при работе с параметром /j службы NTBackup, нужно указать имя процесса резервного копирования. Это имя будет появляться в окне NTBackup, в Backup Reports. В переменной SETDESC, используемой параметром /d службы NTBackup, следует задать описание процесса резервного копирования. Это описание появится в файле журнала и в столбце Description панели Restore пользовательского интерфейса службы NTBackup. Значение переменной DTSTAMP (указывать не обязательно) указывается в конце описания и позволяет быстро определить дату и время выполнения резервного копирования.

Можно изменить значение переменной JOBINFO, но это не обязательно. Данная переменная определяет текст сообщений об ошибке и название темы почтовых сообщений. Следует иметь в виду, что она использует значения переменных JOBNAME и COMPUTERNAME, так что можно будет определить, какой процесс и компьютер выдал сообщение.

Значение переменной OPTIONS используется для определения режима работы командной строки службы NTBackup. Предположим, требуется, чтобы служба NTBackup выполняла резервное копирование вне зависимости от того, какая лента вставлена. Тогда следует просто добавить параметр /a к значению переменной OPTIONS. Также необходимо убрать слова /n «%MEDIANAME%» из строки «Set COMMAND=, так как нельзя совместно использовать параметр /n с параметром /a.

Можно указать любой из параметров командной строки NTBackup, кроме /j, /d, /n, /g, /f, /t, /p и /um. Как я отмечал ранее, параметры /j и /d уже определены в переменных JOBNAME и SETDESC, соответственно. Сценарий автоматически определяет метку тома ленты (параметр /n) и ее GUID (/g). Остальные параметры (/f, /t, /p и /um) не стоит использовать, так как они создают конфликты.

Переменная LOGFILE применяется в целях отладки. Выходные данные каждого сценария перенаправляются в файл журнала вместе с именем ленты, идентификатором GUID логического раздела, копией состояния командной строки службы NTBackup и выходным кодом команды. Если вы оставите переменную LOGFILE, установленную в значение %~dpn0.log, файл журнала будет создан в том же каталоге, где находится сценарий Backup.cmd, и получит имя Backup.log.

Подготовка, тестирование, за работу!

После завершения этих трех этапов сценарии резервного копирования готовы к тестированию в непроизводственной обстановке. Хотя я тестировал эти сценарии под системами Windows 2003, XP и Windows 2000, в принципе перед внедрением следует всегда испытывать любые новые сценарии в лабораторной среде. После удачного тестирования вы получите гибкое средство резервного копирования.

Cистемный и сетевой администратор компании French Mortuary, Нью-Мехико. bill.stewart@frenchmortuary.com