Вариации на тему резервного копирования

Я работал системным администратором в различных организациях, и мне ни разу не посчастливилось видеть идеальную сеть. Главную проблему везде представляет безопасность данных.

Для обеспечения сохранности данных в локальной сети, работающей под управлением любой операционной системы, будь то Unix, Novell NetWare или Windows NT, чаще всего применяется резервное копирование. Идеальный вариант - регулярное копирование данных на магнитную ленту - общеизвестен, но мало где реализован.

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

Года три тому назад я заведовал отделом автоматизации банка. Когда передо мной встала задача приобрести новый сервер, я, естественно, постарался предусмотреть в нем все необходимое для сохранности данных. Правление банка, изучив смету, задало риторический вопрос, набивший оскомину многим сисадминам: "Что для чего существует: банк для автоматизации или автоматизация для банка?"

Чтобы доказать свою правоту, я в течение трех месяцев собирал сведения о печальном опыте сетевых сбоев и потери данных в различных банках (подготовленный тогда отчет могли видеть подписчики RU.BANK_TEHNOLOGY). Собранные данные не только произвели необходимое впечатление на правление моего банка, но и помогли делу автоматизации в других организациях.

Работая системным администратором в Издательском доме "Компьютерра", я столкнулся со знакомой проблемой - отсутствием копирования и архивирования данных. Примененный в качестве спасательного средства прием не нов. Я переписываю данные с одного сервера на другой и, таким образом, имею частично дублированные наиболее важные данные. Это не спасет в случае стихийного бедствия, но при гибели одного из серверов ущерб будет не так велик.

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

В общем случае, если сеть построена на операционной системе Unix или Windows NT, решение проблемы зеркалирования части данных с одного сервера на другой заложено внутри каждой из них. Но мне потребовалось копировать данные с сервера Novell NetWare 3.11 на сервер Windows NT 4.0.

Простейшее решение, казалось, лежало на поверхности: подключить (map) необходимый директорий на NetWare-сервере и написать небольшой batch-файл, запускающийся по команде at посреди ночи для копирования данных (посреди ночи потому, что NetWare не позволяет копировать файлы, используемые в то же время другим пользователем). Решение простое и многократно применявшееся мной для копирования данных с NT-сервера на находящийся на этом же сервере магнитооптический накопитель.

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

Batch-файл содержал команду xcopy с небольшим оформлением вокруг; запуск из командной строки показал, что в нем нет ошибок. Для иллюстрации моих действий приведу конкретный пример строки:

at 00:20 /interactive /every:M,T,W,Th,F,S,Su cmd /c d:\1c\1ccopy.bat,

где d:\1c\1ccopy.bat - командный файл, вызывающий файл 1cnw.bat и передающий ему в качестве параметров текущий год, месяц и день. 1cnw.bat осуществляет копирование в каталог 1с.

Утилиту batdate, генерирующую передаваемые параметры, я нашел в одной из телеконференций:

Rem 1ccopy.bat

echo on

cd \1c

batdate 1CNW.BAT

rem 1cnw.bat

MD %1%2%3

XCOPY o: d:\1c\%1%2%3 /E /V /H /C

arj a -r f%1%2%3 %1%2%3

if errorlevel 1 goto halas

deltree /Y %1%2%3

:halas

Командный файл 1cnw.bat создает в каталоге 1c директорий с названием типа 980120, где 98 - год, 01 - месяц, 20 - число, и переписывает в него файлы с сетевого диска. Затем создает под именем f980120 arj-файл с содержимым соответствующего каталога. Наконец, проверяется правильность архивирования. При успешном архивировании созданный каталог стирается для экономии места. В случае сбоя инициатива передается системному администратору.

При удачном раскладе на NT-сервере будут храниться архивные файлы с именами, соответствующими дням копирования. При необходимости их можно будет удалить вручную.

К моему удивлению, запуск не дал желаемого результата.

Команда xcopy сообщила, что она не может найти исходных файлов. Оказалось, что если сервис Schedule запущен с системными установками, то любые действия можно производить только с данными текущей рабочей станции.

Пришлось запустить настройки Schedule и заменить System Account на This Account с выбором моего сетевого логина и вбиванием моих сетевых паролей.

Для NT-сети это дало желаемый результат. В назначенное время запускался 1ccopy.bat и копировал данные с логического диска О.

Хорошо, перехожу к эксперименту с NetWare-сервером. Аналогично создаю на нем директорий и подключаю его как диск О. Запускаю команду at с указанными ранее параметрами, и - вот он желаемый результат! Аккуратно переношу все установки и batch-файл на NT-сервер, после чего с чистой совестью считаю задачу выполненной.

А на следующий день обнаруживаю, что в доступе к NetWare-серверу мне отказано. Проанализировав сетевые установки на рабочей станции и сервере, вспоминаю, что на рабочую станцию я установил 32-битный NetWare-клиент от Novell, а на сервере стоит клиент от Microsoft. (Кстати, установка клиента Novell позволяет запускать с рабочей станции такие полезные утилиты, как purge.) Я установил клиент Novell на сервер, и все заработало. NetWare-клиент от Novell можно скачать с сайта www.novell.com. Желаю удачи.

С автором можно связаться по e-mail: dva@computerra.ru