We rise up for the things we believe in over and over again
Да-да, на дворе уже 2013 год за половину перевалил, но тут по-прежнему используется Exchange 2003. Впрочем, не об этом речь.
В общем и целом, начало этому посту было положено уже давно. История с лог-файлами, которая в моем личном хит-параде стоит на первом месте. Вот она: Клац!
А теперь ее продолжение, и хочется верить, что окончание.
Да, была авария на почтовом сервере. Да, есть бекап. Да, базу из него поднять можно и нужно.
Поскольку на том диске, где база и ее логи лежали изначально, место уже практически исчерпано (Zabbix об этом орет уже вторую неделю), решил восстановить базу на другой раздел, побольше. Памятуя о том, что у нас на разных разделах разный размер сектора (см. ту самую ссылку), размещаю файлы баз данных и логов Recovery Storage Group на новом разделе, а так называемый патч-файл (restore.env) и временные логи транзакций - на старом разделе. Для них места хватит, и на работу самого сервера еще останется. Все распланировано, запускается процесс восстановления. Файлы полного бекапа послушно кладутся на свои места, временные логи так же послушно кладутся на старый раздел. Поверх этого всего накатываются логи из Differential-бекапа, чтобы минимизировать потери почты. Дается команда Commit logs... И понимаем, что эта самая последняя команда не выполняется. Дает ошибку следующего вида:
Operation terminated with error -546 (JET_errLogSectorSizeMismatch, the log file sector size does not match the current volume's sector size)
Но как же так? ОК, сделаем то же самое, только руками, а не полагаясь на работу Backup Exec. Открываем командную строку, переходим в каталог с временными логами, даем слеующее:
eseutil /cc
Принудительное считывание и применение логов, обозначенных в файле restore.env, лежащем в текущем каталоге. Команда приводит к той же самой ошибке. Что за чертовщина? Следующая проверка:
eseutil /ml %LOG_FILE_NAME%
fsutil fsinfo ntfsinfo %DRIVE_NAME%
Размеры секторов совпадают. До байта. В чем проблема?
Начинаю вспоминать, как вообще нарвался на эту ошибку впервые. Ошибка появлялась при перенесении имеющихся логов группы хранения. В то же время, если их создать заново - все базы группы хранения спокойно примонтируются, а новые логи будут привязаны к разделу с новым размером сектора. Так, создание логов. Начинаем прикидывать, где у нас создаются логи при восстановлении баз. А создаются они в папке логов Recovery Storage Group. Чем черт не шутит, а почему бы не расположить их на том же разделе, что и временные логи из бекапа, где размер сектора тот, что надо?
Вы не поверите, это сработало. Даже при создании логов RSG учитывается размер сектора диска, где они будут лежать. Еще одно откровение, ничего не скажешь. Какое же счатье было читать в системном журнале сообщения следующего вида:
Information Store (992) Restore0008: The database engine has begun replaying logfile N:\Temp\SG1\E0085AEA.log.