Мы восстанавливаем только базу данных общих папок с помощью Backup Exec 9.1.
Основные файлы EDB и STM восстановлены нормально. Однако счетчик байтов остановился, и теперь в папке базы данных есть тонны файлов .IFS. 40-60, если быть точным.
Кажется, что они меняются каждые несколько минут с увеличивающимися именами, такими как:
14D-871CFBD0-1541491D.IFS
Я беспокоюсь о том, чтобы что-то предпринять, так как на восстановление общих папок объемом 70 ГБ ушло более 7 часов, плюс еще 4 часа на это. Отменить восстановление, попробовать смонтировать базу данных вручную, ничего не делать?
Примечание. Хотя база данных была смонтирована правильно до того, как произошел сбой сервера (из-за сбоя диска), я обеспокоен тем, что, возможно, размер базы данных превысил предел в 75 ГБ, что могло быть причиной этого?
Есть предложения по дальнейшим действиям?
РЕДАКТИРОВАТЬ - Восстановление длится уже более 23 часов. Также обратите внимание, что во временной папке есть 5 файлов журнала транзакций, с restore.env в 1 КБ.
Хотя мне никогда не приходилось восстанавливать всю базу данных PF, и уж точно не с такой старой версией BE, как 9.1, я бы посоветовал позволить этому заданию выполняться. В случае сбоя произойдет сбой, и вы сможете использовать коды ошибок в истории заданий для устранения неполадок. Восстановление Exchange (особенно одно из 75 ГБ) обычно занимает немного больше времени, чем восстановление файлов, поскольку «под капотом» происходит гораздо больше.
Уф. Еще один потерянный день в разговоре со службой поддержки Microsoft Exchange.
Нам пришлось отключить все службы BackupExec, чтобы снять блокировки с файлов, а затем выполнить жесткое восстановление восстановленных файлов с помощью eseutil.
Больно, но все снова работает.
Есть ли в 9.1 SGMon? инструмент ведения журнала .. он будет в каталоге программы, вы можете увидеть, как он работает, если статус перестает обновляться.
Он покажет вам все «под капотом», которое вы можете унести!