Pull to refresh

Пока гром не грянет…

Reading time 3 min
Views 31K
Возможно, кому-то уже доводилось попадать в неприятную ситуацию – когда по какой-то причине выходит из строя RAID-контроллер, или просто массив «рассыпается». Особенно часто это происходит с дешевыми контроллерами, встроенными в материнскую плату. Расскажу небольшую, но поучительную историю, произошедшую со мной на заре моей админской карьеры.
image



Итак, однажды все же случилось то, что могло представиться только в страшном сне.
Одним прекрасным утром ко мне подходит наш тестировщик и спрашивает: «А что случилось с TFS'ом?». TFS – Team Foundation Server, некое веб-приложение, завязанное с MS Visual Studio, используемое программистами для отслеживания багов, и возможно – еще для чего-то, во всяком случае для меня этот TFS был «черным ящиком».
Сервер, на котором это приложение запускалось представлял из себя обычный системный блок, с внешним SATA RAID-контроллером Adaptec 2410S. На трех SATA-дисках объемом 149Гб был создан массив RAID5, на котором все и было установлено. Батарейки у контроллера, естественно не было. Да, сейчас в меня полетят помидоры, но увы – сервер был поднят еще до меня, на брэндовый (судя по всему) денег не давали, да и я тогда особо не задумывался об этом. А зря.
Итак, я, ничего плохого не подозревая, пингую сервер, на котором был установлен TFS. Не пингуется. Матерясь про себя, я пошел в серверную проверять кабеля — вроде все в порядке, сервер включен, диод “Link” на сетевой карточке горит. Захожу на сервер с KVM'a – и вот оно: «Non-system disk or disk error». С помощью Святой Троицы (Ctrl-Alt-Del) я перезагружаю сервер. Проходит POST, инициализируется RAID-контроллер и вдруг… «Array #0 has missing required members. Found 0 arrays.» Теперь я начинаю материться уже вслух. Нажимаю Ctrl-A, захожу в BIOS контроллера.
Смотрю — а статус массива — FAILED. Два диска из трех показаны серым цветом.
«Так вот ты какая, белая северная лисичка!» — подумал я. Начал думать, что же, собственно, произошло. Контроллер вроде как работает. Диски тоже будто бы видны. Запускаю проверку обоих «проблемных» дисков утилитой в BIOS контроллера. Проверка проходит успешно, «0 errors found». Перезагрузка — опять массив не найден.
Написав заранее заявление об увольнении, я раскручиваю корпус сервера, ставлю его рядом со своим компом, подключаю жесткие диски (благо, они были SATA и я подключил их напрямую к материнке) и загружаюсь.
Винты вроде бы определились. Надо теперь как-то вытащить с них данные, а именно – базы данных MS SQL Server 2005, в которых хранились данные TFS. Самая большая проблема заключалась в том, что надо было каким-то образом воссоздать структуру RAID-массива, и при этом не потерять данные.
Блуждая по интернету, наткнулся на прогу Runtime RAID Reconstructor (www.runtime.org).
В описании было сказано, что она может автоматически определить структуру массива. Качаю, запускаю.
Окно программы выглядит так:
image

В левой части окна я выбрал свои диски. Кстати говоря, эта программа позволяет создать полные образы дисков и потом подключать их вместо «живых» дисков — может оказаться полезным, когда диск начинает «сыпаться» и может выйти из строя в любую минуту.
Затем я нажал «Open Drives» и «Analyze», чтобы проанализировать структуру массива.
В мастере анализа, кстати, нет размера блока 512Кб (который вроде как использовался у меня), но можно добавить Custom Size, что я собственно и сделал. Количество секторов для анализа я оставил дефолтное (10000).
Анализ прошел успешно, структура массива была определена.
После этого она создала Virtual Image File — маленький (меньше 1Кб) файл с расширением *.vim, в котором описывается структура массива.
Эта же программа затем предлагает открыть файл разными утилитами от Runtime — Captain Nemo, GetDataBack, Disk Explorer. Мне нужна была, судя по всему, Captain Nemo: задача была – вынуть данные с дисков. Качаю. Ставлю.
Открываю ей свой vim — и, о, чудо! — увидел полное дерево папок! Нашел нужные файлы баз, сохранил их через Captain Nemo на свой винт и подключил на свежеустановленном TFS'e — и все заработало! Можно сказать, «пронесло». Заявлние об увольнении отправилось в шредер.
Теперь — подведем итоги.
В качестве сервера использовался обычный системник.
Система вместе с БД лежали на одном 3-дисковом массиве RAID5, на одном разделе.
Массив был построен на 3 SATA винтах, с использованием контроллера Adaptec 2410SA.
Причины сбоя так и не удалось установить. По моим подозрениям, причиной стал сбой по питанию. RAID-контроллер не снабжен BBU (батарейкой резервного питания) и, по-видимому, во время записи на диск произошел сбой питания, в результате чего потерялась некая информация о структуре массива, и контроллер стал считать 2 жестких диска сбойными.
Мораль сей басни такова: Нельзя целиком доверять RAID'у! Особенно — сделанному на дешевом железе. RAID никогда не заменит бэкап на отдельный носитель.
Надеюсь, сей опус поможет кому-нибудь, кто попадет в подобную ситуацию. Но все же еще больше я надеюсь, что она поможет не попадать в нее. Как известно, админы делятся на тех, кто еще не делает бэкап, и на тех, кто уже делает. Если хоть один из прочитавших этут статью перейдет во вторые, минуя первое — я буду считать, что моя цель выполнена. На этой оптимистичной ноте я, пожалуй, закончу.
Tags:
Hubs:
+55
Comments 155
Comments Comments 155

Articles