Дефрагментация базы Exchange 2016

Sveta_NA

Почетный гость
Добрый день! на VM где установлен почтовый сервер заканчивается место на диске выделенном под хранение DB (уже менее 10%). Я конечно могла бы просто увеличить размер диска - datastore на VMware позволяет, но это не решение а оттягивание проблемы. Поэтому хочу уменьшить размер базы DB. Так как раньше никогда не делала, думаю будет не лишним посоветоваться с опытными людьми как лучше и безболезненнее это сделать на Exchange 2016. Поправьте меня если я ошибаюсь. Итак:

1. Чтобы затея вообще имела смысл, надо сначала переместить в архив или удалить все ненужные ящики. На данный момент команда
Get-MailboxDatabase -Status | ft name,databasesize, availablenewmailboxspace -auto
выдает что освободится всего 111,5 Мб, что естественно капля в море от 598.5 ГБ.

Name DatabaseSize AvailableNewMailboxSpace
---- ------------ ------------------------
DB-01 598.5 GB (642,634,481,664 bytes) 111.5 MB (116,916,224 bytes)

Отсюда вопрос - как элегантнее сделать архивацию старой почты для пользователей чтобы архив и место не занимал на Exchange и всегда доступен был, если кому-то потребуется найти письмо пятилетней давности? Или лучше всего это дедовский способ - архивация через аутлук на локальный диск пользователя? ))

2. Так как у меня нет DAG, то для дефрагментации подойдет и оффлайн через ESEUtil и онлайн с созданием новой базы и переносом всех ящиков.
С одной стороны офлайн-метод вроде выглядит проще и ничего не надо туда-сюда перемещать и перенастраивать, но меня терзают смутные сомнения сколько займет время дефрагментация почти 600 Гб ? В рабочее время это сделать нельзя, но вдруг и выходных не хватит? Да и в выходной день могут в это время приходить письма а почта будет недоступна. Если случится какой-то сбой - то база вообще может рухнуть и придется восстанавливать VM из резервной копии что тоже занимает время...

3. Если делать онлайн-способом, то опять же - сколько это обычно занимает времени и какие есть нюансы о которых я могу не знать при перемещении всех ящиков в новую DB ? Чтобы потом с удивлением не обнаружить исчезнувшую почту или сбитые настройки групп и ящиков.
 
Последнее редактирование модератором:
Вот насчет дефрагментации БД. Я почему то никогда не пользовался на практике этим - долго и муторно.
Я бы вам посоветовал создать новую БД и перетащить туда нужные ящики. Старую базу удалить. Можно делать на горячую. А если через eseutil то там по-моему размонтировать надо ну и это достаточно долгий процесс и тд и тп..
 
Я бы сначала из имеющейся базы поудалял или повыгружал ненужное, а затем создал новую, пустую БД. Туда бы переместил те ящики которые нужны. Так пустот не будет в базе
 
Отсюда вопрос - как элегантнее сделать архивацию старой почты для пользователей чтобы архив и место не занимал на Exchange и всегда доступен был, если кому-то потребуется найти письмо пятилетней давности? Или лучше всего это дедовский способ - архивация через аутлук на локальный диск пользователя? ))
Можно попробовать прицепить к виртуальной машине еще один HDD и переместить на него базу данных с почтовыми архивами
 
2. Так как у меня нет DAG, то для дефрагментации подойдет и оффлайн через ESEUtil и онлайн с созданием новой базы и переносом всех ящиков.
С одной стороны офлайн-метод вроде выглядит проще и ничего не надо туда-сюда перемещать и перенастраивать, но меня терзают смутные сомнения сколько займет время дефрагментация почти 600 Гб ? В рабочее время это сделать нельзя, но вдруг и выходных не хватит? Да и в выходной день могут в это время приходить письма а почта будет недоступна. Если случится какой-то сбой - то база вообще может рухнуть и придется восстанавливать VM из резервной копии что тоже занимает время...
Долго это все и игра не стоит свеч. Создайте пустую БД, и как вам выше посоветовали.
 
Добавлю еще 5 копеек. Для дефрагментации вам потребуется свободное место на диске в размере 110% от размера базы. Т.ч. создание новой базы может оказаться даже единственным выходом.

И, если все ровно будете переносить ящики, лучше раскидать их по разным базам. Майкрософт рекомендует, что размер базы не должен превышать 200 ГБ. Хотя у меня на практике также работала база на 500 ГБ и все было ОК, кроме невозможности выполнить обслуживание, из-за недостаточного количества свободного места. Главное помнить что у Ексченджа есть ограничение на количество баз (кажется пять в стандартной версии) и один слот нужно зарезервировать на подобную эквилибристику ящиками.
 
На сервере тот что в продакшен, дефрагментировать базу моветон, можно получить ноль байт после дефрагментации. Не претендуя на оригинальность, новая база и перемещение почтовых ящиков, до кучи кольцевое перезаписывание трансзакционных логов.
За 500 гигов не помню, но если мне не изменяет память, в редакции стандарт база не должна превышать 1тб.
 
Назад
Верх