none
Подмена базы в Exchange 2013 RRS feed

  • Вопрос

  • Добрый день. Имеется две базы на одном сервере, на разных томах. База "А" - упала, теперь она с ошибками индексации, в статусе "Dirty shutdown". Т.к. её невозможно было подключить и что-либо поправить, в таком виде (вся директория вместе с логами, они внутри каталога с базой) была скопирована на другой том (копировать-вставить). Копия (база "Б") пропущена через ESEUTIL, до получения результата "clean shutdown" + была выполнена процедура дефрагментации.

    Проблема в том, что при попытке подключить исправную базу "Б", появляется логичная ошибка, что база с таким именем уже существует - это база "А" (её всё еще видно через ецп, она отключена).

    Как подменить базу, наиболее корректно? Есть опасения, что если просто запихнуть логи, файло и саму базу "Б" на том, где лежит база "А", по тому же пути, с заменой всего, что заменяется, ничего не заведётся. Так ли это?

    Буду признателен за любую информацию, спасибо.

    п.с. рекавери базы и бэкапов нет.



    • Изменено Astalf 25 июля 2018 г. 19:18
    25 июля 2018 г. 18:31

Ответы

  • Добрый день. Имеется две базы на одном сервере, на разных томах. База "А" - упала, теперь она с ошибками индексации, в статусе "Dirty shutdown". Т.к. её невозможно было подключить и что-либо поправить, в таком виде (вся директория вместе с логами, они внутри каталога с базой) была скопирована на другой том (копировать-вставить). Копия (база "Б") пропущена через ESEUTIL, до получения результата "clean shutdown" + была выполнена процедура дефрагментации.

    Проблема в том, что при попытке подключить исправную базу "Б", появляется логичная ошибка, что база с таким именем уже существует - это база "А" (её всё еще видно через ецп, она отключена).

    Как подменить базу, наиболее корректно? Есть опасения, что если просто запихнуть логи, файло и саму базу "Б" на том, где лежит база "А", по тому же пути, с заменой всего, что заменяется, ничего не заведётся. Так ли это?

    Буду признателен за любую информацию, спасибо.

    п.с. рекавери базы и бэкапов нет.



    Чтобы подменить файл базы нужно убрать из её директории все файлы *.log, *.chk, скопировать туда файл .edb (т.к. БД в Clean Shutdown, то журналы транзакций для её монтирования не нужны), и указать Exchange, что можно монтировать базу после записи на её место другого файла: Set-MailboxDatabase -Identity <DatabaseIdParameter> -AllowFileRestore $true (можно это сделать и через EAC, но где именно - точно не помню). После это можно смонтировать базу и надеяться, что eseutil /p ничего критичного не потерял. Если после этого будут проблемы с какими-нибудь п/я, используйте New-MailboxRestoreRequest для исправления.

    Слава России!


    • Изменено M.V.V. _ 26 июля 2018 г. 8:04
    • Помечено в качестве ответа Astalf 26 июля 2018 г. 11:15
    26 июля 2018 г. 8:03

Все ответы

  • Это так, ничего не заработает.

    Для начала сделайте бэкап всего что есть, чтобы не сделать хуже (можно просто обычной копипастой при остановленных службах эксча).

    Поскольку теперь у вас уже есть восстановленный файл edb, то вы можете скопировать его на прежнее место, где в данный момент лежит битый файл с логами и прочими служебными файлами. Но! Предварительно вам нужно дропнуть все файлы и папки из каталога с базой так, чтобы потом в каталоге остался только один исправленный edb. В таком случае должно взлететь.

    25 июля 2018 г. 19:35
  • 26 июля 2018 г. 6:57
    Модератор
  • Павел, благодраю за ссылки. Материал полезный, но к сожалению не моя ситуация. 
    26 июля 2018 г. 7:46
  • Егор, объясните, пожалуйста, что Вы подразумеваете под словом "дропнуть" ?
    26 июля 2018 г. 7:47
  • Добрый день. Имеется две базы на одном сервере, на разных томах. База "А" - упала, теперь она с ошибками индексации, в статусе "Dirty shutdown". Т.к. её невозможно было подключить и что-либо поправить, в таком виде (вся директория вместе с логами, они внутри каталога с базой) была скопирована на другой том (копировать-вставить). Копия (база "Б") пропущена через ESEUTIL, до получения результата "clean shutdown" + была выполнена процедура дефрагментации.

    Проблема в том, что при попытке подключить исправную базу "Б", появляется логичная ошибка, что база с таким именем уже существует - это база "А" (её всё еще видно через ецп, она отключена).

    Как подменить базу, наиболее корректно? Есть опасения, что если просто запихнуть логи, файло и саму базу "Б" на том, где лежит база "А", по тому же пути, с заменой всего, что заменяется, ничего не заведётся. Так ли это?

    Буду признателен за любую информацию, спасибо.

    п.с. рекавери базы и бэкапов нет.



    Чтобы подменить файл базы нужно убрать из её директории все файлы *.log, *.chk, скопировать туда файл .edb (т.к. БД в Clean Shutdown, то журналы транзакций для её монтирования не нужны), и указать Exchange, что можно монтировать базу после записи на её место другого файла: Set-MailboxDatabase -Identity <DatabaseIdParameter> -AllowFileRestore $true (можно это сделать и через EAC, но где именно - точно не помню). После это можно смонтировать базу и надеяться, что eseutil /p ничего критичного не потерял. Если после этого будут проблемы с какими-нибудь п/я, используйте New-MailboxRestoreRequest для исправления.

    Слава России!


    • Изменено M.V.V. _ 26 июля 2018 г. 8:04
    • Помечено в качестве ответа Astalf 26 июля 2018 г. 11:15
    26 июля 2018 г. 8:03
  • Благодарю за информацию! Буду пробовать, сообщу по результатам.
    26 июля 2018 г. 8:11
  • Егор, объясните, пожалуйста, что Вы подразумеваете под словом "дропнуть" ?
    удалить. см. сообщение M.V.V. _, он успел написать раньше)
    26 июля 2018 г. 8:27
  • Чтобы подменить файл базы нужно убрать из её директории все файлы *.log, *.chk, скопировать туда файл .edb (т.к. БД в Clean Shutdown, то журналы транзакций для её монтирования не нужны), и указать Exchange, что можно монтировать базу после записи на её место другого файла: Set-MailboxDatabase -Identity <DatabaseIdParameter> -AllowFileRestore $true (можно это сделать и через EAC, но где именно - точно не помню). После это можно смонтировать базу и надеяться, что eseutil /p ничего критичного не потерял. Если после этого будут проблемы с какими-нибудь п/я, используйте New-MailboxRestoreRequest для исправления.


    Слава России!


    База взлетела, спасибо!

    Что не выполнял:

    1) Не останавилвал службы

    2) Из каталога с мёртвой базой "А" удаляется всё, кроме папки с метаданными. Она удерживается службами.

    3) После копирования исправной базы "Б" в каталог проблемной базы "А", ничего подцеплять не нужно.

    Если имена баз одинаковы (и база "А" была видна из EAC/ECP) - всё подхватывается самостоятельно!


    • Изменено Astalf 26 июля 2018 г. 16:43
    26 июля 2018 г. 10:10