Конец традиционным резервным копиям благодаря встроенной функциональности в Exchange 2010 (Часть 1)

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

Еще когда предприятия переходили к Exchange 2003 и в большинстве случаев консолидировали свои инфраструктуры передачи сообщений с Exchange, они в то же время вкладывались в дорогое high-end решение SAN, которое использовалось для хранения данных из Exchange и других приложений. Сейчас, поскольку данные из Exchange становятся все более и более значимыми, большие корпорации часто вкладывались в два high-end решения SAN, чтобы обеспечить защиту данных не только с помощью RAID, но и с помощью зеркал SAN, обычно расположенных в двух разных центрах данных. В отличие от Exchange 2007 и Exchange 2010, в Exchange 2003 решения высокой доступности, которые усиливали кластерную функциональность в Windows, обладали только одной копией данных за исключением ситуации, когда данные реплицировались на уровне хранилища или третьесторонним решением на основе репликации. Также в Exchange 2003 были очень строгие требования по вводу\выводу для подсистемы хранения, поэтому насущной необходимостью стало хранение данных Exchange на быстрых и небольших по размеру дисках (диски 136ГБ или меньшего объема 10 или 15 тысяч об./мин. на базе SAS), обычно организованных в конфигурации RAID 10 или RAID 50. Кроме того, Exchange 2003 был ограничен 32-битной архитектурой, а это означало, что сервер Exchange 2003 не мог пользоваться более 4 ГБ памяти.

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

Из-за высокой стоимости хранения у пользователей были серьезные ограничения на почтовые ящики. Нормой было150 МБ и менее. Очень привилегированные пользователи имели почтовый лимит в 250 МБ, но не более того (за исключением крайне редких случаев). Это приводило к двум следствиям. Либо компания вкладывалась в дорогие третьесторонние решения для архивирования, чтобы переместить данные Exchange с SAN на более дешевые диски, либо пользователи перемещали свои данные из почтовых ящиков в PST-файлы, после чего эти данные выходили из-под контроля компании и обычно для них не создавались резервные копии.

С появлением Exchange 2007, который был первой версией, построенной на 64-битной архитектуре, а также включавшей новые функции высокой доступности, например, clustered continuous replication (CCR), все изменилось к лучшему. Exchange теперь не был ограничен 4 ГБ лимитом памяти, что, помимо всего прочего, означало, что требования к вводу/выводу (В Exchange 2007 загрузка устройств ввода/вывода уменьшилась почти на 70 процентов) для подсистемы хранения стали намного ниже по сравнению с Exchange 2003. Имея CCR, компания также могла воспользоваться преимуществами от естественной асинхронной репликации, что сделало репликацию на уровне хранилища и третьесторонние репликационные решения в каком-то смысле устаревшими. В Exchange 2007 SP1 вводилась standby continuous replication (SCR), что дало возможность компаниям иметь более двух копий баз данных. Копии баз данных на целевом сервере SCR даже могли быть копиями с задержкой по времени.

Имея Exchange 2007, IT-отдел в Microsoft переместил все данные Exchange для всех сотрудников Microsoft с зеркального high-end SAN-решения на DAS-решения и теперь мог предлагать почтовые ящики размером до 2GB конечным пользователям и при этом получать миллионы долларов США в год, так как работа на DAS вместо решения хранения на базе SAN значительно уменьшает затраты на хранение. И хотя решения хранения на базе SAN полностью поддерживались, группа Exchange Product попыталась объяснить клиентам компании, почему это было хорошей идеей переместить данные Exchange с SAN на низкозатратное решение на базе DAS. Некоторые клиенты последовали совету, но многие все еще продолжали хранить данные при помощи решений SAN, поскольку они в них уже вложились. И.. угадайте, что? Да, клиенты компании все еще вкладывают деньги в третьесторонние решения для архивирования, потому что хранение всех данных из Exchange на SAN очень дорого.

Когда дело доходит до создания резервных копий Exchange 2007, компании все еще используют такие решения. Хотя большинство все-таки перешло к решениям на базе VSS вместо решений на базе потокового резервного копирования.

И тут появляется Exchange 2010, и практически все меняется даже в большей степени по сравнению с изменениями, привнесенными Exchange 2007. В Exchange 2010 мы снова увидели огромную оптимизацию процедур хранения. В основном вся архитектура хранения была пересмотрена, и в результате мы видим больше улучшений, чем их было за последнее десятилетие! Это означает, что больше нет никакого смысла хранить данные Exchange на быстрых небольших по объему дисках. Теперь вы можете воспользоваться большими и медленными дисками. И да, я сейчас говорю о 1-2 ТБ корпоративных дисках SATA, очень похожих на те, которые стоят в рабочих станциях. Кроме того, новая функция Database Availability Group (DAG) в Exchange 2010 позволяет вам теперь иметь до 16 копий почтовой базы данных. И хотя вряд ли многим понадобится иметь 16 копий одной и той же базы данных, но если у вас их будет 3 или более, у вас появляется возможность обходиться без RAID, используя вместо него JBOD для хранения данных Exchange. Кроме того, одна или более копий баз данных могут быть копиями с задержкой (поддерживается до 14 дней разницы между версиями базы данных против 7 дней в Exchange 2007). Однако помните, что для использования копий с задержкой, вам необходимо иметь как минимум две копии с задержкой на JBOD или 1 такую копию на RAID.

В Exchange 2010 также вводится новая полностью переделанная папка элементов для восстановления (известная как Dumpster 2.0) and функция litigation hold. Папка элементов для восстановления может использоваться для кратковременного и долговременного консервации данных, а функция litigation hold – для ситуаций приостановления работы с определенными данными согласно судебным предписаниям или для консервации данных на очень большой срок. Кроме того, в Exchange 2010 включен новый персональный архив (который можно просматривать через OWA 2010, Outlook 2010, а в Exchange 2010 SP1 также через Outlook 2007), который можно включить для любого пользователя и таким образом убрать те самые непопулярные PST-файлы. И, наконец, в Exchange 2010 включены новые политики длительного использования, которые можно назначать для папок или объектов в почтовом ящике, чтобы данные перемещались из почтового ящика в персональный архив, связанный с этим почтовым ящиком.

Благодаря всему вышеприведенному, а также другим новым возможностям, многие организации попрощались с high-end SAN и, следовательно, дорогими дисками, дорогими третьесторонними решениями для архивирования и часто дорогими решениями для резервного копирования, что резко снизило затраты на IT.

В этой статье я предлагаю вам обзор того, как все это работает. Материала у нас много, так что давайте двигаться вперед.

Улучшения в восстановлении отдельных объектов

Практически все время существования Exchange конечные пользователи имели в своем распоряжении возможность восстанавливать удаленные объекты.

Давайте коротко вспомним о том, что представляет собой функция восстановления удаленных объектов.

Когда пользователь удаляет один или несколько объектов из своего почтового ящика, они перемещаются в папку удаленных объектов. Когда папка удаленных объектов очищается, объекты не удаляются из почтового ящика. Вместо этого они помечаются флагом ptagDeletedOnFlag, который делает эти объекты невидимыми и ненаходимыми с почтовых клиентов, таких как Outlook и Outlook Web App (OWA).

Когда почтовый объект удаляется 'нормальным' способом (с помощью клавиши delete или после нажатия правой кнопки мыши), это считается «мягким удалением», и, как уже упоминалось, при этом объект(ы) просто перемещаются в папку удаленных объектов. Вы также можете нажать shift и delete (это будет «жесткое удаление»), при этом объекты навсегда удаляются из устройства хранения, если вы не используете Outlook 2007/2010 или Outlook 2003 (или более ранние версии) с включенным ключом реестра DumpsterAlwaysOn для клиентов, где установлен Outlook.

То есть, если вы работаете с Outlook 2007/2010, или у вас включен ключ DumpsterAlwaysOn на более старом клиенте, «мягко» удаленные и «жестко» удаленные объекты можно просматривать и восстанавливать при помощи функции recover deleted items, пока они не будут очищены, то есть навсегда удалены с устройства хранения. В Exchange 2003 настройки предполагали 7-дневный период хранения удаленных объектов по умолчанию. В Exchange 2007 эти настройки были изменены до 14 дней, что по умолчанию принимается и для Exchange 2010. Эта настройка изменяется на уровне почтовой базы данных и наследуется почтовыми ящиками, хранящимися в соответствующей почтовой базе данных, но менять эту настройку также можно и на уровне почтового ящика.

Рисунок 1: Окно хранения удаленных объектов для базы данных Exchange 2003

Рисунок 2: Окно хранения удаленных объектов, унаследованное почтовым ящиком в Exchange 2003

В Exchange 2010 функция восстановления удаленных объектов была значительно переработана, чтобы лучше поддерживать кратковременную и долговременную консервацию данных. Функция восстановления удаленных элементов больше не использует флаг ptagDeletedOnFlag для скрывания объектов, но имеет теперь почтовую папку под названием 'Recoverable items', в которой есть три подпапки: Deletions, Versions и Purges. Эта новая папка хранится в поддереве Non-IPM почтового ящика, как вы видите на Рисунке 3, где я открыл поддерево Non-IPM с помощью инструмента MFCMAPI.

Рисунок 3: Папка Recoverable Items в поддереве Non-IPM, просматриваемая с помощью инструмента MFCMAPI

Когда почтовый объект удаляется с помощью shift+delete или удаляется из папки удаленных объектов, теперь он перемещается в подпапку Deletions в папке Recoverable items. В Exchange 2010 по умолчанию объекты хранятся в папке Deletions, так как это и было в предыдущих версиях Exchange. Когда время для данного объекта истекает, объект убирается из устройства хранения. Если пользователь удалил объект случайно, и он был убран из устройства хранения, он должен быть восстановиться при обычном восстановлении резервной копии при необходимости.

Некоторые из вас, возможно, удивляются, в чем же преимущества всех этих изменений. Сейчас мы к этому перейдем.

В Exchange 2010 у почтовых ящиков есть несколько новых атрибутов. Один из них - 'SingleItemRecoveryEnabled', который по умолчанию установлен в false (Рисунок 4).

Увеличить

Рисунок 4: Восстановление отдельных объектов по умолчанию отключено

Включить его можно с помощью следующей команды:

Set-Mailbox 'Identity hew 'SingleItemRecoveryEnabled $true

Увеличить

Рисунок 5: Предупреждение о том, что настройка может не вступить в силу немедленно

При включении мы получаем предупреждение о том, что может пройти до 60 минут до того, как новая настройка вступит в силу. Этот промежуток времени зависит от размера и сложности топологии Active Directory. В односайтной топологии AD это не должно занять больше нескольких минут.

Когда для почтового ящика включено 'Single Item Recovery', все объекты, удаляемые из папки Recoverable Items не будут навсегда удаляться из почтового ящика, а вместо этого будут отправлены в подпапку 'Purges' папки Recoverable Items, откуда его и удалять в случае, если срок его хранения превысит 14 дней (если именно такие настройки у базы данных, где хранится данный почтовый ящик). Это значит, что пользователь ни случайно, ни умышленно не сможет навсегда удалять объекты из своего почтового ящика. Все такие объекты окажутся в подпапке 'Purges', к которой у пользователя нет доступа.

Замечание:Даже если Single Item Recovery настроено как 'false', важно обратить внимание на то, что все календарные объекты будут храниться 120 дней, и только после этого будут удалены.

Кроме того, включение 'Single Item Recovery' для почтового ящика добавляет функциональность отслеживания новых версий. Конкретнее, когда/если объект почтового ящика модифицируется, инициируется так называемое 'копирования при записи', при котором начальный объект перемещается в подпапку 'Versions' в папке Recoverable Items, а новая копия размещается в поддеревьях IPM.Note и IPM.Post. Это очень полезная функция в ситуациях legal hold: так как вы всегда сможете найти оригинальную копию нужного объекта.

Увеличивая окно хранения удаленных объектов до 30, 60, 90 дней или даже до года (в зависимости от RPO в вашей организации) вместе с включением Single Item Recovery для всех почтовых ящиков, вы лишаетесь необходимости в решении для регулярного резервного копирования, когда речь заходит о восстановлении объектов из почтовых ящиков организации.

Рисунок 6: Окно хранения удаленных объектов установлено на 90 дней

Обычно пользователь может восстановить объект(ы) с помощью функции восстановления объектов, а в том случае, если она недоступна или неприменима, тогда вы как администратор/консультант Exchange можете восстановить объекты с помощью новой функции поиска по почтовому ящику, что я продемонстрирую в части 2 этой многочастной статьи.