Из почты службы спасения данных...

Санкт-Петербург (812) 294-8686
Москва (495) 700-0509

Из почты службы спасения данных...

Всем привет!

Вот решил поделиться историей о том, как когда-то (дело было в 2004 году) в нашей конторе вирус W32.Mydoom.A@mm (он же W32.Novarg.A@mm) при помощи Symantec AntiVirus Corporate Edition положил набок Microsoft Exchange Server 5.5.

Все началось с того, что в одно ужасное утро наш Exchange был обнаружен лежащим на боку... Остановился сервис Microsoft Exchange Information Store, а также - зависящие от него сервисы Microsoft Exchange Internet Mail Service и Microsoft Exchange Event Service. Попытки запустить сервисы вручную, а также "освежающая" перезагрузка ни к какому положительному результату не привели...

Следует, наверное, рассказать о нашем сервере. Это двухпроцессорная интеловская платформа высотой 2U. Памяти 1 ГБ. Два диска SCSI 36 ГБ в аппаратном зеркале на Mylex 170. Операционка - Microsoft Windows NT 4.0 с SP6 и прочими обновлениями. Кроме почты (Microsoft Exchange Server 5.5), он вообщем-то ничего и не делал. Антивируса под Exchange мы не нашли, поэтому поставили на него обычный Symantec AntiVirus Corporate Edition Client, который получает обновления с другого сервера...

Как выяснилось в то злополучное утро, именно Norton AntiVirus дров и наломал. В Event Viewer - Application Log мы нашли такую запись:

Virus Found! Virus name: W32.Mydoom.A@mm in File: D:exchsrvrMDBDATAedb.log by: Realtime Protection scan. Action: Clean failed : Quarantine succeeded : Access denied

А вслед за ней - такие:

The error 0x80040115 was encountered while trying to communicate with the message store. An attempt to refresh the connection will be made. If not successful, the service will be shut down.

The error 0x8004011d occurred while trying to refresh network connections to the Information Store. The Internet Mail Service is being shut down.

То есть, AntiVirus обнаружил, что в хранилище сообщений попал вирус, и, недолго думая, попытался "полечить" его. В результате сервис сообщений "встал", а вслед за ним - и остальные сервисы Exchange.

Как я уже сказал, попытки запустить сервисы вручную результата не дали...

Теперь о том, как мы делаем резервное копирование нашего сервера.

Стример Quantum DLT4000 и Veritas Backup Exec v.8.5 стоят на другом компьютере. С почтового сервера мы просто сохраняем все файлы на ленту. По пятницам делаем полное сохранение, а в другие дни - дифференциальное.

После того, как выяснилось, что Exchange по-хорошему запускаться не желает, решили восстановить почтовый сервер с резервных лент...

А дальше - дальше выяснилось, что сервер мы сохраняли вообщем-то неправильно...

Итак, Exchange по-хорошему запускаться не хотел, поэтому мы решили восстановить сервер с резервных лент... Сделали восстановление с последней пятничной ленты, потом - со вчерашней дифференциальной. Восстановление делали поверх той же самой не совсем работающей системы. Результат - никакой...

О блин, там же галочку надо было снять - Skip if existing file is more recent! Еще раз все по новой! Результат - все то же самое...

Стали разбираться. Короче, выяснилось, что те самые файлы, которые потоптал антивирус - хранилище сообщений и его логи - у нас и не копируются вовсе!!! Каждый день BackupExec писал в лог буквально следующее: The item exchsrvrmdbdataedb.log in use - skipped!

То есть, резервной копии этого файла у нас и нету совсем! (Почему ин-юзе, понятно - лог открыт Exchange'м постоянно. Отсюда же ясно, почему скиппед). Стыдоба, одним словом...

Ну так вот, всерьез замаячила перспектива переставлять заново сервак.

Смыть Exchange и поставить заново вообщем-то дело недолгое, даже ящики создавать не пришлось бы, так как экспорт каталога мы сделали. Проблема в том, что после импорта эти ящики все равно надо привязывать к пользовательским аккаунтам (а юзеров у нас десятка три). Да и дополнительные мейлы вручную вбивать, потому что в экспорт попадают только по одному (основному) е-мейлу от каждого ящика (как говорится, спасибо MS за наше счастливое детство!).

Вы поймите меня правильно, я же не починяю базы каждый день, не восстанавливаю утраченные данные постоянно! Когда все исправно, когда все работает, завел юзера раз в месяц, подтолкнул спулер, посмотрел статистику за интернет... В основном - почистить мышку, вытащить скрепку из ксерокса, отформатировать дикетку для бухгалтера и прочая хлопотная мелочевка... Суета, одним словом.

В последний момент нашего программиста осенило: раз Exchange - это база, то и средства лечения этой базы должны существовать! Полезли в каталог exchsrvrbin. Там - несколько EXE-шников, среди которых вроде бы то, что нужно - EDBUTIL.EXE.

C:exchsrvrbin>EDBUTIL.EXE
EDBUTIL has been replaced with the tool ESEUTIL.EXE.
ESEUTIL.EXE can be found in the %windir%system32 folder (C:WINNTsystem32).

Ладно, запустили другую программку:

C:exchsrvrbin>EseUTIL.EXE /?
Microsoft(R) Windows NT(TM) Server Database Utilities Version 5.5
Copyright (C) Microsoft Corporation 1991-1999. All Rights Reserved.

DESCRIPTION: Maintenance utilities for Microsoft(R) Exchange Server databases.

MODES OF OPERATION:
Defragmentation: ESEUTIL.EXE /d <database name> [options]
Recovery: ESEUTIL.EXE /r [options]
Integrity: ESEUTIL.EXE /g <database name> [options]
Upgrade: ESEUTIL.EXE /u <database name> /d<previous .DLL> [options]
File Dump: ESEUTIL.EXE /m[mode-modifier] <filename>
Repair: ESEUTIL.EXE /p <database name> [options]

Note log file path must be specified explicitly unless using /IS or /DS options.

В общем, тут-то все и закончилось. Пошли в каталог с хранилищем, запустили эту прогу с ключом /p и именем хранилища priv.edb в качестве параметра. Потом еще раз запустили - с параметром pub.edb. Удалили логи, как было сказано. Все, сервис запустился! Сервак заработал как ни в чем ни бывало! Ура!

P.S. Позже на эту тему нашли еще вот такой ресурс:
http://www.osp.ru/win2000/exchange/44exch10_print.htm

Мы, конечно, изменили наше отношение и к резервному копированию, и к методам защиты от вирусов. Сформулировали план аварийных мероприятий, тестируем и анализируем результаты резервного копирования всех наших серверов. После этой истории нашлись и агент для Exchange, и (что еще важнее) - AntiVirus для него же, родимого. Главное, мы поняли - данные сами (почему-то) защищаться не желают. Защищать их (и свое спокойствие и благополучие) приходится нам самим.

Комментарий редактора:
Вот чтоб таких проблем в будущем не огребать, читайте господа сисадмины внимательно документацию к тем продуктам, которые внедряете (в данном случае Symantec/Norton Corp Edition)! Там ведь черным по белому написано что (и даже как) необходимо исключить из сканирования при совместном использовании антивируса и почтового сервера.

© При перепечатке ссылка на источник (www.timcompany.ru) обязательна!





На каком уровне RAID, по Вашему, следует разместить основную базу данных предприятия?
RAID 0:
4%
RAID 1:
15%
RAID 10/1E:
27%
RAID 5:
34%
RAID 50/5EE:
11%
RAID 6:
8%
Другой/Никакой:
1%
© 2011 Группа компаний ТИМ, Почта: info@timcompany.ru, Ссылки