Случай из практики IT-аутсорсера

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

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

Дальнейший рассказ идет от первого лица с минимальной редакцией. Именно в таком виде мы получили его от одного из участников событий.

С чего все началось

Приехали по заявке. У клиентов частично не работали сервисы и отсутствовал доступ к файловому хранилищу. Все это хранилось на древнем HP Proliant ML350 Gen4. Сервер стоял в условной кладовке, никто о нем не вспоминал годами. Диагностику провести не удалось — сервер не пинговался и на попытки подключения по RDP не реагировал.

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

Очевидно, повреждена главная загрузочная запись. Использовали дистрибутив на основе WinPE с обычным для таких случаев софтом. Но ждал сюрприз — WinPE не могла получить доступ к массиву.

Клиент нервничал, встала работа офиса, ведь все рабочие файлы хранились на этом сервере. Резервного сервера или бэкапов не было. Нужно быстро восстановить доступ и сохранить данные в целости.

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

Скачиваем данные

Мы сообщили клиенту возможные сценарии и после недолгого обсуждения решили вытащить данные из сервера, арендовать любой самый простой сервер и залить их туда.

Для доступа к данным мы использовали популярный Live-дистрибутив для системных администраторов — GRML Live Linux. Он зарекомендовал себя в работе с любыми серверами, поддерживая огромное количество оборудования, даже старого.

Записали на флешку, загрузили. Создали папку для монтирования:

mkdir /mnt/storage

С помощью fdisk -l посмотрели, как массив определился в системе и примонтировали его:

mount /dev/sdX /mnt/storage

Нам повезло — файлы теперь видны, но их сложно вытащить с сервера. Сетевого хранилища для передачи по локальной сети нет. Подключить обычный SATA-накопитель нельзя, в сервере есть только Ultra-320 SCSI. Жесткого диска для соединения по USB также нет. Остался один вариант — залить файлы в облако, затем выкачать их на другой сервер.

В качестве облака выбрали услугу облачное хранилище от Selectel. Мы уже использовали её для хранения резервных копий других клиентов. Создали приватный контейнер, директорию для данных и отдельного пользователя с полными правами доступа. Самым простым вариантом обращения к хранилищу стало использование протокола FTP.

В комплекте с GRML есть консольный FTP-клиент под названием lftp, умеющий работать в многопоточном режиме.

1. Подключились к FTP-серверу:

   lftp ftp.selcdn.ru

2. Авторизовались:

   lftp ftp.selcdn.ru:~> user аккаунт_имяпользователя@ftp.selcdn.ru
   Password: ввели пароль по запросу

3. Запустили копирование в 10 потоков:

   mirror -R /mnt/storage/data /data --parallel=10

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

Подсчитываем итоги

Мы спасли все файлы с древнего сервера. Восстановили штатную работу офиса. Операция с перекачиванием ~60 Гб в хранилище и обратно стоила 79 рублей и 69 копеек. Старый сервер списали. Клиенту настроили VPN, он получил доступ к своим данным из любого места.

Было ли вам интересно прочитать о таком случае?
Сталкивались с подобной ситуацией?
Какой сценарий попробовали бы сами?
Ждем вас в комментариях!