Удаление логов транзакций в Microsoft Exchange Server 2007
Время от времени ИТ специалисты в форумах жалуются на то, что на диске с базами Exchange заканчивается место и оно забито странными файлами с расширением LOG. Как-то мне знакомый админ сказал, что место на диске Exchange сервера 2007 закончилось и он все логи удалил, я долго ждал когда он пожалуется на убитый сервер, но этого не произошло… ему просто повезло
Или например, как бекапить и что делать с логами Exchange 2007, установленного на Windows Server 2008? И так, как же работает механизм логов, как бекапить Exchange без ntbackup и специальных программ резервного копирования, а также безопасно ли удалять логи вручную?
Все знают, что данные в Microsoft Exchange Server 2007 хранятся в почтовых базах и логах. Папка с файлами данных Exchange выглядит примерно так:
Name Length
—- ——
E00.chk 8
E000000001B.log 1024
E00tmp.log 1024
E00res00002.jrs 1024
E00res00001.jrs 1024
E0000000019.log 1024
E00.log 1024
E000000001A.log 1024
E0000000018.log 1024
E0000000017.log 1024
tmp.edb 2064
Mailbox Database.edb 10256
CatalogData-1da9bbdf-30e6-4777-9f5c-… 0
Где Mailbox Database.edb — база сообщений, а файлы E00000*.log — файлы транзакций. Письмо перед тем, как попасть в базу сначала сохраняется в лог файл, а затем уже Information Store «проигрывает» его в базу. Информация об уже проигранных логах хранится в файле E00.CHK. Проигранные логи могут быть удалены. Обычно они удаляются с помощью программы резервного копирования Microsoft Exchange и для многих ИТ специалистов это является единственным способом по освобождению места на диске и удалению файлов логов.
Но это не так, существует несколько способов для удаления логов и освобождению места на диске:
- 1. Главный, он же правильный метод, это своевременное резервное копирование Microsoft Exchange Server с помощью специально предназначенных для этого программ. Они это делают с помощью специального API, простым файловым бекапом копировать базу нельзя, т.к. файлы базы, логов и вспомогательных файлов будут открыты и не скопируются. Исключением является размонтирование базы и ее копирование, как файла. Но это не рекомендуется.
- 2. Перемещение логов или баз на другой диск
- 3. Размонтирование баз и удаление вручную ВСЕХ логов. Для большей надежности лучше убедиться в корректном закрытии базы(eseutil /MH) и проверить последний сброшенный в базу лог (eseutil /MK)
- 4. Проверка последнего сброшенного в базу лога (eseutil /MK) и удаление всех ненужных. Последний сброшенный лог можно определить командой:
C:\eseutil /mk «C:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group\E00.chk» |find » Checkpoint:»
Checkpoint: (0×21,8,16)
0×21 означает, что файлы E0000000020.log и старше, т.е. E0000000019.log, можно спокойно удалить.
Что собственно и делает программа резервного копирования. Full backup делает бекап базы+ бекап логов, потом ненужные логи удаляет. Incremental бекап тупо копирует логи с момента Full backup и удаляет проигранные в базу.
Если лень удалять файлы вручную, то можно использовать скрипт на PowerShell.
$temp = (eseutil /mk «C:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group\E00.chk»)[13]
$Bottom_Log_File = $temp.remove($temp.IndexOf(«,»)).remove(0,$temp.IndexOf(«x»)+1)
Get-ChildItem «C:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group» | Where-Object { $_.Name.Length -eq 15 -AND $_.Name -like «E00*.log» -AND $_.Name.Substring(3+8-$Bottom_Log_File.length,$Bottom_Log_File.length) -lt $Bottom_Log_File } | foreach($_) {remove-item $_.fullname}
Для запуска скрипта по времени можно вставить конструкцию powershell.exe -noexit D:\Purge_Exchange_T_Logs_3rdSGroup_LCR.ps1 в Tasks Scheduler.
Скажем в малююююююсеньких компаниях вполне возможен следующий сценарий бекапа:
1. Размонтирование хранилища
2. Копирование файла базы сообщений
3. Удаление всех логов
4. Монтирование базы.
Если по ночам сервер не используется и базы можно размонтировать, то чем плохо? Бесплатно и быстро.
Еще существуют самописные утилиты для очистки от логов. Более подробно написано здесь.
На больших и средних предприятиях такими примитивными способами бекапа пользоваться не стоит. Малым предприятиям, установившим Exchange 2007 на Windows 2008 лучше подождать SP2 для Exchange 2007, когда Windows Backup будет делать резервное копирование Exchange 2007.
Этот пост написан в познавательных целях, прежде чем что-то удалять или запускать скрипт, убедитесь, что Вы понимаете, что делаете.
Документация по работе хранилища http://support.microsoft.com/kb/240145. Очень рекомендую, хорошая статья.
Еще немного есть тут. http://searchexchange.techtarget.com/tip/0,289483,sid43_gci1187056_mem1,00.html
Если есть вопросы и дополнения — всегда Welcome в комменты!
p.s. Кстати, если хотите, чтобы Ваше милое личико отображалось в комментариях возле вашего имени на МНОГИХ сайтах и блогах, то зарегистрируйтесь на сайте http://ru.gravatar.com/ Там все просто, e-mailу ставится соответствие с фотографией. Удобно.
Похожие посты:
1 Июль 2009, 14:14
Комментариев: 19





2 Июль 2, 2009 г. в 00:48
Павел, большое спасибо за статью.
2 Июль 2, 2009 г. в 09:02
Паша, а циркуляцию логов уже отменили
?
2 Июль 2, 2009 г. в 09:44
во-во! circular logging рулит, особо когда ящики с одного сервера на другой переносишь в массовом порядке.
2 Июль 2, 2009 г. в 10:17
Саня, че типа подловил?
Про циркуляцию логов я не стал писать специально, ибо все кто понимает о чем написано в этом посте прекрасно знают, что такое circular logging и поскольку это считается Best practice.
Стас кстати хорошую идею подал про перенос мейлбоксов. Я помню, что у меня давно количество перенесенных ящиков за ночь ограничивалось именно размером дисков для логов.
2 Июль 2, 2009 г. в 13:53
Странно… почему после удаления файлов транзакций Exchange должен упасть?
2 Июль 2, 2009 г. в 18:45
Речь о файлах транзакций, которые еще не проиграны в базу. Я полагаю, что база будет инконсистент и или размонтируется или при следующем монтировании не смонтируется. Точно не знаю, но это всегда можно проверить.
6 Июль 6, 2009 г. в 18:32
А еще я у Petri встречал статью про offline бэкап на постоянной основе.
6 Июль 6, 2009 г. в 22:11
В небольших системах можно, но если сервис нужно предоствлять 24 часа, то какой уж тут оффлайн бекап.
8 Июль 8, 2009 г. в 16:29
Помогите плиззз!!!
Есть кластер exchange 2007, БД бэкапится HP DataProtection мне надо понять как востанавливать БД после полного краха, после неработоспособности базы сразу на 2 серверах кластера. Просто бэкапами у нас занимается другой отдел, ни я ни они не понимаем как бэкапить правильно Exchange. Сам кластер стоит на Win2008 и бэкапить стандартными средствами ntbackup нельзя. Моя задача заключается в том, что бы востановить базу со всеми ящиками и письмами в ней после удаления работоющей БД из бэкапа, который делается на HP DataProtection.
Есть интересное наблюдение, я попросил, что бы мне бэкап скинули на сервер в директорию, в бэкапе было примерно 10 файлов логов и 1 файл restore.env, но перед бэкапом я видел, что у меня не 10 файлов логов а примерно 50-70, почему после разбэкапирования вышло только 10 я не понял.
P.S. Спасибо!!!
8 Июль 8, 2009 г. в 16:51
to Voron: Вам надо делать Full Backup базы
8 Июль 8, 2009 г. в 17:50
Voron:
Если посмотреть на Ваши файлы полученный после резервного копирования, то напрашивается вопрос в компетентности используемого продукта в возможности резервного копирования базы данных Exchange. Как минимум, если делать бекап файлов, то получается edb файл.
Поэтому лучше пользоваться штатными средствами, благо в Exchange 2007 Sp2 был добавлен плагин для Windows Server Backup, посредством которого можно производить резервную копию базы Exchange 2007 штатными средствами.
9 Июль 9, 2009 г. в 10:21
Спасибо за ответы!
Я так и предполагал, что должен создаваться при бэкапе файл edb. На счет плагина не был в курсе, буду пробовать.
Всем спасибо!
10 Июль 10, 2009 г. в 07:23
‘Exchange 2007 Sp2 был добавлен» не был добавлен, а только будет добавлен в третьем квартале, поэтому на даный момент решения резервного копирования E2007 под W2008 для небольших и бедных предприятий просто нет.
Понятие offline backup существовало давно и является возможным, но не рекомендуемым методом бекапа.
http://support.microsoft.com/kb/296788
10 Июль 10, 2009 г. в 07:28
[...] Переход с Exchange 2003 на Exchange 2007 Рубрика: Exchange, PowerShell — Метки:Exchange — zorion @ 14:23 Эпопея с резервными копиями разрешилась удалением логов. Спасибо Паше Нагаеву за скрипт. А вот тут он написал статью подробнее. Я очень рекомендую к прочтению Ссылка [...]
14 Июль 14, 2009 г. в 08:05
Проблему востановления из бэкапа спомощью НР DPM решили. При тестировании удалили БД с активной ноды, после востановления пришлось ручками востановить репликацию кластера CCR, после чего полная работоспособность кластера востановлена.
15 Июль 15, 2009 г. в 09:57
Andrey,
HP DataProtector вполне компетентен в вопросах бэкапов почтовых систем, особенно в части бэкапирования развитой инфраструктуры. Это система бэкапирования «энтерпрайз» уровня. Поэтому c MS Бэкап данную систему сравнивать некорректно. Используем HP DP уже давно – нариканий на данную систему нет никаких. Все восстанавливается успешно – в том числе и БД Exchange…..
15 Июль 15, 2009 г. в 10:50
Guard:
Не хотел никого обижать, но если получили такие файлы то напрашивалось 2 вопроса: некомпетентность программы (маловероятно) и некомпетентная настройка.
Внутри, я думал про второе
9 Август 9, 2009 г. в 14:28
http://theessentialexchange.com/blogs/michael/archive/2009/01/26/exchange-2007-and-windows-2008-online-exchange-backup-part-6-of-7.aspx
3 Декабрь 3, 2009 г. в 12:52
Паш, спасибо.