6 типичных ошибок при резервном копировании и восстановлении данных Exchange

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

Неверный выбор метода архивирования

Два основных метода резервного копирования данных Exchange — оперативный и автономный. В оперативном режиме программный интерфейс Microsoft (такой, как Extensible Storage Engine — ESE, специальные API или служба Microsoft Volume Shadow Copy Service — VSS), обеспечивает копирование избранных данных Exchange при работающих службах Exchange и смонтированной и активной целевой базе данных. Предоставляемые Exchange интерфейсы API архивируют и при необходимости сокращают журналы транзакций.

В автономном режиме база данных Exchange и файлы журналов копируются, пока база данных не смонтирована. Поставщики некоторых решений утверждают, что данные Exchange копируются без использования Microsoft API и демонтирования баз данных. В статье «XADM: Hot Split Snapshot Backups of Exchange» объясняется, что компания Microsoft относит такие резервные копии к категории автономных.

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

Сохранение непроверенных резервных копий

Сбой в процессе резервного копирования может остаться незамеченным, но пользователи наверняка поднимут тревогу, если администратор не сможет восстановить данные электронной почты. Мне известна одна компания, в которой администратор случайно испортил базу данных почтовых ящиков. При попытке восстановить ее администратор обнаружил, что резервные копии за более чем четыре месяца испорчены, так как установленная версия стороннего агента резервного копирования была несовместима с Exchange. Агент пытался создать резервные копии файлов, но не смог, потому что файлы Exchange Information Store (IS) были открытыми. Даже беглый просмотр отчетов программы резервного копирования или журнала событий приложения показал бы неполадки в копировании данных Exchange. К сожалению, процесс резервного копирования никто не контролировал. Чтобы избежать такой неудачи, следует регулярно проверять журналы программ резервного копирования. Необходимо убедиться, что:

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

Убедитесь, что данные можно восстановить на сервере и Exchange может извлечь информацию.

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

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

Неправильная обработка журналов транзакций

Возможность восстановить базу данных Exchange определяется состоянием журналов транзакций. Если имеется корректный набор файлов журнала для базы данных, значит, есть вероятность восстановления базы данных в точке отказа. И наоборот, если журналы потеряны или испорчены, вероятность полного восстановления снижается. В процессе восстановления Exchange предпринимает попытки последовательно воспроизвести файлы журналов, начиная с первого журнала, необходимого для базы данных (также называемого нижним якорем — low anchor log), и заканчивая последним доступным журналом (верхний якорь — high anchor log). Если отсутствует файл журнала в промежутке между нижним и верхним якорем, воспроизведение журналов прекращается. Процедура восстановления не может возобновиться до тех пор, пока отсутствующий файл журнала не будет восстановлен.

В оперативные резервные копии автоматически вводятся файлы журналов как часть резервного набора данных. При нормальной работе Exchange продолжает создавать новые файлы журналов по мере совершения транзакций. Эти файлы журналов остаются на диске до тех пор, пока не будет выполнено полное или оперативное копирование, после чего процесс Exchange IS урезает или удаляет файлы. Нельзя удалять файлы журналов самостоятельно. В некоторых случаях может потребоваться скопировать файлы журналов в отдельный каталог для надежного хранения. В статье Microsoft «Offline Backup and Restoration Procedures for Exchange» рекомендуется сохранять копии журналов транзакций в отдельном хранилище, прежде чем восстанавливать данные из автономной резервной копии.

При восстановлении с помощью NTBackup журналы не воспроизводятся, если не установлен флажок Last restore set (или аналогичный флажок в другой программе резервного копирования). Восстанавливаемую базу данных нельзя монтировать, если этот флажок не установлен или для ручного запуска обработки журнала не используется команда Eseutil /r.

Если журналы транзакций отсутствуют или хотя бы один файл журнала испорчен, стоит применить бесплатный анализатор Exchange Server Disaster Recovery Analyzer (ExDRA) компании Microsoft. Этот инструмент анализирует демонтированную базу данных, сообщает об имеющихся и отсутствующих файлах журналов и возможных вариантах устранения обнаруженных проблем. ExDRA — ценный инструмент при неожиданных сбоях процесса восстановления, но администратору по-прежнему необходимо знать тонкости процесса восстановления после аварии и консультироваться со специалистами службы Microsoft Customer Service and Support (CSS) или другими экспертами.

Недостаток времени для копирования

Процесс резервного копирования требует времени. У каждой серверной конфигурации есть показатель пропускной способности, который отражает количество данных, которое можно скопировать или восстановить в данный период времени. Типичная ошибка — недооценить время, необходимое для восстановления. Слишком длительный процесс восстановления иногда приводит к нарушениям соглашения об уровне обслуживания (SLA), и часто — к проявлениям недовольства со стороны пользователей.

Компания Microsoft рекомендует измерить время, необходимое для резервного копирования массива данных, и выделить вдвое больше времени для восстановления. Почему для восстановления требуется вдвое больше времени, чем для копирования? Предположим, нам нужно получить копию базы данных емкостью 60 Гбайт с использованием системы резервного копирования со скоростью записи 12 Гбайт/ч. Пять часов — приемлемое время для резервного копирования. Однако при подготовке к восстановлению данных следует помнить, что простое считывание данных займет пять часов. В процессе восстановления требуется также выполнить следующие операции.

• Найти соответствующий резервный носитель (если используется сменный носитель, такой как лента) или подыскать подходящий дисковый том (при использовании резервных копий на базе VSS или SAN).
• Передать резервные данные на сервер, с которого выполняется восстановление.
• Создать сервер восстановления или группу восстановления хранилища (Recovery Storage Group – RSG), если это необходимо.
• Прочитать данные с резервного носителя и устранить любые ошибки и неполадки.
• Воспроизвести журналы транзакций.
• Переместить данные с сервера восстановления или RSG в производственные почтовые ящики.
• Успешно монтировать базу данных.
• Устранить любые сопутствующие проблемы.

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

Забытые мелочи

Обсуждение проблем резервного копирования Exchange часто сводится к копированию и восстановлению данных; при этом упускаются из виду многие другие объекты и элементы данных, которые также необходимо копировать и восстанавливать. Например, при катастрофическом отказе оборудования необходимо заменить аппаратные средства и установить Windows и Exchange на новом сервере, прежде чем можно будет использовать резервные копии базы данных Exchange и журналов транзакций. Создав резервную копию состояния сервера Exchange, нетрудно восстановить данные сервера и Exchange, и значительно ускорить возвращение к нормальной работе, не теряя времени на поиск компакт-дисков, серийных номеров продуктов и т.д. Если в среде Exchange имеются антивирусные программы, фильтры спама, центры сертификации (ЦС) X.509, факс-коннекторы или другие вспомогательные службы, то необходимо сделать копии и восстановить их конфигурацию, наряду с важными данными (например, закрытыми ключами и списками фильтрации), чтобы восстановить эти службы в исходном рабочем состоянии.

При резервном копировании состояния системы с помощью NTBackup собираются все системные данные локального компьютера, в том числе реестр, файлы Active Directory (AD) Directory Information Tree (DIT) на контроллере домена (DC), данные Windows Certificate Services, базы данных серверов DHCP и DNS и другие обязательные данные. Большинство утилит резервного копирования независимых поставщиков также располагают данной функцией, но можно обойтись и без этих инструментов; с помощью NTBackup можно составить расписание копирования состояния системы в файл на диске, а затем ввести этот файл в каждую резервную копию Exchange. Данный метод гарантирует своевременно обновляемую копию состояния системы. Не забывайте периодически обновлять диск автоматического восстановления системы (\Automated System Recovery (ASR). С его помощью часто удается исправить поврежденные экземпляры Windows без полной переустановки операционной системы.

Пренебрежение практикой

Освоить процесс восстановления данных лучше всего до возникновения неполадок. Отрабатывать восстановление можно, даже если на предприятии имеется всего одна база данных и единственный сервер. Для этого нужно получить экземпляр Microsoft Virtual PC 2004 или VMware Workstation, построить испытательный сервер и практиковаться в восстановлении данных. Работая с Exchange Server 2003, необходимо изучить группы RSG и способы их использования. Нужно узнать, как восстановить данные с исходного сервера на другом сервере с помощью программы резервного копирования. Установочные компакт-диски и серийные номера продуктов должны находиться в надежном месте (не в текстовом файле на сервере, который требуется восстановить). Полезно регулярно тренироваться, восстанавливая элементы, которые потребуется вернуть в рабочее состояние в случае настоящей аварии; в зависимости от особенностей среды, эти элементы могут быть отдельными почтовыми ящиками, отдельными сообщениями, базами данных, группами хранения (SG) или целыми серверами. Время, затраченное на тренировку, окупится, если произойдет сбой.

Тратим время, экономим деньги

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