Какое плановое обслуживание, задачи или задания следует выполнять на сервере Exchange Server и как часто?
Некоторые люди могут сказать, что вам следует выполнять автономную дефрагментацию IS по определенному графику. Я видел, как машины E2K3 идут лет без автономной дефрагментации, поэтому для продолжения работы это не требуется. Точно так же я слышал, как люди ругаются, выполняя дефрагментацию файловой системы тома, содержащего хранилища, с выключением ядра базы данных (при условии, что файловая система находится на DASD, а не на томе SAN). Я также видел, как серверы E2K3 работали годами (с приемлемой производительностью), но никогда этого не делали.
Основное необходимое повторяющееся задание - это регулярное резервное копирование в онлайн-хранилище. По умолчанию E2K3 запускает ядро базы данных в режиме некциклического ведения журнала, поэтому журналы транзакций будут накапливаться до тех пор, пока не будет запущено полное или инкрементное оперативное резервное копирование. Таким образом, вы должны делать регулярные резервные копии в Интернете.
Все остальное является либо автоматическим (обслуживание IS), либо может быть запланировано для запуска во время производства (перестройка списка адресов, политики диспетчера почтовых ящиков).
Однако мне бы хотелось услышать мнения других по этому поводу.
Резервные копии и исправления являются ключевыми. Проверка целостности и дефрагментация - это, IMHO, лучшая практика, особенно если ваша база данных Exchange превышает 50 ГБ.
Проверки целостности помогают избежать коррупции. Defrag освобождает (возможно, драгоценное) дисковое пространство - нетривиально, особенно если вы работаете в компании с высокой текучестью кадров.
Проблемы с Integ и Defrag - это время, необходимое для завершения, а для дефрагментации - дисковое пространство, необходимое для запуска. На самом деле для дефрагментации вам нужно пустое дисковое пространство, равное 1,2-кратному текущему размеру базы данных Exchange.
У меня была комбинация интеграции и дефрагментации, которая занимала от 6 часов (20 ГБ) до 22 часов (90 ГБ) на дисках U320 со скоростью вращения 15 об / мин. Просто больно, а в некоторых случаях невозможно.
Еще один вариант «дефрагментации», хотя и несложный, - это создать дополнительное хранилище почтовых ящиков и перенести туда пользователей. Затем удалите пустое старое хранилище информации.
Я был бы склонен согласиться с Эваном в этом. Мы выживаем без регулярного обслуживания и дефрагментации.
Единственное, что я хотел бы сказать, это то, что если вы удалите учетные записи, вы не освободите место в их почтовом ящике, если не выполните автономную дефрагментацию. По крайней мере, так я понимаю, и я хотел бы, чтобы в этом было доказано, что я ошибаюсь.
Я думаю, что во многих организациях техническое обслуживание материалов exch 2003, как правило, оставляют до тех пор, пока они не понадобятся, то есть для исправления поврежденных БД сообщений и т. Д.
Фактически, программное обеспечение резервного копирования устанавливает бит архива, чтобы показать, что было заархивировано или скопировано. Вы можете открывать файл с установленным битом A снова и снова, и это ничего не изменит. Однако, если вы измените любой файл и сохраните его, операционная система сбросит бит A. Если вы делаете полную резервную копию, она копирует или создает резервную копию всего, независимо от состояния A bit.
Но волшебство бита архива заключается в том, что когда вы делаете инкрементное или дифференциальное резервное копирование, оно будет создавать резервные копии только тех файлов, у которых очищен бит A (то есть его нужно заархивировать). После инкрементного резервного копирования бит A будет снова установлен программой резервного копирования. Это просто эффективный способ для программного обеспечения резервного копирования сообщить ОС и пользователю, какой файл был скопирован, а также эффективный способ для ОС и пользователя сообщить программе резервного копирования, что файл был изменен. Разница между инкрементным и дифференциальным резервным копированием заключается в том, смотрят ли они извне на момент последней резервной копии (инкрементной) или внутренне на то, когда произошло последнее полное резервное копирование (разностное) для нового набора архивов.
Предположим, у вас есть резервная копия 1000 файлов в Sun, и вы ежедневно изменяете другой набор из 100 файлов, и вам нужно перестроить систему в пятницу утром. При инкрементном режиме вам нужно будет восстановить 1 полную резервную копию ленты (и) и 4 инкрементных ленты (100 Пн, 100 Вт, 100 ср, 100 чт), чтобы снова получить полную систему. С дифференциалом вам нужно будет восстановить 1 полную ленту и дифференциал Thu (400 файлов). Дифференциальный - это просто (полный плюс дифференциальный = ВЫПОЛНЕНО), но требует большего хранилища резервных копий (100 + 200 + 300 + 400 + 500, в то время как инкрементальный - быстрый и дешевый, но требует большей сложности в процессе восстановления (и риска - что произойдет, если Пленка ср пропала?).
Движущими силами обычно является количество имеющихся у вас лент, объем данных, которые у вас есть и которые необходимо резервировать ежедневно, и объем имеющегося у вас окна резервного копирования. Большинство людей стараются использовать полную и дифференциальную версию, если они могут позволить себе хранилище резервных копий (ленту или диск), потому что это проще всего. Некоторые люди вынуждены использовать ежедневные инкрементальные ленты, но не имеют большого количества дублирований на инкрементных лентах, как на дифференциальных.