Будни резервного копирования

Николай Прокофьев

Необходимые меры для создания системы резервного копирования

Требования к системе резервного копирования

 

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

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

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

1. Структура папок проекта осталась без изменения — пропали только файлы.

2. На ленте резервного копирования (которое, кстати, выполнялось ежедневно) файлов обнаружено не было, хотя структура папок присутствовала в полном объеме.

     

Необходимые меры для создания системы резервного копирования

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

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

• технический аудит вычислительной системы на предмет создания или модернизации системы резервного копирования;

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

• проектирование системы резервного копирования — разработка технической и рабочей документации;

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

• поставка и настройка оборудования и программного обеспечения;

• разработка процедур эксплуатации — организация процессов эксплуатации системы резервного копирования, разработка регламентов и расписаний системы резервного копирования. Этот вид работ очень важен: без организованного должным образом процесса эксплуатации не будет эффективно работать ни одна система, в том числе система резервного копирования;

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

 

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

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

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

     

Требования к системе резервного копирования

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

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

- управление с выделенных компьютеров резервным копированием во всей сети;

- удаленное резервное копирование данных, содержащихся на серверах и рабочих станциях;

- централизованное использование устройств резервного копирования.

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

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

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

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

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

- выполнение резервного копирования по расписанию;

- ротацию носителей;

- обслуживание устройств резервного копирования по расписанию.

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

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

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

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

Резервное копирование данных в интерактивном (on-line) режиме. Зачастую информационная система включает различные приложения «клиент-сервер», которые должны функционировать круглосуточно. Примером этого являются почтовые системы, системы коллективной работы (например, Lotus Notes) и SQL-серверы. Осуществить резервное копирование баз данных таких систем обычными средствами невозможно, поскольку они все время открыты. Поэтому в них часто встроены собственные средства резервного копирования, но их использование, как правило, не вписывается в общую технологию, принятую в организации. Исходя из этого система резервного копирования должна обеспечивать сохранение баз данных приложений «клиент-сервер» в интерактивном режиме.

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

 

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

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

Чем же закончилась сия печальная история? А вот чем:

1. Было принято решение сохранять завершенные проекты на DVD.

2. Период ротации магнитных носителей был увеличен до трех месяцев.

3. Была разработана и принята политика хранения и резервирования информации в рамках всего холдинга.

P.S. Данные все-таки были найдены в одном из файловых залежей, коих немало в любой сети.

 

 

По материалам www.ibs.ru.

КомпьютерПресс 4'2004


Наш канал на Youtube

1999 1 2 3 4 5 6 7 8 9 10 11 12
2000 1 2 3 4 5 6 7 8 9 10 11 12
2001 1 2 3 4 5 6 7 8 9 10 11 12
2002 1 2 3 4 5 6 7 8 9 10 11 12
2003 1 2 3 4 5 6 7 8 9 10 11 12
2004 1 2 3 4 5 6 7 8 9 10 11 12
2005 1 2 3 4 5 6 7 8 9 10 11 12
2006 1 2 3 4 5 6 7 8 9 10 11 12
2007 1 2 3 4 5 6 7 8 9 10 11 12
2008 1 2 3 4 5 6 7 8 9 10 11 12
2009 1 2 3 4 5 6 7 8 9 10 11 12
2010 1 2 3 4 5 6 7 8 9 10 11 12
2011 1 2 3 4 5 6 7 8 9 10 11 12
2012 1 2 3 4 5 6 7 8 9 10 11 12
2013 1 2 3 4 5 6 7 8 9 10 11 12
Популярные статьи
КомпьютерПресс использует