Десять заповедей резервного копирования
#10/2004
Независимо от используемой технологии резервного копирования всегда следует придерживаться некоторых фундаментальных правил. Мы приведем 10 условий, выполнение которых облегчает проведение резервного копирования. На первый взгляд, эти условия просты и очевидны, но не всегда их легко выполнить.
Когда кто-то о чем-то рассказывает или делится впечатлениями, всегда проще и эффектнее говорить о чем-то плохом. Плохие новости воздействуют всегда сильнее, чем хорошие. Например, срывы ночных сессий резервного копирования, безвозвратно испорченные ленты, невосстановимые данные. Впрочем, не все так плохо. Есть учреждения, где резервное копирование и восстановление проходят нормально и без всяких затруднений укладываются в выделенное временное окно. Очевидное условие существования надежной и отлаженной инфраструктуры резервного копирования — наличие эффективного управления и оптимальной организации всей вычислительной системы. Хорошо отлаженная и организованная среда обеспечит ясное понимание задач и способов их решения. Ниже приведены десять моментов, на которые имеет смысл обратить внимание при организации системы резервного копирования или при оптимизации существующей.
Предварительное планирование. Резервное копирование является стратегическим компонентом защиты данных (существует также зеркалирование, снэпшоты и репликация данных). Но важнейшим, фундаментальным элементом всей стратегии хранения данных должно стать планирование резервного копирования.
Все компоненты инфраструктуры резервного копирования должны учитываться в процессе планирования, а все приложения, серверы и тенденции увеличения емкости первичных хранилищ данных не должны оставаться без внимания. Очень часто изменения в среде не принимаются во внимание. Это может вызвать сбои и оказать пагубное воздействие на работу системы резервного копирования.
Кроме того, правильное планирование позволяет составить более полное представление о потребностях и особенностях работы приложений с точки зрения защиты данных.
Приложения баз данных, где присутствуют разделенные «зеркала» и приложения, работающие в файловой среде, в которой нет дополнительной защиты данных, требуют разных стратегий и подходов к резервному копированию. Аналогично, большое корпоративное приложение, развернутое на нескольких серверах и предполагающее сложную взаимозависимость данных для обеспечения последующего восстановления, будет требовать соответствующей синхронизации резервного копирования.
Установление жизненного цикла и календаря операций. Эффективная работа системы резервного копирования требует ежедневного успешного выполнения определенных заданий. Однако есть не менее важные задания, которые выполняются еженедельно, ежемесячно, ежеквартально и ежегодно. Задания с коротким циклом в большей степени являются тактическими, а задания с большим циклом — стратегическими. В среде эффективного резервного копирования все задания должны быть задокументированы и выполняться согласно расписанию.
Ежедневные задачи являются основой, с которой хорошо знакомы системные администраторы. К ним относятся:
В случае еженедельных, ежемесячных и других операций надо обращать внимание на:
Документируем их, и убеждаемся, что они выполняются и генерируют отчеты в полном соответствии с расписанием. Все эти временные файлы нельзя упускать из виду. Храниться они будут долго, пройдет год, завершится годовой цикл. Поначалу это покажется неудобным, но потом появится понимание, как оптимизировать среду (или окажется, что среда резервного копирования уже оптимизирована).
Ежедневный обзор логов процесса резервного копирования. Обзор логов ошибок и выполнения резервного копирования является необходимой ежедневной задачей.
Но часто это легче сказать, чем сделать, поскольку такое занятие требует много времени. Однако затраченное время может принести неплохие дивиденды в виде надежно работающей системы резервного копирования.
Проблемы при резервном копировании, как правило, возникают лавинообразно. Один-единственный сбой может повлечь за собой целую последовательность, на первый взгляд даже не связанных между собой затруднений. Например, задание резервного копирования может либо «зависнуть», либо не запуститься из-за того, что нужный привод магнитных лент не был освобожден предыдущим заданием. Это предшествующее задание сохраняло сервер приложений, на котором одновременно шел незапланированный ресурсоемкий процесс. Выполнение данного процесса не позволило закончить резервное копирование в установленный расписанием срок. Ответственный системный администратор своевременно не информировал администратора резервного копирования, чтобы он мог внести соответствующие изменения в расписание процессов. Порой для того чтобы определить, является ли некоторое состояние причиной или следствием чего-то другого, может потребоваться немалого опыта и усилий, а сам процесс будет напоминать детективное расследование. Естественно, для успешного решения возникающих проблем необходима согласованная работа системных, сетевых администраторов и администраторов баз данных.
Защита базы данных резервного копирования или каталога. Все приложения резервного копирования ведут свою базу данных или каталог, необходимые для последующего восстановления сохраненных данных. Потеря каталога влечет потерю сохраненных данных. Хотя некоторые приложения резервного копирования имеют механизмы корректного чтения лент и индексов для восстановления, это может оказаться непосильной задачей. Такой каталог должен рассматриваться как любое другое критически важное приложение баз данных. Желательно иметь его зеркальную копию или, по крайней мере, хранить в RAID-системе. Кроме того, желательно убедиться в том, что каталог сохраняется согласно расписанию и без ошибок.
Ежедневное определение временного окна резервного копирования. Ошибки, связанные с временным окном резервного копирования, не оставляют соответствующих сообщений в отчетах, так как на самом деле это нормальный и успешно завершившийся процесс резервного копирования. Поэтому часто проблема остается незамеченной. Если задания начинают приближаться или выходить за пределы отведенного временного окна, это является признаком приближения к предельной емкости системы или наличия «узких мест» в производительности. Своевременное обнаружение таких признаков может избавить от последующих более крупных сбоев системы.
Локализация и сохранение «внешних» систем и томов. ПО резервного копирования предоставляет некоторые отчеты о ежедневных сессиях резервного копирования. Рассматривать только их и полагаться только на них рискованно.
ПО резервного копирования генерирует отчеты только об известных ему серверах. Сложные среды часто имеют «внешние» системы, системы, которые участвуют в работе, но не включены в схему резервного копирования. Это происходит по разным причинам. Купленная неким подразделением система и оказавшаяся вне поля зрения IT-подразделения некоторое время может работать с собственным резервным копированием. Но рано или поздно возможен сбой, приводящий к потере данных. Тогда специалисты IT-подразделения получают запрос восстановления данных на системе, о которой им ничего не известно. Как правило, такие системы попадают в поле зрения службы IT, слишком поздно. Решение этой проблемы может оказаться трудоемким и займет массу времени. Потребуется регулярный просмотр и мапирование новых сетевых адресов в узлы (ноды), фильтрация не связанных с задачей адресов (дополнительные сетевые карты, сетевые устройства, принтеры и т. д.), идентификация местоположения и владельцев таких узлов и внесение соответствующих изменений в политику резервного копирования (в этом случае объемы данных, подлежащих сохранению, увеличатся). Также важно регулярное предоставление отчетов владельцам системы и приложений о том, что на самом деле сохраняется, а что — нет.
Максимально возможная централизация и автоматизация резервного копирования. Ключом к успешной защите данных является их целостность. Но это не значит, что со всеми данными требуется обходиться одинаково. Наоборот — одинаково надо обращаться с данными, сходными по объему и важности для компании. Проблема «внешних» систем, о которой шла речь чуть выше, как раз является примером нарушения целостности данных, возникающего из-за нецентрализованного управления резервным копированием. Нередко операции резервного копирования для Windows— и Unix-серверов происходят независимо. Такая организация могла предшествовать сетевому хранению. Помимо того что это неэффективно, подобная организация предполагает разные наборы процедур и разные стратегии резервного копирования для разных платформ. Определять ценность данных таким образом неправильно. По географическим соображениям функции резервного копирования могут быть действительно распределены по удаленным офисам, но, принимая во внимание качество современных коммуникаций, выгода от такой децентрализации весьма небольшая. По мере увеличения сложности инфраструктуры резервного копирования для выполнения повторяющихся операций желательно применять средства автоматизации. Возьмем, к примеру, трудоемкую задачу ежедневного изучения журналов (логов) выполнения операций. Автоматизация позволит генерировать сигналы тревоги при появлении в логах заранее определенных ошибок. Верно и обратное: автоматизация поможет накапливать повторяющиеся в логах ошибки. Если в логах увидеть одну ошибку SCSI, это то же самое, что увидеть их тысячу. Просмотр всех одинаковых ошибок — занятие утомительное, способное отбить охоту к ежедневному изучению логов вообще. Если правильно определить выполняемую задачу и ожидаемый результат — средства автоматизации, несомненно, смогут избавить от части утомительной работы.
Создание и поддержка открытых отчетов, отчетов об открытых проблемах. Нахождение и устранение упомянутых выше проблем является тактической частью работы по обеспечению надежного функционирования системы резервного копирования.
Однако эффективное преодоление проблем и определение некоторой шкалы, по которой можно оценить качество резервного копирования, вполне может оказаться движущей силой улучшения инфраструктуры резервного копирования. В больших и сложных средах проблемы могут отслеживаться при помощи формальной системы ярлыков. Если такая система не используется, то наличие журнала открытых (нерешенных на данный момент) проблем может способствовать оптимизации процесса резервного копирования. В любом случае регулярные, детализирующие открытые (нерешенные) проблемы, отчеты будут указывать частоту и количество появления новых и закрытия старых проблем, что, в свою очередь, многое говорит об общем состоянии системы резервного копирования. Простой отчет о тенденциях с соответствующими данными может открыть фундаментальные проблемы и помочь выработать их решение.
Резервное копирование должно быть включено в процесс контроля изменений системы.
Среда резервного копирования по своей природе достаточно динамична. Изменение системы резервного копирования тоже происходит динамично. Резервное копирование должно входить в процесс стратегического планирования, а на операционном уровне — стать частью процесса контроля изменений системы. Существует масса историй о непредусмотренных перебоях резервного копирования, происходящих по вине коммутационной топологии сетей хранения данных, или в связи с изменениями в зонировании, или с появлением «узких мест», возникающих в результате изменения конфигурации системы резервирования данных. Они могут и должны быть устранены. Если в инфраструктуре резервного копирования необходимо наличие ежемесячного перерыва для проведения апгрейдов или регламентных тестов, такое временное окно не должно пересекаться с аналогичным перерывом в работе остальных систем. При внесении изменений в систему существует повышенная потребность в восстановлении данных, когда файлы сохраняются, а новые устанавливаются. Если инфраструктура резервного копирования остановлена для планового обслуживания, то данные не смогут быть восстановлены в нужное время.
Инфраструктура резервного копирования — это производственная система, и, как одно из важнейших используемых приложений, требует поддержки и внимания ничуть не меньше остальной производственной среды.
Консультации с вендорами. Среда резервного копирования сложна и с появлением новых технологий становится еще сложнее. Поставщики программных и аппаратных средств соревнуются друг с другом в добавлении новых возможностей для того, чтобы выделиться. В то время как большая часть данных технологий действительно полезна (а все это звучит еще лучше), есть множество затруднений в понимании нюансов функционирования той или иной технологии и отличий между ними. Например, существует множество подходов к дисковому резервному копированию. Какой из них лучше всего подходит для данной среды и в чем его преимущество? Вот фундаментальный вопрос, на который надо ответить: у выбранного поставщика достаточно умения для удовлетворения ваших потребностей? Если все технические проблемы решены — хорошо. Если технические проблемы не решаются за разумное время — то с подобным поставщиком работать не следует. Это особенно заметно, когда требуется интеграция продуктов от разных изготовителей.
Описанные правила могут показаться слишком очевидными, но выполнять их все бывает далеко не просто. Это зависит от некоторого количества ключевых элементов: возможностей в плане отчетности, высокого уровеня компетентности персонала, связанного с резервным копированием, и прочного взаимодействия структур, выполняющих разные функции. Помех этому тоже может быть немало: стоимость, доступность ресурсов, уровень мастерства, организационной политики и многое другое. Если нет возможности предусмотреть все указанные аспекты, стоит выделить наиболее важные и сфокусироваться на них. Но по другую сторону этих трудностей находится риск невосстановления данных, а значит, и потери критически важной информации.
