от Mike Aubert

Добро пожаловать в статью девятую моей серии «Изучи сервер Windows SQL 2000 за 15 минут в неделю». На прошлой неделе мы начали создавать план аварийного восстановления. На этой неделе мы завершим данную работу. В статью включены следующие темы:

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

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

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

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

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

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

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

Будет использовано 11 лент: ПОНЕД., ВТОРН., СРЕДА, ЧЕТВЕРГ, ПЯТНИЦА, СУББОТА, 1НЕДЕЛЯ, 2НЕДЕЛЯ, 3НЕДЕЛЯ, 1МЕСЯЦ, 2МЕСЯЦ…

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

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

Май 2002, среда 1 – пятница 31:

Июнь 2002, суббота 1 – воскресенье 30:

Несколько озадачены? :)

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

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

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

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

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

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

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

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

На следующей неделе мы рассмотрим, как восстанавливать базу данных с резервной копии и, таким образом, мы сможем проверить, как действует наш план аварийного восстановления. Мы также закончим рассмотрение тем, связанных с резервным копированием/восстановлением баз данных и тогда мы сможем перейти к изучению более интересного материала! И как всегда…если у вас возникнут какие-либо технические вопросы, пожалуйста, присылайте их на доску объявлений сайта 2000Trainers.com SQL message board. Нетехнические вопросы, комментарии и обратная связь – по адресу моей электронной почты. Я надеюсь, что вы найдете эти статьи полезными и был бы рад узнать ваше мнение о них.

Mike Aubert, MCSE, MCDBA,  MCSD.