MaximumExchange.ru

Раз вопрос восстановления данных почтовых серверов в последнее время стоит весьма остро – поделюсь некоторыми советами профессионалов восстановления, которые мы частенько применяем в реальной жизни.

(Будем считать это первой статьей в разделе восстановления данных)

Наверное мало для кого окажется секретом то, что компания Ontrack, выпускающая такие знаменитые инструменты как EasyRecovery, Data Advisor и конечно же PowerControls для баз данных Exchange, занимается не только написанием софта, но и сервисными услугами по восстановлению данных. А значит специалисты наработали некоторый опыт в этом деле, и к их советам можно прислушаться. Tips & Tricks простые, как шесть копеек, однако не все их помнят, особенно в критических ситуациях сбоев данных. Итак:

Аварийные сбои данных были, есть и будут. Понимание этого факта – первый шаг в подготовке серьезного, «боевого» Плана Восстановления – Disaster Recovery Plan (DRP). В аварийных ситуациях, время всегда играет против IT-специалистов, так что все мельчайшие детали составляют залог успешного решения проблемы. Дьявол кроется в мелочах.

Ниже представлены некоторые соображения инженеров Ontrack Data Recovery по этому поводу (мне доводилось и общаться с ними лично),  густо сдобренные моими комментариями и дополнительными фичами (за восемь-то лет внедрения и восстановления Exchange), о том что нужно, и чего не нужно делать в ситуациях аварийных сбоев данных:

• При аварийных восстановлениях, ни в коем случае нельзя восстанавливать данные на сервер, где произошел аварийный сбой, – всегда восстанавливайте на отдельный сервер. Неверными шагами в процессе восстановления очень легко усугубить проблему, вместо того, чтобы ее решить, и при этом потерять оригинал, с которым еще хоть чтото можно было делать.
• В сбоях Microsoft Exchange или SQL, никогда не пытайтесь чинить само оригинальное хранилище (Store) или файлы базы данных в каком-либо виде – Всегда работайте с Копией данных.
• В ситуации случайного удаления данных лучше экстренно выключить машину, вместо полноценного завершения работы Windows. Это может предотвратить риск перезаписи данных из кэша.
• Регулярно используйте дефрагметаторы. Но, только от партнеров Microsoft, чьи продукты «Certified for Exchange / Windows / etc». Избегайте использовать какой попало софт на боевых серверах, не рискуйте данными, и собственным статусом.
• При падении диска в RAID-массиве, никогда не используйте этот же самый, «починенный диск». Всегда заменяйте сбоивший диск новым. Никто не знает на 100%, восстановлен ли тот или иной диск, и как долго он после этого еще будет работать. Всегда убеждайтесь что диск новый, чистый, и абсолютно пустой.
• Если диск в массиве производит неестественный, необычный шум – немедленно отключайте его, и без отлагательств разбирайтесь что к чему. Не ждите пока массив вывесит вам «Finit a la comedia – Все плохо». Разумеется, при этом у вас должны быть актуальные арихивы данных, Логи транзакций и базы данных, разнесенные на разные диски/массивы/LUN, а такие вещи как LCR в Exchange Server 2007 это вообще золото в подобных неприятностях.
• Всегда имейте актуальнейшую архивную копию ВСЕХ уникальных данных, без которых вы не сможете обойтись, перед любыми программными или аппапатными изменениями.
• Пометтье все диски в RAID массиве, обозначениями типа и идентификатора массива, позиции диска. Думаю, вы без труда найдете любого рода бумажные наклейки, на которых можно писать. Приторочьте их к незадействованным бортам винчестера. Помнится, я когда-то даже использовал наклейки для аудиокассет. «Mail-SRV1, RAID 0+1, Row1, Pos2″ и/или «scsi(1)disk(0)rdisk(1)partition(1)»
• Не используйте инструменты восстановления Дисков, на самих оригинальных дисках с поврежденными базами. Какой-нибудь Norton Disk Doctor - вещь конечно может быть полезная, но не для баз данных Exchange.
• Не используйте дисковые дефрагментаторы, на дисках, подозреваемых в сбое. Потенциально восстановимые данные можно получить в виде мусора «lost chains».
• При сбоях питания, на RAID массивах, если у вас есть подозрения на целостность файловой системы, если диски не подключаются, или данные недоступны – не спешите сразу запускать инструменты восстановления массива. Постарайтесь диагностировать проблему более тщательно, убедитесь что вы проверили все возможные зависимости баз данных, сервисы, подключения итп.
• Горячо любимый всеми неискушенными новичками инструмент Eseutil /P (в народе, среди знающих людей, называемый /Паяльник) Совсем не то, что нужно запускать, как только база не смонтировалась или вы не находите какие-либо данные. Это – последнее что можно сделать с базой, перед тем как ее окончательно выбросить в мусорку. 1. Восстановление из бэкапа. 2. Починка относительно безопасными инструментами (e.i. Isinteg /fix, eseutil /d, /r, etc). И уж если ничего не помогает, Eseutil /P – последняя надежда. Которая далеко не всегда оправдывается. Потому что при этом вырезаются все невалидные блоки данных в базе. Долго ли проживет пациент, которому хирург вырежет пол-организма? Сможет ли он вообще жить дальше?
• Всегда, после починки базы с помощью eseutil /p – переносите данные в новую базу. Никогда не оставляйте пофиксенную таким образом базу, работать дальше. Никто из знающих людей не поручится за жизнеспособность этой базы в дальнейшем. Никто не даст и евро, что она не сдохнет в следующий раз, в совершенно неожиданный момент, и ее вообще можно будет как-нибудь восстанавливать еще раз.

Вобщем, удачных вам восстановлений! И чтоб вы всегда знали что делать с рухнувшей базой.

MaxMVP Exchange 2003, Exchange 2007