Итак, Вы системный администратор. У вас в хозяйстве есть некоторое количество разнообразного оборудования и серверов с произвольным набором данных. Вы отвечаете за работоспособность инфраструктуры, целостность данных и за очень многие вещи, о которых умалчивают должностные инструкции.

Как создать систему резервного копирования за очень дешево, а лучше всего вообще бесплатно?

Не буду заниматься рассмотрением теории, а просто поделюсь личным опытом.

Имеем типичную ситуацию: бюджетное учреждение, скромные зарплаты, старенькая техника, запланированного бюджета на ИТ нет совсем, покупки оборудования и программного обеспечения происходят от случая к случаю, когда в организации появляются какие-то деньги или когда прижимает уже окончательно. Необходимо обеспечить надежную и простую систему резервирования важных данных, попутно не разорив организацию, закупая самое лучшее программное и аппаратное обеспечение для решения этой проблемы. Отсутствие средств не избавляет от соблюдения уголовного законодательства и проверок соответствующих органов, поэтому все программное обеспечение, используемое в организации строго лицензионное. Решение проблемы резервного копирования с помощью «пиратского» программного обеспечения исключается.

Что хочется получить от системы резервного копирования?

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

Так уж исторически сложилось, что основной платформой на серверах и рабочих станциях нашей организации является Microsoft Windows различных версий. Поискав различные решения под эту платформу, попробовав разные программы, мы пришли к неутешительному выводу: купить удобное и надежное решение по резервному копированию мы пока не в состоянии. Бесплатные решения по тем или иным причинам нам не подошли. Был или неудобный формат хранения копий или неудобство настройки под наши нужды или что-то еще. Пробовали решения на Linux системах, но опыта эксплуатации этой операционной системы мало, хотя это конечно нас не оправдывает.

Обдумав сложившуюся ситуацию, решили пойти своим путем.

Еще до поиска подходящего решения была проведена полная ревизия того, что вообще следует резервировать. При этом попытались сами для себя ответить на следующие вопросы:

• какие важные данные есть в организации?

• где они располагаются?

• как часто нужно делать резервную копию данных?

• как долго ее нужно хранить?

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

Определив наборы данных для резервного копирования можно двигаться дальше. Попутно стало ясно, что все данные разные, многие требуют своего индивидуального подхода к сохранению. Если обычные файлы можно просто поместить в архив и его уже хранить как резервную копию, то с базой данных так поступить уже сложнее, нужно предварительно выгрузить данные и только потом помещать их архивную копию, или же предварительно остановить сервис конкретной базы данных и затем ее поместить в архив. Таким образом, требуется предварительная индивидуальная подготовка каждой резервной копии.

 Резервные копии, как и куриные яйца, храниться в одной корзине не должны. Даже если эта корзина поддерживает RAID.

Было решено создавать многоуровневую систему резервирования – в нашем случае получилось 4 уровня.

Первый уровень – это копия данных, которая хранится в виде архива на том же сервере, где хранятся сами данные, но желательно это делать на разных дисковых массивах. При этом формируется архив, который потом передается на все остальные уровни хранения. Считаем что знание, какие данные извлечь и как это сделать - привилегия сервера, который является источником этих данных.

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

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

Третий уровень - был подготовлен еще один сервер, назовем его удаленное хранилище резервных копий. В нашем здании присутствует подвал с разной степени заброшенности помещениями и одна комнатка была размером ровно таким, чтобы установить туда 19 дюймовую стойку. Присутствовала система вентиляции, укрепленные стены и толстая металлическая дверь толщиной в сантиметр. Для чего она была предназначена изначально, истории не сохранилось, но под наши нужды подходила идеально. В комнату была установлена стойка с одним сервером и блоком бесперебойного питания. Если основная серверная комната будет уничтожена, то эта бронированная комнатка способна пережить даже обрушение здания. Помимо физической удаленности основной серверной от импровизированной, был предпринят еще один шаг – удаленный сервер выведен из рабочего домена, и в домене не осталось никаких учетных записей, которые бы имели доступ к ресурсам этого сервера. Таким образом, если учетная запись, под которой происходит резервирование данных, скомпрометирована (например, под ней будет запущен вредоносный код), то у нее не будет возможности попасть к третьей копии данных. Данные на этот выделенный сервер могут попасть только тогда, когда этот сервер сам заберет данные. Никаких открытых ресурсов для доступа снаружи, на этом сервере так же не осталось, только доступ удаленного рабочего стола с учетной записью самого сервера.

Четвертый уровень – для последнего уровня защиты было решено выделить несколько жестких дисков, на которые раз в несколько месяцев будут копироваться данные. Диски хранятся в сейфе и для копирования подключаются к одному из серверов с помощью док-станции. После копирования убираются обратно в сейф. Также эти диски можно хранить дома у одного из сотрудников, чтобы обеспечить большую территориальную изоляцию этих копий.

На каждом из этих уровней хранится не одна копия данных, а многодневные копии, которые накапливаются и удаляются по мере устаревания.

Перейдем к этапу реализации.

В качестве основного средства для создания резервных копий был выбран архиватор «7-zip». Программа довольно универсальная, обладающая огромными возможностями и совершенно бесплатная. Одной из возможностей является функция работы с файлами списками. Это обычный текстовый файл, в котором в виде текстовых строк перечисляются каталоги или файлы, для добавления в архив. Это дает возможность создания универсального скрипта для архивации, который никак не связан с самими данными, нужна только ссылка на текстовый файл с перечислениями нужных ресурсов.

Как уже упоминалось, данные на серверах самые разнообразные. Значит на сервере источнике данных нужен небольшой скрипт, который предварительно подготовит данные для архивации, а затем передаст управление универсальному скрипту, который и произведет действия по созданию архива, а также его передачу в соответствии с прописанными правилами на сервер основного хранения. Помимо всего, нам как «администраторам-параноикам» желательно бы знать, а все ли прошло хорошо в ходе архивации, т.е. нужна функция ведения логов процесса и отправка извещений об ошибках. Это тоже можно возложить на универсальный скрипт.

 «Да будет скрипт!»

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

Окно для создания резервных копий для нашей организации приходится на ночные часы и выходные дни.

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

@echo off 

set pBData=C:\Backup_Data 
set pNet=\\Server-3\Backup_all 
set pDate=%date% 

rem Обновление клиентского скрипта, если оно существует 
xcopy %pNet%\#_client\*.* %pBData%\*.* /D /Y /R /E 

call %pBData%\backup.bat Budget %pBData% %pNet% %pDate% 

В первую очередь задаются параметры запуска универсального скрипта:

pBData – каталог, куда будут размещены копии необходимых скриптов, файл список с перечислением архивируемых ресурсов, а также подкаталоги с результатами резервного копирования и логи выполнения.

pNet – доступный сетевой ресурс на основном сервере резервного копирования, где хранятся резервные копии и универсальные скрипты.

pDate – дата формирования резервной копии, она будет присутствовать в имени формируемой копии и лог файлах.

Затем выполняется контроль версии универсального скрипта, если файл на клиенте не совпадает с расположенным на основном сервере резервного копирования, то файл будет обновлен. Скрипт копируется на сервер источник данных для того, чтобы если вдруг будет разорвана связь с основным сервером резервного копирования, сам процесс создания копии все равно был бы начат, вне зависимости от того, работает ли второй сервер в данный момент или нет.

После этих действий выполняется универсальный скрипт, при этом первым параметром передается «имя копии», в приведенном примере это «Budget».

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

- #_time_log – здесь будет создан файл с логами результатов выполнения резервного копирования.

- «имя копии» – каталог с именем создаваемой резервной копии, это же имя идет в качестве параметра при вызове универсального скрипта.

Также в этом каталоге должен быть файл «имя копии.ls». В нем в виде текстовых строк перечисляются каталоги, в которых расположены данные подлежащие резервированию.

На основном сервере резервного копирования по адресу из переменной pNet должны быть следующие файлы и подкаталоги:

- #_client – каталог, содержащий в себе файл универсального скрипта, а также еще несколько скриптов вызываемых в процессе работы универсального скрипта. Все файлы из этого каталога копируются на сервер источник данных и запускаются именно оттуда. Для обновления скрипта на всех клиентах – необходимо обновить его в данной папке. Во избежание ненужных проблем желательно к этой папке сделать доступ для клиентов только на чтение.

- #_time_log – каталог, в котором собираются логи о времени и результате выполнения резервного копирования со всех задействованных клиентов. Файл с логом называется по имени копии «имя копии.log». Также в этом каталоге располагается обобщенный лог «total_mail.log», на его основе формируется электронное письмо для отправки системному администратору.

Рассмотрим содержимое универсального скрипта «backup.bat»

@echo off

rem Системное имя резервной копии
set cName=%1

rem Каталог для резервного копирования на клиенте
set pBData=%2

rem Расположение в сети папки с копиями и скриптами
set pNet=%3

rem Дата запуска процедуры резервного копирования
set pDate=%4

rem Файл с информацией о времени выполнения архивации
rem и ее размере
set fTime=%pBData%\#_time_log\%cName%.log

rem Обобщенный лог для отправки администратору
rem на электронную почту
set fMail=%pNet%\#_time_log\total_mail.log

set dStart=%date%
set tStart=%time%

rem Количество дней хранения архивов
set KOL_DAY_COPY=5

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

Время хранения архивов на основном сервере резервного копирования прописано в универсальном скрипте в переменной «KOL_DAY_COPY», по умолчанию 5 дней.

Продолжаем:

rem Если каталога для хранений копии нет,
rem то его нужно создать
if not exist "%pBData%\%cName%" ( mkdir %pBData%\%cName% )

rem Параметры архива:
rem –r		Просматривать подкаталоги
rem –p		Пароль
rem -ssw	Архивировать файлы открытые на запись
rem -y		Отключить интерактивные запросы пользователю,
rem 		на все вопросы отвечается ДА
rem -t7z		Формат файла 7z
rem -mx=7	Степень сжатия 7 - maximum (по умолчанию 5)
rem -mmt=on	Использовать паралельную обработку
rem -myx=7	Использовать анализ exe файлов,
rem 		на возможность дополнительного сжатия

rem Определяем архиватор
set aName="%ProgramFiles%\7-Zip\7z.exe"

rem Задаем параметры архивации
set param="a -r -pPassword -ssw -y -t7z -mmt=on"

rem Формируем имя файла архива
set pFName="%pBData%\%cName%\%pDate%-%cName%.7z"

%aName% %param% %pFName% @%pBData%\%cName%.ls

rem Получаем размер файла, для последующего анализа
if exist %pFName% ^
for %%i in (%pFName%) do (set fLen=%%~zi) else (set fLen=0)

rem Копируем полученный архив на сервер хранения
robocopy %pBData%\%cName%\ %pNet%\%cName%\ %pDate%-%cName%.7z

set dEnd=%date%
set tEnd=%time%

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

После формирования архива, получаем его размер в переменную fLen, для последующего анализа.

В переменных dStart, dEnd, tStart, tEnd запоминаем дату и время до и после архивации. Это поможет оценить время, затраченное на создание архива, что в дальнейшем помогает правильно составить расписание для запуска процедуры.

Для передачи архива с сервера источника данных на сервер основного хранилища резервных копий используется утилита «robocopy.exe». Если в системе данная утилита отсутствует, то нужно установить Microsoft Resource Kit 2003. Местоположение утилиты нужно прописать с помощью системной переменной PATH. Стандартная команда «xcopy» на больших файлах и по сети работает не стабильно.

К сожалению, пароль на создаваемый архив прописан в открытом виде внутри скрипта, но при грамотном разграничении доступа это не так страшно.

И третья часть универсального скрипта, уже заключительная – это сохранение логов и обработка архивов:

echo %cName% %dStart% %tStart%-%dEnd% %tEnd%:%fLen%>>%fTime%

rem Формирование статистики для отправки администратору
echo %cName% %dStart% %tStart% %dEnd% %tEnd% %fLen%>>%fMail%

rem Если файл с архивом меньше килобайта, то что-то не так!
if %fLen% LSS 1024 ( 
echo WARNING: Size %cName% too small ! >> %fTime%
cscript "%pBData%\sendMail.js" "admin@a.ru" ^
"error@a.ru" "Error backup %cName% %dStart%" ^
"The size of the copy %cName%, is too small (%fLen%)."
)

rem Удаление старых копий на источнике данных
cd /D %pBData%\%cName%
wscript %pBData%\del_old.vbs %KOL_DAY_COPY%

rem Удаляем старые копии файлов на основном сервере.
net use b: /delete /y
net use b: %pNet%
cd /D b:\%cName%\
wscript %pBData%\del_old.vbs %KOL_DAY_COPY%

net use b: /delete /y
cd /D %pBData%\

rem Отправляем итоговый лог файл на сервер хранения
copy /y %fTime% %pNet%\#_time_log\*.*

В ходе создания резервной копии создаются два файла с логами.

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

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

Один раз в неделю происходит копирование данных с основного хранилища резервных копий на удаленное хранилище резервных копий, которое расположено в изолированном помещении. Количество дней хранения на этом сервере ограничено размером дискового пространства. Если файл уже присутствует на удаленном сервере, он уже не копируется. Скрипт, который этим занимается, не приводится, он построен на основе предыдущего.

Для полноты картины осталось привести еще два файла, которые располагаются в каталоге «#_client» основного хранилища резервных копий.

Процедура отправки письма администратору оформлена в виде скрипта на Microsoft JScript «sendMail.js»:

var arg = WScript.Arguments;

var sTo = arg(0);		// адресат
var sFrom = arg(1);	// от кого
var sSubject = arg(2);	// тема письма
var sBodyFile = arg(3);	// файл с текстом для отправки

var refMsg = WScript.CreateObject("CDO.Message");

refMsg.To = sTo;
refMsg.From = sFrom;
refMsg.Subject = sSubject;

var FSO = WScript.CreateObject("Scripting.FileSystemObject");
var ts = FSO.OpenTextFile(sBodyFile, 1, false);
refMsg.Textbody = ts.ReadAll();
ts.Close();

refMsg.BodyPart.Charset ="windows-1251";
var strA="http://schemas.microsoft.com/cdo/configuration/";

refMsg.Configuration.Fields.Item(strA+"sendusing")=2;
refMsg.Configuration.Fields.Item(strA+"smtpserver")="a.ru";
refMsg.Configuration.Fields.Item(strA+"smtpserverport")=25;

refMsg.Configuration.Fields.Update();
refMsg.Send();

Процедура удаления устаревших архивных файлов реализована на Microsoft VBScript (в данном случае этот язык выбран из-за более простой работы с датами), скрипт просматривает текущий каталог и удаляет все «*.7Z» файлы старше указанного количества дней.

Файл «del_old.vbs»:

Dim fs, i, fc, ArgObj, days
Set ArgObj = WScript.Arguments

if(ArgObj.Count > 0) then
	days = ArgObj.Item(0)
else
	days = 5
end if

daylimit = now - days

Set fs = CreateObject("Scripting.FileSystemObject")
Set fc = fs.GetFolder(".").Files
For Each i in fc
   if (Ucase(right(i.name,2)) = "7Z") then
    if i.DateCreated < daylimit then
     fs.DeleteFile i.name, true
    end if
   end if
Next

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

Пример расписания запуска процессов на серверах источниках данных приведено в следующей таблице:

Подведем итог.

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

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