Универсального бэкапа не существует?

Есть три типа админов: те, кто делает бэкап; те, кто уже делает бэкап; и те, кто ещё и периодически его проверяет. Это история о том, как мы построили дорогую enterprise-систему резервного копирования и считали её надёжной. Пока однажды не выяснилось, что без одного промежуточного звена восстановить данные с ленты невозможно.

Меня зовут Евгений Касаткин, я руководитель отдела ИТ-проектов и интеграции в операторе ИТ-решений «ОБИТ». Несколько лет назад я занимался резервным копированием в крупной региональной логистической компании. Как и во многих крупных организациях, вопрос хранения данных там был критически важен: рабочие документы, файловые архивы, базы данных — всё это требовало гарантированного восстановления.

Для решения задачи был развернут полноценный дорогостоящий программно-аппаратный комплекс из следующих компонентов:

Networker (EMC) + EMC VNX + LTO

В сжатом состоянии хранилось приблизительно 1PB данных (впечатляет, согласны?). Дедупликация делала своё дело, а с учётом большого объема повторяемых данных (резервная копия, всё же) данные впихивались в эту железку с завидной плотностью. Задания РК разделялись на оперативные, долгосрочные и очень долгосрочные. Оперативные задания выполнялись на локальное хранилище сервера, где хранились не больше двух недель. Было предусмотрено и место на томах для восстановления определённого объема данных.

Для enterprise-сегмента такая схема вполне типична. Особенно там, где инфраструктура работает 24/7 и простой даже на несколько часов может стоить очень дорого. Все выглядело проработанным и работоспособным. Таковым и являлось:

Спустя время в наш отдел прилетела нестандартная бизнес-задача: пересмотреть Disaster Recovery политику и проверить возможность восстановления данных при отказе из одного узлов резервного копирования. Конкретно — без доступа к дисковой полке. Для справки: дисковая полка — набор жестких дисков с «мозгами» для хранения большого объёма данных, с возможностью дедупликации, что мы активно использовали в системе резервного копирования. Плюс к этому вендор ушел из России, хлопнув дверью и закрыв доступы к сайтам. И все что имеется — лента, стример и старенький сервер. Готовы восстановить? Конечно (а нет выбора).

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

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

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

Где ошибался инженер? Практически нигде. Все собрано по букве инструкций от вендора. Все соответствовало требованиям РК, и здравому смыслу. Успешно проходило и восстановление данных. Была и апробированная Disaster recovery инструкция.

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

Все интересные задачи для нас, как для проектного отдела, начинаются со слов «Мы все сделали правильно, но что-то пошло не так».

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

Как избежать таких ситуаций? Нет 100% решения. Однако, существуют наработанные практики и тот важный и, местами, горький опыт, которые позволяют подобрать наиболее подходящие и устойчивые решения, а главное:

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

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