После марафона с еще одним восстановлением почтовых ящиков после вторичной аварии на сервере (многовато их что-то) наконец-то начал разгребать весь бардак по резервированию и архивированию информации с Exchange. И нашел в этом одну загвоздку.
Бекап всей информации у нас длился почти 1.5 суток, это очень много. И завершился он в очередной раз неудачей, что для всех, кроме меня, было уже привычным. Стал разбираться, в чем дело. А дело в том, что в процессе резервирования информации почтовые базы данных отключились, то есть стали недоступными. Ни для админов, ни для пользователей, ни для программы архивации. Попытки выяснить причину полного отключения всех баз вывели меня на вот эту статью в базе знаний MS - Клац!
Суть в следующем - при начале архивации базы последняя блокируется для любых изменений на все время архивирования. Все действия, которые должны быть с базой выполнены, сохраняются в файлах логов, которые получают статус Uncommited - непримененные. В системе есть жестко закодированное ограничение на количество таких логов - 1024 штуки (как всегда - по степени двойки). Однако, если этот лимит достигнут, сохранность баз будет под вопросом. Поэтому, если количество непримененных логов достигает 1008 - Exchange самостоятельно принимает попытку сохранения баз данных от повреждения и выполняет т.н. мягкое отключение, базы переводятся в состояние Clean Shutdown, в котором могут быть снова подключены в любой момент. В противоположность этому есть термин "грязное отключение" (Dirty Shutdown), в состоянии которого подключение базы сопряжено с дополнительными действиями, такими, как приведение ее в согласованное состояние и опять же, приведение ее к состоянию Clean Shutdown.
Что же происходит у нас. После того, как на вторые сутки количество непримененных логов превысило критическую величину, базы отключились. Программа архивации, которая до этого момента исправно сливала информацию в бекап, натыкается на недоступность баз, офигевает от такого поворота дел, и отказывается работать дальше, рапортуя об ошибочном завершении задания. В итоге бекапа фактически нет, а та часть, что уже слилась - непригодна для использования в случае краха.
Единственным методом решения данной проблемы является уменьшение времени, необходимое для выполнения всей процедуры резервирования. А вот как этого добиваться, уже вопрос. Лично я пока решил делать резервные копии всех баз, но по-отдельности - одна база за день, это больше, чем трехкратное снижение объема информации. В понедельник - тестовый запуск. Если отработает - распространяю расписание на всю неделю, после чего останется только распланировать сброс архивных копий на ленту и забыть об этой проблеме.