V. 5.5/2000/2003

Oleg Krylov · Отправлено: **00:38, 24-02-2009** | #2

Первым делом проверьте диск. Скорее всего умер, поэтому тяните куда-то данные.
Второе - заставьте пользователей забэкапить почту в PST-файлы
Проверьте базу при помощи eseutil, НО СКОРЕЕ ВСЕГО МОЖНО СЛУЖИТЬ ЗАУПОКОЙНУЮ.
Создайте еще одну базу, переместите пользователей в нее. И накидайте данные из PST.

kdsnice · Отправлено: **13:05, 25-02-2009** | #3

Диск уже заменили. А вот пользователе заставлять уже поздно, база та уже упала и доступа к ней нету. Еseutil вообще этот пустой файл принимать не хочет.

Тут задача сводиться к тому что бы каким то образом вытащить почту из файлов транзакций. Из бекапа я восстановил базу, осталось на неё как то логи накатить, по тому что бекап то старенький...

MD@nshin · Отправлено: **18:57, 25-02-2009** | #4

Олег, привет! Мы с тобой как раз эту тему и обсуждали тогда...

У меня так и не получилось помочь.
http://msexchange.ru/forum/read.php?FID=5&TID=3668

kdsnice, а у вас пользователи режим кэширования отключили что ли? По умолчанию он включен и данные можно достать из OST.

kdsnice · Отправлено: **19:05, 25-02-2009** | #5

Пользователи работают в терминале, под ограниченным профилем, и когда настаиваешь аутлук, то опция "Режим кэширования" отключена, и даже недоступна....

MD@nshin · Отправлено: **20:20, 25-02-2009** | #6

Хм. Я тоже всегда работаю под ограниченным профилем. Терминал думаю тут не причем. Что бы лишить пользователей возможности включать и отключать режим кеширования, обычно для этого делают доменную политику, но прежде вам нужно скачать соответствующий adm файл т.к. по умолчанию такой политики нет.

Oleg Krylov · Отправлено: **01:59, 26-02-2009** | #7

Привет, Миш. А нет у этой проблемы решения... Бэкапы нужно делать регулярнее. Нет PST - нет мультиков. Восстанавливайте бэкап, но состояние почты получите на момент бэкапа. А лучше создать новую базу, а бэкап восстановить в Recovery Storage Group. И оттуда пытаться перетаскивать ящики. STM - в данной ситуации бесполезен. Он используется для non-MAPI клиентов, например IMAP. Если остановить Information Store, содержимое STM можно просматривать хоть блокнотом, и там искать какую-то критическую информацию. А вот куда у Вас делись логи за месяц, не понятно. Забился диск и включили циклическую перезапись? Бэкап - наше все. Мои соболезнования.

Oleg Krylov · Отправлено: **02:19, 26-02-2009** | #8

Здесь http://technet.microsoft.com/ru-ru/l...EXCHG.65).aspx читайте раздел Hard Recovery. Утащите содержимое каталога базы (бэкап, логи, stm-файл) в безопасное место. Восстанавливайте бэкап, проигрывайте логи, активно изучайте Eseutil. Чисто теоретически можно проиграть логи даже при их нехватке. Но это симулятор геморроя, честное слово...

MD@nshin · Отправлено: **09:35, 26-02-2009** | #9

Нет. При нехватке логов нельзя их проиграть. Пишет "Existing log file is not contiguous" и все тут!

kdsnice · Отправлено: **12:51, 26-02-2009** | #10

Полностью согласен с тем что нужно делать чаще бэкап! Циклическая перезапись логов у меня не включена, а часть логов нет по простой причине. Я просто не писал об этом, посчитал это не важным, так как ситуация от этого не меняется. На самом деле бэкап делается регулярно, ntbackup-ом, а когда делаешь таким образом бекап, то все логи скидываются в базу и удаляются. По этому у меня и отсутствует часть логов, проблема в том что более свежий бекап был запорчен из-за того что находился на том же диске что и сама база, только на другом разделе. По этому остался в живых только старый бекап, который лежал на сетевом хранилище. Вот так вот все запутанно

С Eseutil перепробовал все возможные варианты, ничего не получилось, как сказал MD@nshin, "Existing log file is not contiguous". Получается парадокс: файлы транзакции нужны в Exchange для повышения отказоустойчивости, но на самом деле отсутствие хотя бы одного файла транзакций сводит эту отказоустойчивость на нет ))) В Exchange 2008 вроде эту ситуация поправили, там есть параметр Eseutil /А который игнорирует недостающие логи. Но от этого не легче, так как у меня 2003, вот и лежит теперь почта мертвым грузом в лог файлах.

Спасибо за помощь!