(c) Peter Gubarevich, 2010
Microsoft Security Trusted Advisor
Microsoft Certified Trainer
Microsoft Certified IT Professional


1. Что за восстановление, о чём вообще речь?
«Совсем неважно, как ты ударишь, а важно, какой держишь удар.» Rocky Balboa.


    Отказоустойчивая система — вовсе не та, в которой создаются резервные копии. А та, что сумела восстановиться после сбоя. Никакое резервное копирование не имеет значения, если вы не можете восстановить данные из копии. Большинство системных администраторов никогда не пытались восстановить свои сервера из резервных копий, и это — просто факт, как правило, не зависящий ни от размера организации, ни от объёма штата IT-персонала. Эта задача зачастую откладывается «на потом», перекладывается на других (то есть, ведётся игра в «футбол»), выполняется частично  («давай попробуем восстановить базу, если заработает — всё о'кей»).

    Но критический сбой никогда не предупреждает вас о своём появлении заранее. Он не позвонит со словами «приготовься, это случится через неделю» и даже не вышлёт сообщение на электронную почту. С какими же проблемами в момент отказа сервера (да и не только сервера!) приходится столкнуться администраторам, не выполнявшим восстановление ранее?



    - Резервная копия не содержит всех необходимых данных.

    Типичный случай из практики: на предприятии успешно выполнялось резервное копирование рабочих документов и баз данных 1С. Но, когда отказал основной жёсткий диск с данными, обнаружилось, что электронной почты в копиях нет. На вопрос директора, почему, администратор ответил «а чего её было копировать, это же просто почта?». Системщик считал, что, раз почта для него лично ценности не представляет, значит, она ценности не представляет вообще. К сожалению, почта содержала всю историю переписки с поставщиками и покупателями, их контакты и оперативные цены на продукцию фирмы.

    Если бы тот администратор попытался выполнить восстановление сервера до аварии, он мог выявить недостаточность резервного копирования заранее.

    Выполняйте копирование всех данных, обрабатываемых на предприятии. Если что-то копировать не нужно — значит, и данные эти не нужны. Удалите их, они бесцельно заполняют собой дисковое пространство. Что-что? Удалять нельзя, эти данные нужны? Тогда включите их в план резервного копирования.


    Типичный случай номер два: компьютер шиномонтажа представлял собой обычную машину класса PC, на которой была установлена ОС Windows XP и производственная программа. Так сложилось, что за её работу никто из IT-персонала не отвечал — руководство не считало должным озаботиться вопросом её поддержки, а системщики тоже не горели особым желанием увеличивать себе объём работы. Но «это» однажды случилось — въезжающий в бокс автомобиль протаранил шиномонтажный станок и повредил компьютер. Резервных копий состояния системы или инсталляционных файлов производственной программы нигде не было. Так как поставщик оборудования отдельно выдать программу отказался, пришлось заказывать новый укомплектованный компьютер из Германии.

    Обошлось это приключение ОЧЕНЬ недёшево, особенно учитывая, что простой мастерской составил около недели.

    Выполняйте копирование состояния системы всех компьютеров, исполняющих программное обеспечение, критичное для работы предприятия. Даже если это — обычная рабочая станция, на которой не установлены какие-либо особые программы, заранее проинсталлируйте запасной системный блок. Если какие-то компьютеры неважны совсем — отключите и уберите их.



     - Процедура восстановления не документирована и не протестирована.

    В теории процедура восстановление системы может звучать здорово и красиво, но на практике постоянно сталкиваешься с шероховатостями, которые в учебниках не рассматриваются. Поэтому «подводные камни», на которые натыкаешься в момент срочного восстановления аварийной системы, зачастую приходится встречать методом «Джентльменов удачи», разрывая майку на груди.

    Одно происшествие, которое мне запомнится надолго, серьёзно потрепало нервы и системщикам, и прочему персоналу компании. Отказавший блок питания сервера одним махом выжег всё, к чему был подсоединён напрямую — все жёсткие диски, материнскую плату, даже процессора. Так как резервного сервера на предприятии не было, один из сотрудников привёз из дому свой компьютер, по мощности не уступавший серверу. Однако, как выяснилось, ОС Windows Server 2003, поднятая из резервной копии, вовсе не собиралась стартовать на этом компьютере, перезагружаясь в момент инициализации ядра.

    Причина-то в целом понятна — несовместимость архитектур ядра (Uniprocessor PC, Multiprocessor PC, ACPI PC и т.д.), но что делать дальше? Этого никто не знал. Резервная копия целостна, доступна и содержит все данные? Да. Аппаратура и инсталляционный компакт-диск есть? Да. А что дальше?

    Проведя двое суток в попытках восстановления сервера, мы добились успеха. Но до самого последнего момента никто не знал, получится ли. Инсталлировать и конфигурировать сервер со всеми его задачами с нуля было бы ещё более мрачной альтернативой.

    Протестируйте план восстановления системы и задокументируйте весь процесс. Заранее составьте список возможных угроз/сбоев и способов их устранения. Уделите внимание сложным, нестандартным моментам и отразите их базе знаний. Убедитесь, что IT-персонал понимает эти инструкции и умеет их выполнять.



    - Отсутствует необходимое программное или резервное аппаратное обеспечение.

    Мы любим прокалываться на мелочах. Обычно это — ерунда вроде IDE-перемычки или простейшего SATA-контроллера, которой везде полно, но никогда нет в нужный момент. Самое неприятное — это когда количество мелочей вдруг переходит в качество.

    Мне пришлось участвовать в восстановлении сервера одного предприятия, когда обслуживающий персонал пришёл в тупик по причине отсутствия таких мелочей. Всё шло «не так» с самого начала — крайне неудобное время сбоя, непонятна его причина. Приняв решение менять сервер, обнаружили, что в сменной машине нет жёстких дисков. Когда вместо требуемых SCSI-дисков сумели найти SATA, выяснилось, что на плате сменного сервера нет SATA-разъёмов. Где взять соответствующий контроллер в пятницу вечером?

    Найденный в понедельник контроллер не успел доставить слишком много радости. Внезапно! выяснилось, что инсталляционного компакт-диска тоже нет. На самом деле, его никогда и не было, а персонал даже не задумывался об этом.

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

    Восстановление сервера заняло неделю.


    Пример номер два: в одном из филиалов предприятия работал сервер видеонаблюдения. Ответственные лица периодически им пользовались для статистики использования ресурсов компании, иной раз полиция обращалась с просьбой показать лицо того, кто расплатился краденой кредитной картой. Никто не замечал его ценности, пока этажом выше не протёк водопровод.

    Диск с данными на первый взгляд выглядел неповреждёнными, но вот система больше не загружалась, и служба видеонаблюдения не стартовала. Было принято решение о переустановке системы на новый диск, что и было сделано. Как вы думаете, на чём застопорился процесс? Не было драйверов платы видеозахвата и инсталляционных файлов службы видеонаблюдения. К тому же, поставщик этой системы более не поддерживал устаревшее оборудование и предложил приобрести новую плату и программу.

    Процесс решения проблемы занял месяц. Всё это время задачи видеонаблюдения не выполнялись. Работа фирмы парализована не была, но и особых восторгов никто не испытывал.

    Полная резервная копия — не единственное, что требуется вам для восстановления системы. Убедитесь, что также имеются все необходимые инструменты, инсталляционные ресурсы,  серийные номера и документация. Протестируйте свой план восстановления заранее.



2. Как же следует выполнять резервное копирование сервера?
«Хочешь всё сделать правильным? Это плохо. Ничего не бывает правильным.» Gregory House.



    Типовые сервера нуждаются в копировании трёх типов данных:
    - Рабочие документы и базы данных, копию которых можно снять простым копированием;
    - Базы данных, для создания копии которых вызываются специальные процедуры резервирования (MS SQL, MS Exchange и другие);
    - Состояние системы, установленные программы и реестр самого сервера.

    Первые два пункта я рассматривать не буду — пусть они останутся на совести системного администратора. Тем более, обычно они особого непонимания не вызывают. Но вот по третьему пункту недоработки встречаются достаточно часто, поэтому на них следует остановиться подробнее.

    В теме резервного копирования и восстановления ОС Windows есть понятие System State. Что оно включает в себя? Для типичного Windows Server это:
    - Registry (Реестр);
    - Boot files, system files (загрузочные и системные файлы);
    - COM+ Class Registration database (база COM+);
    - IIS Metadirectory (метабаза веб-служб Internet Information Server), если служба установлена;
    - Certificate Authority database (база данных служб сертификации), если служба установлена;
    - Cluster Service information (информация службы кластеризации), если служба установлена;
    - Active Directory database (база домена Active Directory), если служба установлена.

    Иногда системные администраторы, создавая план резервного копирования рядового сервера или сервера Active Directory на базе Microsoft Windows 2000/2003, не учитывают, что основная ценность System State заключается в копии реестра и базы Active Directory, но полностью всё программное обеспечение, установленное на компьютере, в этот тип копирования не включается.


    Случай из практики: отказал терминальный сервер с Microsoft Office. Администратор решил переинсталлировать сервер с нуля и восстановить его состояние из System State. Процедура прошла гладко, но установить MS Office на восстановленную машину не получилось — по уверениям реестра, офисный пакет был уже установлен. Что ж поделаешь, давайте его уберём через Control Panel и установим снова? Как бы не так. Убрать тоже не получилось — протокола службы Windows Installer не было как файла. Содержимое папки Installer-а не входила в System State.

    Пришлось форматировать диск и начинать процесс с нуля. Что ж, сделаем иначе. Установим систему, добавим к ней Microsoft Office, затем восстановим из резервной копии System State. И снова промах. Оказывается, мнения System State и установленного MS Office насчёт сервиспака и  post-sp обновлений могут существенно различаться.

    Даже решив эту проблему, администратор получал всё новые приключения на свою голову. Например, все пользователи потеряли свои профили вместе со всем их содержимым, а это было уже на порядок проблемнее, чем обновления какой-то программы.

    Создавайте резервные копии не только System State, но и системного диска в целом. Да, Microsoft обдумала и внесла коррективы в процедуры резервного копирования. Начиная с Windows 2008/Vista, System State включает в себя папку самой операционной системы и Program Files. Однако, это ещё не повод расслабляться — если профили пользователей неперемещаемые, убедитесь, что вы сохраняете и их тоже.

    Не создавайте копии сервера Active Directory обычными программами снятия образов диска. Если контроллер один, несколько рабочих станций могут потерять канал связи с доменом (если образу более 30 дней, этот канал потеряют все). Причина ситуации — по умолчанию, раз в 30 дней рабочие станции меняют свои пароли.

    Если контроллеров несколько, то последствия будут сложнее. Более подробную информации ищите в статьях Microsoft Technet “How to detect and recover from a USN rollback in Windows Server 2003” (http://support.microsoft.com/kb/875495) и ”Fixing Replication Lingering Object Problems” (http://technet.microsoft.com/en-us/library/cc738018(WS.10).aspx).

    Автоматизируйте создание копий средствами Task Scheduler. Однажды сделанная вручную копия может оказаться бесполезной, ведь компьютерная сеть редко бывает статичной. Что-то постоянно меняется — ставятся обновления на систему и программы, не остаются статичными профили пользователей, и устаревшие данные могут оказаться уже просто ненужными. Робот, выполняющий задачу копирования, не откладывает свои дела на завтра-послезавтра-айпотом.

    Создавайте несколько копий. Как минимум, одну локальную — для быстрого доступа к данным, одну сетевую — для достижимости копии в случае полного сгорания сервера, одну съёмную, увозимую домой — для сохранности копии в случае пожара или затопления здания.

    Проверяйте качество создаваемых копий. Со стороны может казаться, будто процесс происходит «на ура», но нехватка места при создании файла копии или сбой в сети при передаче уже созданного файла могут быть не столь очевидными. Вроде файл присутствует, вроде большой — но что в нём внутри? Пусть скрипт проверит журнал копирования и пришлёт вам сообщение на е-майл.



3. Некоторые особенности восстановления серверов.
«Хьюстон, у нас проблема.» James Lovell.



    Рано или поздно, но этот момент приходит. Отказывает материнская плата или кто-то случайно удаляет не тот Organizational Unit в Active Directory, и сервер приходится восстанавливать из резервной копии. Которая, надеюсь, у вас была приготовлена заранее, является целостной и содержит все необходимые данные.



    - Восстановление сервера на новой аппаратуре.

    Может так оказаться, что, переставив системный диск (или восстановив его резервную копию) на новый компьютер, вы получите неработоспособный сервер. Это может быть просто перезагрузка в момент инициализации ядра или синий экран INACCESSIBLE_BOOT_DEVICE:

    Если вы восстанавливали сервер программой NTBackup, может помочь оперативное вмешательство в Диспетчере Устройств. По окончании процесса восстановления не спешите выходить из режима Safe Mode/Directory Services Restore Mode. Откройте Device Manager и замените драйвер ATA-контроллера на стандартный и/или замените драйвер Компьютера на Standard PC:

    Если этого окажется недостаточно, вам может помочь процесс восстановления сервера (Repair), запущенный с инсталляционного компакт-диска. Убедитесь, что это диск с той же версией Windows, что установлена на компьютере, и в него интегрирован тот же Service Pack.

    По окончании процесса восстановления системы потребуется переустановить все post-ServicePack обновления системы,проверить версии драйверов оборудования и состояние профилей пользователей (например, пользователя Default User).



    - Восстановление Active Directory при наличии нескольких контроллеров.

    В силу обстоятельств или злого умысла может случиться так, что будет удалена или безвозвратно испорчена важная информация в Active Directory — например, пропадёт учётная запись пользователя, группы или даже целое Организационное Подразделение (Organizational Unit). При этом изменения, выполненные на одном контроллере, будут быстро среплицированы и также применены на остальных контроллерах.

    Прямая попытка восстановить резервную копию System State на каком-либо из контроллеров не принесёт успеха. Рассмотрим ситуацию, когда у нас имеются два контроллера — Альфа и Браво. Предположим, во вторник на контроллере Альфа было случайно удалено ОП Managers со всей вложенной информацией — учётными записями менеджеров, группами и другими вложенными объектами, и репликация уже произошла. Беда, но не трагедия – у нас же есть резервная копия System State, выполненная буквально за день до этого, в понедельник. Загружаем Альфа в режиме Directory Services Restore Mode, выполняем восстановление, рестарт.

    Первое, о чём подумает Альфа после загрузки — о, только что был понедельник, а ведь уже вторник неожиданно подкрался. Я так давно не общался со своим партнёром по репликации Браво, пойду узнаю, какие есть новости.

    Альфа:    Привет, Браво. Последний раз мы с тобой общались в понедельник. Какие новости?
    Браво:    Привет, Альфа. У меня кое-что есть новое для тебя. Пока тебя не было, мы тут во вторник решили удалить ОП Managers. Будь любезен, выполни удаление у себя тоже.
    Альфа:    Понял тебя, выполняю удаление.

    Вот так новости... Как же нам восстановить ОП, если после ближайшей репликации оно снова удаляется? За то, чтобы восстановление было успешным, отвечает так называемое Авторитарное Восстановление (Authoritative Restore). После завершения операции восстановления System State мы закрываем NTBackup, но не перезагружаем сервер в обычный режим работы. Сначала выполняем команду ntdsutil:

    Последнюю команду выполните дважды, чтобы восстановленные учётные записи заполнились данными о членстве в группах. Более подробную информацию  о параметрах команды ntdsutil и вариантах восстановления удалённых учётных записей ищите в статье “How to restore deleted user accounts and their group memberships in Active Directory” (http://support.microsoft.com/kb/840001).



    Проводя аудиты компьютерных сетей, я всегда прошу администраторов показать план восстановления, собственно резервные копии, а также продемонстрировать навыки по восстановлению системы и данных. Дать высокую оценку по всем пунктам удаётся лишь в редких случаях. Должен признать, я и сам — далеко не идеал в этом смысле, иной раз забываю посмотреть отчёты резервного копирования или оформить все детали плана восстановления на бумаге.

    Однако, лучше поставить перед собой цель построения отказоустойчивой системы и последовательно достигать её исполнения, чем даже не думать об этом. Пусть количество сбоев в вашей инфраструктуре равняется количеству успешных восстановлений!