none
Закончилось место на сервере с архивными БД RRS feed

  • Вопрос

  • Доброго времени суток. Случилась беда. Закончилось место на сервере с архивными базами данных. 

    Часть баз висит отключенным с ошибками FailedAndSuspended. 

    При попытки восстановления логов выдает ошибку 

    Operation terminated with error -541 (JET_errLogFileSizeMismatch, actual log file size does not match JET_paramLogFileSi
    ze) after 1.703 seconds.

    Google мне не может найти по этому коду ничего...

    29 октября 2018 г. 6:44

Ответы

  • Это все было ожидаемо. Ради интереса пробегитесь по логам, это будет быстро.

    Ваши следующие шаги - забэкапить каталог с базой и всеми файлами на всякий случай, а потом выполнить hard recover. Это единственный вариант, поскольку какие-то логи у вас битые.

    После hard recover удаляете все файлы в каталоге, кроме .edb, пробуете смонтировать

    • Помечено в качестве ответа Dobrohotov Vladimir 30 октября 2018 г. 10:09
    29 октября 2018 г. 18:33
  • На данный момент по совету коллеги перенес E0X.chk файл в другое место и запустил eseutil с ключами /R /a. 

    Процесс пошел но медленно 

     

    Вместо того, чтобы долго ждать, определите  командой eseutil /mh имя базы.edb какие логи нужны для recovery (там написаны номера, после Logs required, кажется). После этого проверяйте, есть ли у вас все файлы этих логов (последний может иметь укороченное имя - типа E04.log) и правильного ли они размера (1 МБ). Если тут всё в порядке, то убирайте другие файлы логов и запускайте recovery. Если нет, то увы - только восстановление из резервной копии (или eseutil /p как его неполноценная замена).

    PS Интересно, кто и зачем придумал называть eseutil /p "hard recovery"? Когда эта операция испокон веков была "repair" (или даже "lossy repair"), а "hard recovery" назывался процесс применения текущих логов после восстановления из бэкапа (для eseutil это делалось с ключом /cc)?


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


    • Изменено M.V.V. _ 29 октября 2018 г. 19:00
    • Помечено в качестве ответа Dobrohotov Vladimir 30 октября 2018 г. 10:09
    29 октября 2018 г. 18:59
  • Вам изначально надо было всю папку забэкапить на всякий случай.

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

    • Помечено в качестве ответа Dobrohotov Vladimir 30 октября 2018 г. 10:09
    30 октября 2018 г. 9:17
  • Переименовал папку с логами и создал новую чистую и подключилась
    • Помечено в качестве ответа Dobrohotov Vladimir 30 октября 2018 г. 10:10
    30 октября 2018 г. 9:32

Все ответы

  • Добрый день.

    А место вы хотя бы освободили на этих дисках?

    29 октября 2018 г. 6:45
  • Место добавил 
    29 октября 2018 г. 6:55

  • Проверяйте статус через /MH.

    Проверяйте наличие логов через /ML.

    Делайте soft recovery через /R

    Перед манипуляциями лучше скопировать данные в отдельную папку.

    29 октября 2018 г. 7:44
  • Пробегитесь по статье: https://blog.bissquit.com/mail-servers/exchange-server/vosstanovlenie-baz-dannyh-exchange-2013/

    Аккуратнее с hard recovery, всегда имейте бэкап

    29 октября 2018 г. 7:48
  • На данный момент по совету коллеги перенес E0X.chk файл в другое место и запустил eseutil с ключами /R /a. 

    Процесс пошел но медленно 

     
    29 октября 2018 г. 8:53
  • Что-то мне подсказывает, что у вас все равно софт рековер не пройдет и придется по-грубому действовать)

    А так он без чекпоинта просто пошел проверять все логи, которые есть. Процесс долгий.

    Вы логи отдельно проверяли? Как-то так будет выглядеть команда:

    eseutil.exe /ml E01

    Если логов много, сделайте вывод в файл и ужа там посмотрите что прилетит.

    • Изменено Egor Vasilev 29 октября 2018 г. 9:05
    29 октября 2018 г. 9:03
  • Да процесс долго идет, тоже понял что он логи все шерстит.. я запустил один раз с ключом /ml увидел, что там долго (~44 тысячи файликов) и отменил.. 10% процентов прошло пока терпит. Можно было бы с бэкапа восстановить, но оказалось, что случайно попали в архивную базу данных основные почтовые ящики :( скрипт видимо некорректно отрабатывал какое то время и создавал новые почтовые ящики в архивной базе данных..  
    29 октября 2018 г. 9:12
  • Сделать проверку логов было быстрее, чем запускать софт рекавер))

    Результаты по 44к файлов лучше выплевывать в отдельный файлик, чем в консоль.

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

    Базу данных, в которой нужно создавать ящики, нужно указывать в явном виде, иначе будет рандом.

    29 октября 2018 г. 9:14
  • Вопрос, можно ли парралельно запустить команду с выгрузкой в текстовый файл проверку логов? боязно сейчас отменять текущее восстановление)
    29 октября 2018 г. 9:22
  • Не надо такое вытворять. Дождитесь результата, иначе сервер ляжет по иопсам и выполнение обоих задач придется ждать очень долго.
    29 октября 2018 г. 10:05
  • эх на 98% вышла ошибка( проверяло почти весь день) 

    

    я так понимаю теперь надо выгрузить в файлик eseutil /ML чтобы точно знать что там последние логи повреждены? 

    29 октября 2018 г. 18:18
  • Это все было ожидаемо. Ради интереса пробегитесь по логам, это будет быстро.

    Ваши следующие шаги - забэкапить каталог с базой и всеми файлами на всякий случай, а потом выполнить hard recover. Это единственный вариант, поскольку какие-то логи у вас битые.

    После hard recover удаляете все файлы в каталоге, кроме .edb, пробуете смонтировать

    • Помечено в качестве ответа Dobrohotov Vladimir 30 октября 2018 г. 10:09
    29 октября 2018 г. 18:33
  • На данный момент по совету коллеги перенес E0X.chk файл в другое место и запустил eseutil с ключами /R /a. 

    Процесс пошел но медленно 

     

    Вместо того, чтобы долго ждать, определите  командой eseutil /mh имя базы.edb какие логи нужны для recovery (там написаны номера, после Logs required, кажется). После этого проверяйте, есть ли у вас все файлы этих логов (последний может иметь укороченное имя - типа E04.log) и правильного ли они размера (1 МБ). Если тут всё в порядке, то убирайте другие файлы логов и запускайте recovery. Если нет, то увы - только восстановление из резервной копии (или eseutil /p как его неполноценная замена).

    PS Интересно, кто и зачем придумал называть eseutil /p "hard recovery"? Когда эта операция испокон веков была "repair" (или даже "lossy repair"), а "hard recovery" назывался процесс применения текущих логов после восстановления из бэкапа (для eseutil это делалось с ключом /cc)?


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


    • Изменено M.V.V. _ 29 октября 2018 г. 19:00
    • Помечено в качестве ответа Dobrohotov Vladimir 30 октября 2018 г. 10:09
    29 октября 2018 г. 18:59
  • А долго по времени может идти hard recovery(repair) ? eseutil /p db.edb

    p.s. удаление поврежденных логов(всего 1 лог кстати был поврежден) не помогло... остается только repair

    30 октября 2018 г. 6:06
  • Зависит от многих факторов.
    30 октября 2018 г. 6:12
  • Восстановление завершилось. Вы, писали что нужно теперь чтото подчистить. НЕ подскажите что именно) а то я боюсь уже чтото трогать. Я думаю лучше даже перенесу.

    p.s. еще советуют запустить бэкап базы, чтобы во время бэкапа подрезались логи.


    30 октября 2018 г. 9:13
  • Вам изначально надо было всю папку забэкапить на всякий случай.

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

    • Помечено в качестве ответа Dobrohotov Vladimir 30 октября 2018 г. 10:09
    30 октября 2018 г. 9:17
  • Статус БД проверьте, если Clean Shutdown, то попытайтесь смонтировать. Hard Recovery подразумевает потерю информации в процессе починки.
    30 октября 2018 г. 9:18
  • Статус был CleanShutdown

    но при попытке монтирования 

    

    30 октября 2018 г. 9:28
  • Переименовал папку с логами и создал новую чистую и подключилась
    • Помечено в качестве ответа Dobrohotov Vladimir 30 октября 2018 г. 10:10
    30 октября 2018 г. 9:32
  • Спасибо всем, кто помогал. 

    Заработало, пробежался по ящикам людей вроде криминала с потерей данных нету.

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

    30 октября 2018 г. 9:37
  • Обращайтесь!

    Пометьте, пожалуйста, сообщения, которые вам помогли, как решение проблемы.

    30 октября 2018 г. 10:08