Размер почтовых баз Exchange 2010? Кто с каким живет?
Добрый день!
Хотелось бы уточнить кто с каким размером БД работает? и какие неудобства вызывает.
А так же используется ли варианты с сетевым онлайн архивом?
У меня 3 БД Exchange 2010 размером по 600Гб, ввести жесткое ограничение по размеру письма не разрешает руководство. А так же удаление старых писем запрещено, только на усмотрение клиентов. Соответственно сейчас буду вводить Сетевые онлайн архивы причиной послужило следующее - при крахе БД в 600Гб её восстановить средствами eseutil занимает очень продолжительное время.
Кто с чем еще сталкивался и какие объемы хранит?
Какие продукции по архивации? Если есть стандартные средства "Личные архивы"?
Мне просто интересно у кого как реализовано и какие подводные камни возможны
Евгений Денисов: Личные архивы вам, судя по всему, не подойдут, т.к. у вас нет возможности административно заставлять пользователей пользоваться ими. Стандартных средств архивации, насколько мне известно, нет.
Общая архитектура системы архивации выглядит так:
Сервер управления, система хранения архивов, фронт-энд (в вашем случае Exchange).
На сервере управления создаются политики изъятия объектов с фронта (в вашем случае - письма) по определенным критериям - последнее обращение к объекту больше n дней, размер больше m Кб и т.п.
После отработки политики объекты из фронта перемещаются в систему хранения (зачастую с дедупликацией данных) и заменяются на фронте т.н. "ярлыком". При обращении пользователя к архивному объекту данные будут перемещены из архива во фронт. Подобная технология позволяет резко снизить размер фронта и уменьшить размер резервной копии.
Работал с подобными системами - Symantec Enterprise Vault и Commvault.
Везде есть свои нюансы. Главный минус подобных решений - цена. Но после этапа внедрения/тестирования сурово снижают размеры фронта и, зачастую, для пользователей не заметны.
tyurink: Ваш вариант не рассматривали, по одной простой причине- цена!!! Личные архивы по крайней мере вынесены за пределы фронта( БД расположена на более медленном хранилище) и при падении не потянет за собой легкий фронт (который опять же восстановить несколько быстрее будет из-за уменьшенного размера! Вот мне интересно в такой конфигурации много подводных камней?
Простой
