В третьей части этой многочастной статьи мы говорили о том, чем могут оказаться полезны для вашей организации отсроченные копии баз данных. Кроме того, я поэтапно показал, как настраивать отсроченные копии баз данных.
В четвертой части (кстати, последней) я покажу вам, как работать со снимками данных с помощью отсроченной копии баз данных. Имитация повреждения почтового ящикаЧтобы попробовать восстановить данные Exchange из отсроченной копии баз данных, давайте сымитируем ситуацию, когда третьестороннее приложение повреждает значительный объем данных в почтовом ящике. В нашем примере мы просто удалим все 158 сообщений, хранившихся в подпапке в Inbox под названием 'Test', но будем считать, что эти сообщения повреждены третьесторонним приложением. Сначала удаляем сообщения из папки 'Test'. Рисунок 1: Удаление содержимого папки Test Теперь удаляем их из папки Deleted Items. Рисунок 2: Удаление объектов из папки Deleted Items И теперь убираем их из папки Recoverable Items. Рисунок 3: Убираем объекты из папки Recoverable Items И теперь у нас появилась задача по восстановлению. Восстановление потерянных данных почтового ящика из отсроченной копии баз данныхСамым первым шагом, который нужно предпринять для восстановление данных из отсроченной копии базы данных, является приостановка репликации для данной конкретной копии базы данных. Это осуществляется при помощи следующей команды: Suspend-MailboxDatabaseCopy MDB01\E2K10EX10 'SuspendComment 'Restore from point in time'
Увеличить
Рисунок 4: Приостановка репликации для отсроченной копии базы данных После этого неплохо было бы сделать независимый от Exchange снимок тома, где хранятся отсроченная копия базы данных и соответствующий журнальный поток. Это можно проделать с помощью инструмента в Windows Server под названием vssadmin.exe. В нашей тестовой среде база данных и соответствующий журнальный поток хранятся на диске E:, поэтому запускаем следующую команду: Vssadmin.exe create shadow /For=e:
Рисунок 5: Создание снимка базы данных и тома журнала После создания снимка мы можем просмотреть подробности о нем с помощью следующей команды: Vssadmin.exe list shadows
Рисунок 6: Список снимков VSS Теперь настало время для определения файлов журнала, которые нужно переместить в отложенную копию базы данных. Для этого можно просто просмотреть время и даты файлов журнала через Windows Explorer. Нам нужно удалить или переместить все файлы журнала, созданные при возникновении ситуации и все файлы журнала, созданные после. Как уже упоминалось, у нас есть выбор между удалением файлов журнала или перемещением их в другую папку. Позже они будут восстановлены с помощью сделанного нами снимка, поэтому их тоже можно удалить. Увеличить
Рисунок 7: Перемещение нужных файлов журнала перед восстановлением Следующим шагом является удаление файла .chk для отсроченной копии базы данных. Сейчас отсроченная база данных находится в состоянии 'Dirty Shutdown', что можно проверить, запустив команду, показанную ниже, из папки, где находится файл EDB: Eseutil /MH 'MDB01.edb'
Рисунок 9: Копия отсроченной базы данных сейчас находится в состоянии dirty shutdown Чтобы вернуть копию в состояние 'Clean Shutdown', нужно переместить оставшиеся файлы журнала: Eseutil /r e02 /a
Увеличить
Рисунок 10: Перемещение файлов журнала в копию отсроченной базы данных Давайте еще раз запустим Eseutil /MH 'MDB01.edb'. Видно, что база данных теперь находится в состоянии 'Clean Shutdown', и готова к использованию в восстановительных целях. Поэтому давайте скопируем ее в LUN для восстановления и продолжим процесс отсюда. Такие действия полезны, так как вы можете вернуть выделенный снимок и вернуться к репликации сразу после создания копии. Увеличить
Рисунок 11: Проверка состояния clean shutdown у отсроченной копии базы данных Чтобы восстановить данные из отсроченной базы данных, нужно подключить ее через базу данных восстановления. Поэтому давайте создадим такую базу данных с помощью команды: New-MailboxDatabase 'Name 'Recovery Database' 'Server E2K10EX10 'EdbFilePath 'C:\RDB\MDB01.edb' 'LogFolderPath C:\RDB\ -Recovery
Рисунок 12: Создание базы данных восстановления Давайте подключим базу данных восстановления. Это можно сделать так: Mount-Database 'Recovery Database'
Увеличить
Рисунок 13: Подключение базы данных восстановления Перед началом восстановления данных из базы данных восстановления, запустим следующую команду, чтобы посмотреть статистику версии почтовой базы данных, откуда мы будем восстанавливать данные: Get-MailboxStatistics ' Database 'Recovery Database'
Рисунок 14: Список почтовых ящиков и элементов в базе данных восстановления Все выглядит хорошо, поэтому можно запускать восстановление: Restore-Mailbox 'Identity 'Henrik Walther' 'RecoveryDatabase 'Recovery Database'
Увеличить
Рисунок 15: Восстановление потерянных сообщений из базы данных восстановления Щелкните 'Yes' на подтверждающем сообщении. Отсутствовавшие сообщения теперь оказались в почтовом ящике. Увеличить
Рисунок 16: Потерянные элементы теперь оказались в нужном почтовом ящике После завершения процесса восстановления мы можем подключиться к почтовому ящику, и увидим, что теперь все «испорченные» сообщения вернулись. Рисунок 17: Сообщения успешно восстановлены Очистка и возврат отсроченной базы данных в начальное состояниеТеперь осталось только очистить базу данных, вернуться к моменту снимка и возобновить репликацию. Давайте сначала отключим базу данных восстановления, чтобы можно было удалить файл MDB01.edb, который мы скопировали в LUN восстановления: Dismount-Database 'Recovery Database'
Рисунок 18: Отключение базы данных восстановления Теперь нужно удалить восстанавливаемую базу данных из Exchange: Remove-MailboxDatabase 'Recovery Database'
Увеличить
Рисунок 19: Удаление базы данных восстановления из Exchange Теперь удалите папку на LUN восстановления, содержащую файл EDB. Чтобы вернуться к снимку, нужно сначала получить подробный список снимков: Vssadmin list shadows
Рисунок 20: Список снимков VSS Обратите внимание на ID теневой копии, после чего запускайте следующую команду: Vssadmin revert shadow /Shadow={3711ecf7-a116-4734-bbe6-802536505598}
Увеличить
Рисунок 21: Возвращение к моменту снимка Теперь мы видим: теневая копия, файл .chk и соответствующий журнальный поток вернулись к своему начальному состоянию. Увеличить
Рисунок 22: Файл .chk и начальный файл EDB восстановлены Теперь мы можем возобновить репликацию отсроченной копии базы данных: Resume-MailboxDatabaseCopy MDB01\E2k10EX10 Увеличить
Рисунок 23: Продолжение репликации из отсроченной копии базы данных Также обратите внимание, что вам нужно будет запустить следующую команду, чтобы блокировать активацию отсроченной копии базы данных: Suspend-MailboxDatabaseCopy 'Identity MDB01\E2K10Ex10 -ActivationOnly
Задача восстановления успешно решена, и, хотя она предполагает прохождение нескольких этапов, ничего сложного в ней нет. Ну а поскольку вам вряд ли потребуется ее решать ежедневно или даже еженедельно, то все прекрасно, и замечательно подходит в качестве хорошего решения по резервному копированию. Этим мы завершаем нашу многочастную статью. Надеюсь, вам удалось почерпнуть что-то полезное из этих статей.
|