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

Чтобы прочитать другие статьи этого цикла, перейдите по ссылкам:

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

Введение

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

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

Имитация повреждения почтового ящика

Чтобы попробовать восстановить данные Exchange из отсроченной копии баз данных, давайте сымитируем ситуацию, когда третьестороннее приложение повреждает значительный объем данных в почтовом ящике. В нашем примере мы просто удалим все 158 сообщений, хранившихся в подпапке в Inbox под названием 'Test', но будем считать, что эти сообщения повреждены третьесторонним приложением.

Сначала удаляем сообщения из папки 'Test'.

Теперь удаляем их из папки Deleted Items.

И теперь убираем их из папки Recoverable Items.

И теперь у нас появилась задача по восстановлению.

Восстановление потерянных данных почтового ящика из отсроченной копии баз данных

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

Это осуществляется при помощи следующей команды:

Suspend-MailboxDatabaseCopy MDB01\E2K10EX10 'SuspendComment 'Restore from point in time'

После этого неплохо было бы сделать независимый от Exchange снимок тома, где хранятся отсроченная копия базы данных и соответствующий журнальный поток. Это можно проделать с помощью инструмента в Windows Server под названием vssadmin.exe. В нашей тестовой среде база данных и соответствующий журнальный поток хранятся на диске E:, поэтому запускаем следующую команду:

Vssadmin.exe create shadow /For=e:

После создания снимка мы можем просмотреть подробности о нем с помощью следующей команды:

Vssadmin.exe list shadows

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

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

Следующим шагом является удаление файла .chk для отсроченной копии базы данных.

Сейчас отсроченная база данных находится в состоянии 'Dirty Shutdown', что можно проверить, запустив команду, показанную ниже, из папки, где находится файл EDB:

Eseutil /MH 'MDB01.edb'

Чтобы вернуть копию в состояние 'Clean Shutdown', нужно переместить оставшиеся файлы журнала:

Eseutil /r e02 /a

Давайте еще раз запустим Eseutil /MH 'MDB01.edb'. Видно, что база данных теперь находится в состоянии 'Clean Shutdown', и готова к использованию в восстановительных целях. Поэтому давайте скопируем ее в LUN для восстановления и продолжим процесс отсюда. Такие действия полезны, так как вы можете вернуть выделенный снимок и вернуться к репликации сразу после создания копии.

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

New-MailboxDatabase 'Name 'Recovery Database' 'Server E2K10EX10 'EdbFilePath 'C:\RDB\MDB01.edb' 'LogFolderPath C:\RDB\ -Recovery

Давайте подключим базу данных восстановления. Это можно сделать так:

Mount-Database 'Recovery Database'

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

Get-MailboxStatistics ' Database 'Recovery Database'

Все выглядит хорошо, поэтому можно запускать восстановление:

Restore-Mailbox 'Identity 'Henrik Walther' 'RecoveryDatabase 'Recovery Database'

Щелкните 'Yes' на подтверждающем сообщении. Отсутствовавшие сообщения теперь оказались в почтовом ящике.

После завершения процесса восстановления мы можем подключиться к почтовому ящику, и увидим, что теперь все «испорченные» сообщения вернулись.

Очистка и возврат отсроченной базы данных в начальное состояние

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

Давайте сначала отключим базу данных восстановления, чтобы можно было удалить файл MDB01.edb, который мы скопировали в LUN восстановления:

Dismount-Database 'Recovery Database'

Теперь нужно удалить восстанавливаемую базу данных из Exchange:

Remove-MailboxDatabase 'Recovery Database'

Теперь удалите папку на LUN восстановления, содержащую файл EDB.

Чтобы вернуться к снимку, нужно сначала получить подробный список снимков:

Vssadmin list shadows

Обратите внимание на ID теневой копии, после чего запускайте следующую команду:

Vssadmin revert shadow /Shadow={3711ecf7-a116-4734-bbe6-802536505598}

Теперь мы видим: теневая копия, файл .chk и соответствующий журнальный поток вернулись к своему начальному состоянию.

Теперь мы можем возобновить репликацию отсроченной копии базы данных:

Resume-MailboxDatabaseCopy MDB01\E2k10EX10

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

Suspend-MailboxDatabaseCopy 'Identity MDB01\E2K10Ex10 -ActivationOnly

Задача восстановления успешно решена, и, хотя она предполагает прохождение нескольких этапов, ничего сложного в ней нет. Ну а поскольку вам вряд ли потребуется ее решать ежедневно или даже еженедельно, то все прекрасно, и замечательно подходит в качестве хорошего решения по резервному копированию.

Этим мы завершаем нашу многочастную статью. Надеюсь, вам удалось почерпнуть что-то полезное из этих статей.

Чтобы прочитать другие статьи этого цикла, перейдите по ссылкам:

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