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

Создание плана аварийного восстановления – Продолжение

Создание плана аварийного восстановления – Продолжение

В прошлый раз мы приняли решение как часто нам проводить копирование базы данных, а теперь мы должны решить, где сохранять наши резервные копии. Первая доступная возможность – сохранять резервные копии на магнитных лентах непосредственно с сервера SQL. Одним из положительных моментов сохранения резервных копий на магнитной ленте является то, что информация хранится на внесистемном ЗУ (запоминающем устройстве). К недостаткам данного метода можно отнести то, что копирование на магнитную ленту является достаточно медленным и поэтому может оказывать влияние на сервер в течение длительных периодов времени, когда будет осуществляться резервное копирование. Другим распространенным способом хранения резервных копий является сохранение в файл. Создание файла резервной копии намного более быстрый процесс, чем копирование на магнитную ленту, как для операций копирования, так и восстановления, однако резервное копирование в файл не позволяет создать быстрое удаленное внесистемное хранилище (если только вам не посчастливилось быть обладателем высокоскоростного удаленного соединения).

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

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

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

Прежде чем мы тронемся дальше, я хотел бы остановиться еще на одной теме, а именно на выборе кого-то, кто менял бы магнитные ленты. Если ваш план уже внедрен, вы должны назначить одного работника ответственным за проверку размещения лент резервного копирования и их замену в случае необходимости. Очень важно, чтобы за эту работу отвечал только один человек, так как если за это будет отвечать несколько человек, вы можете в итоге получить следующий ответ: «А я думал, что вы уже заменили ленты прошлой ночью!?». Если только один человек отвечает за ленты, это становится для него повседневной задачей. Теперь, когда только один человек не сможет заменить ленты по какой-либо причине, это будет его ответственностью найти человека, который сделает это за него. И хотя другой человек может выполнить эту работу сейчас или после, вы продолжаете считать, что за эту работу отвечает только один человек, а не несколько. Если эта работа окажется слишком большой для одного человека, поручите ответственность над половиной серверов одному работнику и другую половину другому (так, чтобы вы могли установить, кто за что отвечает персонально). Кроме того, если у вас не получится, чтобы один и тот же человек менял ленты каждый день (например, вы выполняете резервное копирование по выходным), установите ясный порядок, кто отвечает за каждый из дней и постарайтесь, чтобы это были одни и те же дни недели (бойтесь скользящих графиков).

Итак, вы решили, как часто производить резервное копирование куда копировать и где хранить резервные копии… что же осталось внести в наш план аварийного восстановления? Довольно много и большая часть этого будет очень зависеть от вашей конфигурации. Прежде всего, нужно документировать, документировать и еще раз ;) Создайте специальную папку и пусть это будет папка для вашего плана аварийного восстановления. Вот только некоторые из вещей, которые должны быть включены в ваш план:

1. Спецификация аппаратного обеспечения сервера;
   
2. Сетевая топология;
   
3. Конфигурация программного обеспечения сервера;
   
4. Схема расположения файлов базы данных (т.е. файлов журнала и файлов данных);
   
5. Обозначение ваших лент, тип резервного копирования и описание способа ротации.

Следующим шагом является размышление о том (и запись того), что случится, если произойдет аварийный сбой. Когда вы начнете писать план, представьте себе, что вы находитесь в удалении и не можете прийти на помощь. Вы также должны представить себе, что работник, который будет восстанавливать сервер, имеет только общие технические знания о сервере SQL и ничего не знает о ваших индивидуальных настройках. Думайте о таких вещах как:

1. Кто может быть доступен, когда что-то пойдет не так?
   
2. Где хранятся резервные копии?
   
3. Где хранится программное обеспечение и жесткие диски?
   
4. Будет ли на месте достаточное количество технического персонала?
   
5. Если потребуется новое аппаратное обеспечение, что должно быть сделано?
   
6. Есть ли здесь другая полезная информация?

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

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