 |
|
|
|
Поучительные истории о резервном копировании
Поучительные истории Автор рассказывает о нескольких реальных случаях ошибок в организации резервного копирования и дает рекомендации, как их избежать В основу этого повествования, местами грустного, местами забавного, лежат реальные события и факты. Мне приходилось лично наблюдать ошибки системных администраторов, как начинающих, так и уже имеющих опыт, и эти ошибки приводили порой к довольно тяжелым последствиям.Важное замечание. Все описанные случаи происходили на самом деле. Никаких имен не называю, и некоторые мелкие детали сознательно изменены в целях анонимности. Но в целом эти прецеденты могут послужить хорошим уроком. История первая. «Замкнутый круг» Мне довелось работать в одной организации, которая, несмотря на то что находилась в прибыльном рыночном сегменте, отличалась крайней небрежностью в области информационных технологий. Обязанности системного администратора исполнял тихий вежливый молодой человек, который почему-то считал, что главная обязанность ИТ-специалиста – с утра до вечера помогать бухгалтерам в их нелегком труде. Для других дел у него попросту не находилось ни времени, ни сил, ни желания.Мои функции носили скорее консультативный характер, а хороший консультант, прежде чем дать рекомендацию, должен выяснить все обстоятельства. Но ответ на невинный вопрос: «А как выполняется резервное копирование?» – я получил просто удивительнейший ответ: «А у нас «железо» очень надежное, нам резервное копирование не нужно!»Этим «надежным железом» оказались старенький сервер Supermicro, который одновременно играл роль почтового и файл-сервера, а также контроллера домена AD.Сказать, что я был слегка шокирован, – это не сказать ничего. Но «законы Мерфи», как и другие законы окружающего мира, например, физики или экономики, опираются на реальное положение вещей. И результат такого пренебрежительного отношения к резервному копированию не заставил себя ждать – через пару дней сервер перестал загружаться. Причина проста – авария жесткого диска. Как раз такой случай, когда никто не виноват, но восстанавливать работу как-то нужно.Надо сказать, что в качестве средства «высокой надежности» использовался RAID-5, который включал в себя один-единственный массив, содержащий все жесткие диски сервера. Средствами Windows он делился на два логических диска: «C:» и «D:». И этот самый RAID-массив после сбоя диска никак не переходил в состояние Degraded, то есть в режим обеспечения доступности за счет оставшихся дисков и контрольных сумм. Не помогли не перезагрузка, ни временное выключение с выдергиванием кабелей питания. Все диски видит, а в Degraded не переходит, выдает сбой, хоть плачь.Срочно был созван военный совет из начальника ИТ-отдела, системного администратора и других специалистов. И первый вопрос, который прозвучал на повестке дня: «А за какое число у нас сделан бэкап?» Молодой человек побелел, потом покраснел и дрожащим голосом тихо сказал: «Я же как-то говорил вам, что у нас для резервных копий места нет, помните?»Руководитель ИТ-отдела был на редкость выдержанный и воспитанный человек. Тем более он совсем недавно заступил на эту должность. Поэтому он не стал устраивать скандал. Вместо этого он тихо и вкрадчиво произнес: «Что, совсем ничего не сохраняется?» «Копия контроллера AD», – ответил сисадмин.На лице шефа от ИТ отразилось что-то вроде: «Ладно, как-нибудь отобьемся, хотя бы новый домен делать не придется...» «А где это лежит?» «На диске D», – радостно ответил системный администратор. «На каком компьютере?» – недоверчиво спросил начальник. «На том же сервере!» – бодро отрапортовал молодой сисадмин.«Занавес!» – как говорят драматурги.Сервер мы все же восстановили. Для этого почему-то пришлось «походить» по меню консоли RAID-контроллера, а потом сохранить параметры и выйти. И он перешел в режим Degraded, далее быстренько сняли резервную копию двумя способами подряд: через встроенную утилиту ntbackup и простым копированием. На самом деле на складе лежала в запасе пара исправных рабочих станций с довольно большими по объему дисками, поэтому вопрос, куда сделать бэкап, в принципе не стоял. В общем, все хорошо, что хорошо кончается. Какие выводы можно сделать из этого случая? Источником всех бед является неправильное понимание роли ИТ-службы в современном бизнесе. Эта служба призвана не «помогать пользователям», а обеспечивать бесперебойное функционирование информационных систем.Никогда нельзя замалчивать проблемы. Принцип «подальше от начальства, поближе к кухне» в сфере информационных технологий работает с точностью до наоборот. Поэтому, если нет возможности организовать нормальное резервное копирование в силу материальных причин – нет соответствующего оборудования, программного обеспечения и так далее, – нужно, что называется, «звонить во все колокола», пока проблема не будет окончательно закрыта. При этом устные высказывания вроде «когда-то что-то сказал», как правило, не работают. Все заявки на покупку оборудования, выделение времени для работ нужно подавать исключительно в письменном виде.В данном примере таких проблем не наблюдалось вовсе. Руководство компании в принципе было не против выделить деньги на резервные копии. Как выяснилось впоследствии, некоторые сотрудники даже сами на свои деньги покупали съемные носители и сохраняли на них какие-то рабочие данные, оставляя тем самым широкую брешь в системе безопасности. Все, что останавливало,– нежелание самого системного администратора приложить некоторые усилия к решению данной проблемы и отсутствие контроля «сверху».Ну и, конечно, нельзя допускать анекдотичной ситуации из серии «Ключ от срочной медицинской комнаты хранится в срочной медицинской комнате». Резервные копии должны быть размещены таким образом, чтобы при аварии к ним можно было без особых трудов получить доступ. И уж точно ни в коем случае не размещать копии на тех же ресурсах и оборудовании, данные которых они же и содержат.Примечание. Бывает, что человек, отвечающий за распределение финансов, прямо отказывается закупать что-то необходимое или применяет тактику молчания, попросту тянет время, иногда мотивируя свой ответ чем-то вроде: «Вот когда что-то случится, тогда и будем что-то решать». Чтобы этого избежать, необходимо обязательно просить завизировать соответствующий документ, например, написать «Согласен» или «Отказать» и поставить подпись.Но что делать, если такой босс оставляет бумагу у себя со словами «Я посмотрю...», и все остается на том же месте? Значит, через короткий промежуток времени нужно снова принести такие же документы на подпись, а потом еще и еще раз, пока не будет получен результат. Иногда полезно обратиться к вышестоящему руководству, вплоть до учредителей компании. Готовых рецептов для таких ситуаций быть не может, поэтому нужно действовать с учетом специфики предприятия. Но всегда ксерокопии всех докладных, служебных записок, счетов и коммерческих предложений нужно оставлять у себя на случай несправедливых обвинений. История вторая. «Все в одном флаконе» Эта история произошла в довольно крупной компании, имеющей офисы в нескольких местах. И, что удивительно, хватало и времени, и средств, и ресурсов, и квалификации специалистов.Резервное копирование было построено следующим образом: в качестве основного ПО резервного копирования использовалась неплохая программа CA ARCServe – очень хорошее и надежное средство, которое на тот момент имело ряд преимуществ, том числе в плане цены и быстродействия. Она использует централизованную топологию и через программы-агенты собирает данные с защищаемых ресурсов, чтобы после записать на ленточные носители или в файлы-контейнеры.В качестве основной системы хранения использовалась ленточная библиотека фирмы Quantum c шестью накопителями на магнитной ленте стандарта LTO2. А подключалась эта чудо-система через SCSI-кабель к серверу на MS Windows 2003, просто ничем не выдающаяся «железка» HP ProLiant DL360 G4, старенькая, но вполне рабочая. Основной ее задачей было управление ARCServe, а также отправка собираемых данных на ленточную библиотеку.Основная проблема заключалась в следующем. Для сбора данных со всей весьма немаленькой инфраструктуры было создано одно-единственное задание резервного копирования, и все данные собирались на один-единственный сервер с ленточной библиотекой. Надо ли говорить, что в связи с довольно богатой историей компании в ее составе работали не только самые современные, но и весьма устаревшие «динозавры». Свои данные системе резервного копирования они отдавали долго и нехотя, подключенные по большей части через FastEthernet 100Mbps, процесс создания резервных копий превращался в долгий и мучительный труд. Full Backup начинался в пятницу в 18-00, сразу после окончания рабочего дня, и заканчивался в понедельник около 10 часов. При этом если происходил какой-то сбой, то всю неделю компания жила со старым бэкапом, в надежде, что черные силы пройдут стороной. Руководство компании ценило производительность работы сотрудников гораздо выше безопасности работы ИТ-инфраструктуры и не разрешало нагружать систему таким «бесполезным занятием», как резервная копия.Часто беда приходит со стороны, но и человек сам кузнец своего счастья. Пользователи стали жаловаться на замедления в работе электронной почты, на доставку писем с большим опозданием. Старенький сервер с MS Exchange 2003 еле-еле копошился в раздутой почтовой базе, в которой каждый пользователь сохранял не только письма, но и объемные файлы-вложения. Молодой руководитель ИТ-отдела принял замечательное решение: выполнить дефрагментацию почтовой базы данных. Это вполне рабочая процедура, позволяющая хоть как-то ускорить процесс обработки.И так как работа бизнеса – это святое, он не соглашался провести эту операцию в никакое другое время, кроме выходных. Как раз тогда, когда должен выполняться бэкап.Уговоры, протесты и даже мольба системного администратора не возымели на молодого шефа никакого действия. Он отдает команду под свою личную ответственность выполнять дефрагментацию, не дожидаясь создания резервной копии. Зная, что этот процесс может занять долгие часы, он так торопился, что отказался даже сделать средствами копирования дубликат базы на другом сервере и работать с ним. В итоге все работы велись с той же самой базой на том же самом сервере. Результат нетрудно предугадать – по неустановленной до конца причине происходит сбой, после которого почтовая база оказалась повреждена, процесс резервного копирования не был доведен до конца и резервная копия не была создана.Но это еще не все. Два предыдущих бэкапа также потерпели фиаско. В итоге организация восстановила данные из совсем старой копии месячной давности. Актуальная переписка была потеряна. Что-то удалось восстановить из кэша почтовых программ-клиентов. Большая часть переписки за последний месяц была утрачена.Подводя итог это печальной истории, можно отметить несколько ключевых моментов:
История третья. «Ни шагу назад» Проводя аудит в одной компании, столкнулся с весьма занятным изобретением. Назвать это системой резервного копирования просто язык не поворачивается.Итак, к файл-серверу был подключен по USB небольшой дисковый массив RAID-0 из двух дисков. Он же был объявлен в качестве публичного сетевого ресурса. Далее на каждом сервере в назначенный час запускалась команда robocopy, которая синхронизировала копию данных на вышеописанной сетевой папке. При этом, если файл был удален на исходном ресурсе, то он также удалялся из копии.Судя по всему, таким образом решался вопрос роста объема резервной копии, которая просто не могла быть больше, чем совокупный размер исходных файлов.Что сразу бросалось в глаза, это общая ненадежность конструкции. Во-первых, USB-соединение время от времени отваливалось. Если сисадмин замечал это, он шел в серверную и вручную выдергивал и заново подключал USB-кабель. Если такая проблема происходила в неурочный час, например, в выходные или ночью, то запущенная синхронизация не выполнялась.Если пользователь по ошибке удалял файл и сразу сообщал об этом, то шанс на восстановление из вчерашней копии еще оставался. Если системного администратора не было на месте или пользователь обнаруживал «недостачу» файла слишком поздно, ничем помочь уже было нельзя.Далее стоит привести слова администратора баз данных, работавшего с 1С: «Пока ничего не сбоило, все было нормально. Но однажды случилась неприятность, и, чтобы восстановить работу нашей бухгалтерии, понадобилась копия за прошлые даты. Конечно, взять было неоткуда. Мы просили любую копию, хотя бы с начала года, но все тщетно. В итоге заново проводили вручную весь период».Вывод из этой печальной истории напрашивается сам собой. Нельзя путать репликацию с системой резервного копирования. И уж точно нельзя отказываться от архивного копирования. Копии данных за прошлые периоды могут понадобиться по множеству причин: проверка со стороны СБ, ошибка пользователя, скрытый сбой, последствия которого были обнаружены через некоторое время, и многое другое. Иначе можно остаться «у разбитого корыта», точнее, с одной-единственной резервной копией, содержащей ошибочные данные.Само собой разумеется, нельзя держать резервные копии на таком ненадежном устройстве. Какой смысл вообще делать резервную копию на массив RAID-0, который является более уязвимым, чем одиночный жесткий диск. И уж точно не надо подключать устройства для хранения копий по постоянно «отваливающемуся» соединению. История четвертая. Вереница снимков История эта случилась у одного из крупных системных интеграторов. Ко мне обратился сетевой инженер с просьбой помочь ему вернуть к жизни виртуальную машину, отвечающую за статистику.Система виртуализации VMware ESXi сама по себе довольно надежна. Но, открыв консоль, я с изумлением обнаружил, что данная виртуалка имеет как минимум пятнадцать моментальных снимком, следующих один за другим.Первая мысль была о том, что это напакостила система резервного копирования. Напомню, что копирование виртуальных систем производится с созданием снимка [1]. Пока свежие измененные данные сохраняются в дополнительно созданном виртуальном диске, можно скопировать образ нетронутой, или, как говорят, «замороженной», виртуальной машины. Такой метод связан с определенными накладными расходами системных ресурсов. Иногда программа системного копирования «забывает» удалить за собой снимок, и может накопиться несколько снапшотов подряд. Тогда ощутимо снижается общее быстродействие, и системный администратор вынужден вручную наводить порядок в системе, удаляя лишние снимки.Но, как оказалось, всю эту «вереницу» создал… сам сетевой инженер. Человек искренне считал, что моментальный снимок – это и есть резервная копия. При этом его нисколько не смущал тот факт, что все это «хозяйство» хранится на том же томе, что и основная виртуальная машина.Разумеется, когда снимков накопилось изрядное количество, виртуальная система уже не смогла поддерживать такую незаурядную виртуальную машину в рабочем состоянии, что вызвало сбой с последующим разрушением файловой системы на виртуальном диске.В итоге все закончилось не так уж плохо. Откат на несколько снимков назад (разумеется, с потерей данных за соответствующий период) позволил загрузить виртуальную машину. Для удаления снимков я выполнил экспорт виртуальной машины в контейнер (OVF) и развернул под другим именем.Так как приобретать нормальную систему резервного копирования никто не планировал, я просто научил инженера вместо создания моментальных снимков выполнять экспорт данных в файл и сохранять его на другом физическом компьютере. Хотя без нормального бэкапа все равно плохо. История пятая. Ночной сюрприз Работал в одной компании в крупном ИТ-подразделении один молодой системный администратор. И так уж случилось, что он был вынужден по личным обстоятельствам часто отпрашиваться с работы. Причина была очень уважительной, и его отпускали безоговорочно. Но его мучил комплекс вины. Ведь пока он отсутствует, его коллеги вынуждены выполнять его работу. И он решил сделать им приятный сюрприз.В составе инфраструктуры работал сервер, на котором был запущен MS SQL. На дисковом массиве сервера было оставлено неразмеченное пространство «на всякий случай». Но время шло, базы данных разрастались, и места на логическом диске стало не хватать. Его можно было расширить, используя неразменное пространство, но все «руки не доходили». Но каждый раз кто-то постоянно жаловался на нехватку места.Однажды вечером наш герой задержался на работе. Дождавшись, когда все уйдут, он приступил к расширению диска. С помощью программы Acronis True Image он сделал снимок системы. Если бы он подготовился заранее и почитал о различных методах решения данной задачи, он мог бы просто использовать утилиту diskpart и закончить работу с массивом. Но молодой сисадмин был полон уверенности в достаточности своих знаний и решил действовать «в лоб». Поэтому он удалил все разделы, зачем-то создал новые и хотел уже восстановить обратно данные из образа, но… сделал ошибку, снова запустив копирование, и перезаписал уже существующий образ. Сказались стресс и усталость, в общем, такие случаи хоть и происходят нечасто, но могут случиться с каждым из нас.Он бросился к полкам с лентами, на которых хранились резервные копии. Но так как система резервного копирования была полностью в зоне его ответственности, а он в силу личных обстоятельств за ней не следил… Как выяснилось позже, резервные копии не выполнялись уже весьма продолжительное время.Остаток ночи он провел за тщетными попытками исправить ситуацию. Это была последняя и самая роковая ошибка. В панике он пытался применить то один способов восстановления, то другой, тем самым уничтожая последние шансы восстановить разделы на диске и затертый файл образа диска.Какие-то данные потом восстановили частично из совсем старых резервных копий, какие-то – из таблиц других баз данных с других серверов. Какие же ошибки совершил системный администратор?Первый и самый страшный просчет – спонтанное выполнение несогласованных работ. Всех неприятностей можно было избежать, если заранее проработать теоретическую и практическую части работ, выполнить тестирование на стенде и только потом приступать к активным действиям на промышленном оборудовании.При осуществлении таких критических действий, помимо штатного резервного копирования, обязательно нужно иметь минимум две копии, два образа системы, желательно сделанные разными программами и обязательно размещенные на разных ресурсах. Ведь сбой может случиться не только на «подопытном» сервере, но и на оборудовании, где хранится образ системы.Ни в коем случае нельзя утаивать проблемы. При любом раскладе нужно иметь мужество заявить о проблеме. Умение признавать ошибки, порой самые тяжелые, – отличительная черта профессионала. Если бы наш герой не пытался в панике что-то исправлять, а позвонил своим коллегам, пусть даже среди ночи, или оставил все как есть до утра и честно рассказал обо всех злоключениях, это увеличило бы шансы на более успешный исход.И последнее. Что это за безобразие – не следить за резервным копированием?! Если не получается уследить самому, нужно поручить эту миссию другому сотруднику. Обязательный контроль, включая тестовые проверки, – это то, что должно быть всегда. История шестая. «Надежный» антивирус Эта забавная история произошла несколько лет назад. Проводя штатное тестирование резервных копий, я обнаружил, что большая часть ночных заданий full-backup не выполняется. При этом задания, в которых фигурируют небольшие объемы данных, по большей части отрабатывают нормально.После некоторых изысканий было установлено, что виной всех бед является антивирусный монитор от одного из известных российских производителей. Когда программа резервного копирования запускает мощный процесс передачи данных, антивирус не в состоянии пропустить через себя такие объемы информации и просто отключает процесс копирования. Никакие «танцы с бубном» не принесли результата, и, влекомый искрой последней надежды, я обратился в техническую поддержку производителя антивируса.Ответ сотрудника техподдержки был убийственным: «А зачем вам резервная копия? У вас же антивирус очень хороший!». Я не счел нужным продолжать этот разговор.Резервное копирование я все-таки настроил. Для этого пришлось отключить антивирусный монитор на серверах и использовать только сканер. Обидно, компания заплатила немалые деньги за это ПО. Выручил бесплатный Comodo Antivirus, чья лицензия в те старые добрые времена позволяла использовать его в том числе и на серверах.Как я уже говорил, в данной статье описаны реальные случаи, произошедшие с разными людьми и в разное время. Я очень надеюсь, что эти крупицы бесценного опыта, которые я попытался обобщить в рамках одной статьи, помогут ИТ-специалистам избежать ошибок в организации резервного копирования.
|
АЛЕКСЕЙ БЕРЕЖНОЙ, независимый консультант, системный архитектор, специалист по системам виртуализации и резервного копирования, Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
