На главную страницу
 
  Главная 
  Новости 
  Статьи  RSS
  Программное обеспечение 
  Форум 
  Опросы 
  Полезные ссылки 
MSExchange.ru ISADocs.ru WinSecurity.ru NetDocs.ru

Exchange 5.5
Exchange 2000
Exchange 2003
Exchange 2007
Общее
Exchange 2010

Поиск по сайту


Авторизация

Запомнить меня на этом компьютере
  Забыли свой пароль?
  Регистрация

Подписка

Изменение параметров

Статистика

Hits 41812657
25029
Hosts 2897970
1180
Visitors 3110285
1890

8
Мониторинг активности принтеров

Главная / Статьи / Общее / Резервное копирование и восстановление в Exchange – потоковая техника и Volume Shadow Service (VSS)


SurfCop

Резервное копирование и восстановление в Exchange – потоковая техника и Volume Shadow Service (VSS)

Версия для печати Версия для печати

Эта статья переведена силами и средствами компании Red Line Software. Размещение данного переведенного материала на других сайтах без разрешения компании Red Line Software запрещается.

Extensible Storage Engine (ESE)

Базовая технология хранения в Microsoft Exchange Server и Active Directory называется Exchange Extensible Storage Engine (ESE), также известная как JET Blue. Это технология хранения данных, основанная на методе индексированного последовательного доступа (Indexed Sequential Access Method - ISAM), целью которой является разрешение приложениям хранить и извлекать данные с помощью индексного и последовательного доступа. Поисковый механизм Window Mail and Desktop Search в операционной системеWindows Vista также использует ESE для хранения индексов и информации о свойствах данных.

Базовые возможности ESE:

  1. Microsoft JET – это передовой 32-битный многопоточных механизм баз данных, комбинирующий скорость и производительно с другими возможностями с целью увеличения возможностей обработки транзакций.
  2. Обеспечение механизма восстановления после сбоя, который поддерживает целостность данных даже в случае сбоя системы.
  3. Транзакции в ESE действуют согласованно, что делает технологию ESE подходящей для серверных приложений. ESE кэширует данные таким образом, чтобы обеспечивать высокопроизводительный доступ к данным.
  4. Кроме того, ESE не требовательна, оптимизирована для быстрого сохранения и восстановления данных.

Замечание:Библиотека исполнения ESE (ESENT.DLL) поставлялась в каждом выпуске Windows, начиная с Windows 2000, причем для версий x64 систем Windows XP и Windows Server 2003 поставлялась специальная x64-версия библиотеки исполнения ESE. Поддержка 64-битного издания началась с Exchange 2007; а в Exchange 2003, библиотека для работы с ESE поставлялась только с 32-битным изданием.

Exchange Information Store

Информационное хранилище, являющееся ключевым компонентом в управлении базами данных в Exchange Server, представляет собой две отдельные базы данных. Частная база данных информационного хранилища, Priv.edb, управляет данными в пользовательских почтовых ящиках. Общее информационное хранилище, Pub.edb, управляет данными в общих папках.

Частное хранилище состоит из файлов .edb и .stm. Файл .edb является основным репозиторием для данных почтовых ящиков. К файлу .edb ESE получает прямой доступ. Базовой структурой файла .edb является бинарное дерево. 4 КБ страниц в ESE организованы в таблицы, составляющие большой файл базы данных, содержащий данные по Exchange.

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

Информационное хранилище работает с интерфейсом Messaging Application Programming Interface (MAPI) и механизмом базы данных, чтобы гарантировать, что все пользовательские действия записываются на жестком диске сервера.

Резервное копирование данных

Компании, вне зависимости от их размера, тщательно выполняют планирование восстановления в аварийных ситуациях (Disaster Recovery - DR) для системы отправки сообщений, критичной для собственного бизнеса. Microsoft Exchange Server выпускается со стандартным API, чтобы программным образом выполнять резервное копирование и восстановление хранилищ Exchange (или баз данных). Поскольку Exchange Server базируется на транзакциях, выполнение резервного копирования на уровне файлов или оффлайновое резервное копирование файлов баз данных может привести к потере целостности данных. Лучшим способом убедиться в том, что вы должным образом сохраняете все данные в системе, включая не сохраненные на диск транзакции, является регулярное выполнение онлайнового резервного копирования.

Типы резервного копирования

Microsoft дает возможность выполнять четыре типа резервного копирования целого сервера или отдельной группы хранения. Это следующие типы: Full, Copy, Differential и Incremental.

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

Copy Backup - Данный тип выполняет все то же самое, что и full backup, за исключением усечения файлов журнала. Copy backup может использоваться для создания копии базы данных в целях тестирования и анализа.

Incremental Backup - Incremental backup копирует журналы транзакций с целью записать изменения, произошедшие с момента выполнения последнего incremental backup или full backup, а затем выполняет усечение журналов транзакций.

Differential Backup - Differential backup копирует журналы транзакций, чтобы записать изменения, произошедшие с момента последнего full backup, и не выполняет усечение журналов транзакций.

В последующих параграфах мы посмотрим на различные техники резервного копирования в Exchange Server, предлагаемые Microsoft.

Преимущественно используются две техники резервного копирования и восстановления хранилищ в Exchange:

  1. Подход, основанный на онлайновом потоковом резервном копировании
  2. Подход, основанный на использовании Volume Shadow Service

1. Онлайновое потоковое резервное копирование

Онлайновое резервное копирование с помощью ESE API позволяет вам копировать базы данных Exchange Server на ваше устройство без отключения сервера. Пока Exchange Server выполняет онлайновое резервное копирование, все службы, включая информационное хранилище, продолжают работать в нормальном режиме. Страницы продолжают обновляться в памяти и передаваться в файлы базы данных на диске, транзакции продолжают записываться в файлы журнала, а файл контрольной точки продолжает перемещение.

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

Процесс потокового резервного копирования

При запуске процесса резервного копирования группы хранения в Exchange происходит несколько важных операций. Вот основные этапы процесса резервного копирования:

  1. Когда инициализируется операция full backup, ESE начинает сбрасывать все грязные страницы в кэше на диск и выполняет останов контрольной точки. Контрольная точка не будет перемещаться до тех пор, пока операция резервного копирования не завершится. Важно отметить, что когда запускается частичное резервное копирование, например, differential backup, incremental backup или copy backup, ESE позволяет контрольной точке перемещаться, поскольку операция резервного копирования не затрагивает базы данных.
  2. Следующий этап в процессе резервного копирования включает копирование файлов баз данных. Приложение резервного копирования вызывает процедуры API для передачи ESE списка баз данных, которые нужно скопировать. Эти базы данных представляют собой открытые файлы, поэтому приложение резервного копирования не просто копирует базы данных. Вместо этого ESE начинает отправлять приложению резервного копирования блоки страниц баз данных по 64 КБ (шестнадцать 4 КБ страниц за раз) последовательно. На этом важнейшем этапе ESE высчитывает контрольную сумму для каждой страницы; и любая ошибка вызывает останов операции резервного копирования.
  3. Далее ESE должен сохранить журналы транзакций в набор резервирования. Как уже упоминалось ранее, ESE останавливает контрольную точку в начале резервного копирования. Но, хотя контрольная точка и остановлена, ESE продолжает записывать транзакции в файлы журнала и продолжает сбрасывать грязные страницы из кэша баз данных на диск. Для того, чтобы выполнить резервное копирование файлов журнала, приложение резервного копирования использует соответствующий вызов из API, чтобы запросить список файлов журнала (а также файлов исправлений, если таковые доступны) от ESE. Когда ESE получает этот запрос, он закрывает текущий файл журнала, сохраняет файл как следующее журнальное поколение в последующем списке, и открывает новый файл E0n.log (n обозначает сущность группы хранения файла журнала). В случае с full backup ESE затем возвращает список файлов журнала приложению резервного копирования; а этот список начинается с текущего журнального поколения (в котором остановилась контрольная точка) и завершается журнальным поколением, только что закрытым ESE (т.е. E0n.log минус 1). В случае резервного копирования типа incremental backup или differential backup, ESE возвращает список, начинающийся с самого последнего журнального поколения на диске и завершающийся последним закрытым журнальным поколением. Используя этот список, приложение резервного копирования может открыть дескрипторы к файлам журнала и скопировать их в набор резервирования. В процессе выполнения этой операции, ESE убеждается, что ни одно журнальное поколение не отсутствует из последовательности, переданной приложению резервного копирования.
  4. После того, как файлы журнала будут сохранены в наборе резервирования, они становятся ненужными на диске. При операциях типа full backup и incremental backup, ESE выполняет усечение файлов журнала на диске после завершения резервного копирования журналов транзакций. Какие файлы журнала усекаются ESE, определяется по тому, какое журнальное поколение старше – поколение контрольной точки или поколение, указанное в заголовке базы данных для данного резервного копирования типа full backup.

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

2. Volume Shadow Service

Microsoft Exchange Server 2003 использует службу Volume Shadow Copy Service (VSS), включаемую в операционную систему Microsoft Windows Server 2003 для того, чтобы делать теневые копии томов баз данных и файлов журналов транзакций в Exchange Server 2003.

Что такое VSS?

VSS – это набор COM API, реализующий инфраструктуру, позволяющую производить резервное копирование томов в то время, пока приложения системы продолжают записывать данные в этих томах. Requestors(клиенты), writers(редакторы) и providers(провайдеры) взаимодействуют в рамках инфраструктуры VSS для создания и восстановления shadow copies (теневых копий) тома. Теневая копия тома дублирует все данные, хранящиеся в определенном томе в один четко определенный момент времени. Создавая копию тома только для чтения, программы резервного копирования могут получать доступ к каждому файлу (принадлежащему базам данных Exchange), не мешая остальным программам делать записи в тех же файлах.

Редактор Exchange автоматически устанавливается вместе с Exchange Server 2003. Клиенты могут получить доступ к редактору Exchange только в том случае, если Exchange Server 2003 установлен под операционной системой Windows Server 2003. Утилита vssadmin используется для отображения списка редакторов и провайдеров:

vssadmin list writers - для отображения списка всех редакторов
vssadmin list providers - для отображения списка всех провайдеров

Замечание: Резервные копии VSS недоступны для Exchange Server 2003 в случае, если Exchange Server 2003 установлен под Microsoft Windows 2000 Server.

Компоненты VSS

VSS работает на уровне блоков файловой системы. Есть три главных компонента инфраструктуры VSS: writer(редактор), requester (клиент – приложение резервного копирования) и provider(провайдер) (Более подробную информацию о клиентах, редакторах и провайдерах можно найти в этой статье в MSDN здесь). Служба Volume Shadow Copy координирует взаимодействие между Requestors (приложениями резервного копирования), Writers (приложениями-службами Windows вроде Exchange Server 2003) и Providers (системными, программными или аппаратными компонентами, создающими теневые копии). Чтобы воспользоваться возможностями службы Volume Shadow Copy для резервного копирования Exchange Server 2003, программа резервного копирования должна включать клиент службы Volume Shadow Copy, могущий работать с Exchange Server 2003.

По запросу клиента редактор Exchange подготавливает базы данных Exchange к резервному копированию. Это делается остановкой всех операций чтения/записи с диска и на диск всеми базами данных на 20 секунд. Это называется freezing(заморозка) баз данных. Провайдер должен быть в состоянии сделать теневую копию в этот промежуток, или резервное копирование будет прекращено. После завершения резервного копирования редактор размораживает базы данных.

Процесс резервного копирования с помощью VSS

Процесс резервного копирования включает в себя следующие этапы:

  1. Клиент инициирует процесс резервного копирования. Клиент дает команду редактору подготовить набор резервирования.
  2. Редактор подготавливает данные к копированию. Exchange Server 2003 и другие приложения работают с редакторами, которые подготавливают данные в соответствии с конкретными требованиями приложения. Когда набор резервирования готов, редактор сигнализирует клиенту о том, что можно копировать этот набор.
  3. Провайдер взаимодействует с дисковой системой и контролирует теневое копирование. Получив запрос от клиента, провайдер создает теневую копию.
  4. Клиент сигнализирует об успешном или неудачном завершении редактору, и завершает процесс резервного копирования.

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

Рекомендуемое решение

Sonasoft Corp. помогает автоматизировать процесс резервного копирования и восстановления с диска на диск для Microsoft Exchange, SQL и серверов Windows Server с помощью революционных решений SonaSafe Point-Click Recovery. Созданные с целью упростить и убрать человеческий фактор из процессов резервного копирования и восстановления, решения SonaSafe также централизуют управление множеством серверов и предлагают эффективную с точки зрения затрат стратегию восстановления после аварий «под ключ» для компаний любых размеров. Если вам нужна более подробная информация, посетите веб-сайт Sonasoft .

Итоги

Так какая же технология лучше; потоковая или VSS? У обеих есть определенные преимущества и ограничения. Некоторые из них перечислены ниже:

  • Обе технологии позволяют выполнять резервное копирование баз данных Exchange при работающих хранилищах.
  • Точно известно, что в Exchange Server 2010 потоковый подход выйдет из употребления (подробнее об изменениях в резервном копировании и восстановлении в Exchange 2010 по этой ссылке). Поскольку доступной поддержки ESE не будет, у поставщиков приложений резервного копирования не будет выбора, кроме как воспользоваться технологией VSS для обеспечения функциональности DR для Exchange 2010.
  • VSS поддерживается, только начиная с Exchange 2003 (Windows 2003 Server с SP1). Поэтому единственным вариантом для Exchange 2000 является потоковое резервное копирование и восстановление.
  • Когда база данных копируется с помощью потокового интерфейса API в Exchange, все страницы в базе данных читаются по очереди, и проверяется целостность контрольной суммы для каждой страницы в процессе резервного копирования. Целостность контрольной суммы файлов журналов транзакций также проверяется до того, как они будут скопированы.
  • В процессе резервного копирования с помощью VSS отсутствует возможность для Exchange прочитать каждый файл базы данных целиком и проверить целостность его контрольной суммы. Следовательно, целостность файлов базы данных и журнала транзакций должна проверяться приложением резервного копирования. Можно сделать это, запустив Eseutil; eseutil /k /i (Если вам нужна более подробная информация, посмотрите статьи в MSDN здесь и здесь).
  • Самым важным преимуществом решений на основании VSS является то, что они могут очень быстро восстанавливать данные. Решения VSS наиболее полезны для инсталляций, включающих большие базы данных, которые требуют короткого времени восстановления (менее 60 минут). Это требования за пределами возможностей текущих потоковых решений для резервного копирования.




Рейтинг:  
4.5 (голосов 2)  
 1   2   3   4   5    

Автор: Аднан Хан(Adnan Khan)
  Аднан Хан является техническим менеджером компании Sonasoft.
Эта статья переведена и опубликована с разрешения www.msexchange.org

Эта статья переведена силами и средствами компании Red Line Software. Размещение данного переведенного материала на других сайтах без разрешения компании Red Line Software запрещается.





Печать пластиковых карт - это часть процесса изготовления и производства пластиковых карт
Изготовление и производство пакетов