Возможно, кто-то уже попадал в неприятную ситуацию – когда по каким-то причинам выходит из строя RAID-контроллер или массив просто «разваливается».
Особенно часто такое случается с дешевыми контроллерами, встроенными в материнскую плату.
Расскажу вам небольшую, но поучительную историю, которая произошла со мной в начале моей администраторской карьеры.
Итак, однажды произошло то, что можно было представить только в кошмарном сне.
В одно прекрасное утро ко мне подходит наш тестер и спрашивает: «Что случилось с TFSЭ» TFS — Team Foundation Server, своего рода веб-приложение, привязанное к MS Visual Studio, используемое программистами для отслеживания ошибок, а возможно и для чего-то еще, по крайней мере для меня этот TFS был «черным ящиком».
Сервер, на котором было запущено это приложение, представлял собой обычный системный блок с внешним SATA RAID-контроллером Adaptec 2410S. Был создан RAID5-массив на трех SATA-дисках емкостью 149 ГБ, на который все и было установлено.
Батарейки в контроллере, естественно, не было.
Да, сейчас в меня полетят помидоры, но увы - сервер подняли до меня, денег на фирменный (видимо) не дали, и я тогда об этом особо не думал.
Но тщетно.
Итак, не подозревая ничего плохого, я пингую сервер, на котором установлен TFS. Не отвечает. Ругаясь про себя, я пошел в серверную проверить кабели — вроде все в порядке, сервер включен, диод «Link» на сетевой карте горит. Захожу на сервер с KVM - и вот оно: «Несистемный диск или ошибка диска».
Используя Holy Trinity (Ctrl-Alt-Del) перезагружаю сервер.
POST проходит, RAID-контроллер инициализируется и вдруг.
«В массиве #0 отсутствуют необходимые элементы.
Нашёл 0 массивов.
" Теперь начинаю ругаться вслух.
Жму Ctrl-A и захожу в биос контроллера.
Смотрю, а статус массива FAILED. Два из трех дисков показаны серым цветом.
«Так вот кто ты, белая северная лисица!» - Я думал.
Я начал думать о том, что же произошло на самом деле.
Контроллер вроде работает. Диски тоже вроде видны.
Проверку обоих «проблемных» дисков я запускаю утилитой в биосе контроллера.
Проверка прошла успешно, «Найдено 0 ошибок».
Перезагрузка - опять массив не найден.
Заранее написав заявление об увольнении, я раскручиваю серверный корпус, ставлю его рядом с компьютером, подключаю жёсткие диски (благо они были SATA и я подключил их напрямую к материнской плате) и загружаюсь.
Винты, кажется, были идентифицированы.
Теперь нам нужно как-то извлечь из них данные, а именно из баз данных MS SQL Server 2005, в которых хранились данные TFS. Самая большая проблема заключалась в том, что нужно было как-то воссоздать структуру RAID-массива без потери данных.
Блуждая по Интернету, я наткнулся на программу Runtime RAID Reconstructor (www.runtime.org).
В описании сказано, что он может автоматически определять структуру массива.
Скачиваю и запускаю.
Окно программы выглядит так: 
В левой части окна я выбрал свои диски.
Кстати, эта программа позволяет создавать полные образы дисков и затем подключать их вместо «живых» дисков — это может пригодиться, когда диск начинает «рушиться» и может выйти из строя в любую минуту.
Затем я нажал «Открыть диски» и «Анализ», чтобы проанализировать структуру массива.
В мастере анализа, кстати, нет размера блока 512Кб (который я вроде бы и использовал), но можно добавить Custom Size, что я собственно и сделал.
Количество секторов для анализа я оставил по умолчанию (10000).
Анализ прошел успешно, структура массива определена.
После этого она создала Virtual Image File — небольшой (менее 1Кб) файл с расширением *.
vim, описывающий структуру массива.
Эта же программа затем предлагает открыть файл с помощью различных утилит из Runtime — Captain Nemo, GetDataBack, Disk Explorer. Судя по всему, мне нужен был Капитан Немо: задача была удалить данные с дисков.
Я скачиваю.
Бьюсь об заклад. Я открываю ей свой вим – и, о чудо! — Я увидел целое дерево папок! Нашёл нужные файлы базы, сохранил их через Капитана Немо на свой винт и подключил к только что установленному TFS - и всё заработало! Можно сказать: «Пролетело мимо».
Заявление об увольнении отправилось в шредер.
Теперь подведем итоги.
В качестве сервера использовался обычный системный блок.
Система и база данных располагались на одном 3-х дисковом массиве RAID5, на одном разделе.
Массив был построен на трёх винтах SATA с использованием контроллера Adaptec 2410SA. Причины неудачи установить не удалось.
По моим подозрениям, причиной стал сбой в питании.
RAID-контроллер не оснащен BBU (блоком резервного питания) и видимо при записи на диск произошел сбой питания, в результате чего часть информации о структуре массива была потеряна, и контроллер начал считать 2 жестких диска как не удалось.
Мораль этой истории такова: нельзя полностью доверять RAID! Особенно те, что сделаны на дешевом железе.
RAID никогда не заменит резервное копирование на отдельный носитель.
Надеюсь, этот опус поможет кому-то, кто оказался в подобной ситуации.
Но все же еще больше надеюсь, что это поможет не впасть в это.
Как известно, админы делятся на тех, кто еще не делает бэкапы, и тех, кто уже делает. Если хотя бы один из тех, кто читает эту статью, перейдет на вторую, минуя первую, я буду считать, что моя цель достигнута.
Думаю, я закончу на этой оптимистичной ноте.
Теги: #Системное администрирование #Восстановление данных #резервное копирование #рейд
-
Азбука Издателя Электронного Журнала
19 Oct, 24 -
Вибрационные Реакции
19 Oct, 24 -
Кухонные Тайны И Тайны Холодильника
19 Oct, 24 -
Финская «Ядерная Сделка»
19 Oct, 24 -
Изменение Useragent Сторонними Приложениями
19 Oct, 24
