Ошибка:
eseutil (2860) JetDBUtilities - 3928: файл журнала \? \ GLOBALROOT \ Device \ HarddiskVolumeShadowCopy84 \ Program Files \ Microsoft \ Exchange Server \ V14 \ Mailbox \ База данных почтовых ящиков 0501047257 \ E000000B4E0.log поврежден, недействителен или недоступен (ошибка -501 ) и не может быть использован. Если этот файл журнала требуется для восстановления, для успешного завершения восстановления потребуется хорошая копия файла журнала.
В настоящий момент Exchange работает нормально.
Я просмотрел эту ошибку, и похоже, что указанный файл журнала может быть навсегда поврежден (я думаю, что это означает ошибку-501). К сожалению, хорошая версия этого файла журнала слишком стара для наших резервных копий.
В Интернете есть различные предложения по запуску eseutil / mh, чтобы проверить базу данных и посмотреть, в каком состоянии она находится, и проверить, действительно ли требуется этот файл журнала. Поскольку все это требует размонтирования базы данных, я ищу лучший первый шаг, чтобы избежать каких-либо проблем, например, если база данных не будет повторно подключаться. Есть ли способ, например, создать резервную копию электронной почты каждого перед отключением базы данных, не переходя по маршруту pst?
Я только что провел эксперимент на виртуальной машине, чтобы попытаться имитировать вашу ситуацию. Я намеренно повредил один из файлов журнала транзакций и использую Windows Server Backup в качестве приложения для резервного копирования. Все, что я говорю ниже, основано на этом эксперименте, но реальность не должна сильно отличаться.
Даже если вы говорите, что в данный момент все работает нормально, вы совершенно правы, что беспокоитесь об этой ошибке, и, задав этот вопрос, вы, возможно, только что избавили свое будущее от горя и паники.
Во-первых, немного истории о том, почему вам следует беспокоиться. Когда Exchange успешно завершает резервное копирование, он сбрасывает (удаляет) журналы зафиксированных транзакций, поэтому, если ваши резервные копии действительно завершаются сбоем с этим сообщением, очень высока вероятность, что ваши журналы транзакций на самом деле не очищаются, а накапливаются. Если старые журналы транзакций не очищаются, у вас, к сожалению, есть бомба замедленного действия в ваших руках, которая может взорваться в любой момент (извините за столь резкое звучание, но на самом деле это довольно серьезно). Когда том, на котором находятся журналы транзакций, заполняется почти до предела, связанные базы данных почтовых ящиков отключаются до тех пор, пока не будет достаточно места для новых журналов транзакций. В зависимости от количества накопленных вами журналов транзакций будет определено, когда ваши базы данных почтовых ящиков будут отключены из-за нехватки места.
Вам придется отключить базу данных, чтобы сделать то, что я предлагаю, однако она должна отключиться без проблем, и когда я отключил свою базу данных, она была в Clean Shutdown состояние, что не может не радовать.
Размонтируйте базу данных, просто проверьте работоспособность и запустите eseutil /mh <edb file name> чтобы убедиться, что база данных находится в Clean Shutdown штат. Затем переместите все *.log файлы, кроме E00.log и E00tmp.log где-нибудь в безопасном месте (не удаляйте их, они вам понадобятся, если все пойдет по танго-униформе). После того, как все они переместятся, снова подключите базу данных и попробуйте как можно скорее создать полную резервную копию базы данных (это должна быть полная резервная копия, а не инкрементная). Этот процесс работал в моей виртуальной машине и, надеюсь, решит вашу проблему.
Предупреждение: НЕ удаляйте файлы журнала транзакций ___EVER___, если вы не абсолютно уверен ты знаешь что делаешь. Если вам нужно удалить журнал транзакций из уравнения, шаг это где-то еще, просто не удаляйте его.