Спецпроекты

Можно ли быстро восстановить терабайты потерянных данных без ущерба для бизнеса

Интеграция

Массивы информации в компаниях растут из года в год. Даже в средних организациях их объемы переваливают за 1 Пбайт, хотя всего 3-4 года назад такое было свойственно только самым крупным предприятиям. Этот тренд заставляет «сбросить с парохода современности» классические подходы хранения и резервирования данных, которые все хуже работают в новых условиях. Что брать на вооружение ИТ-руководителям при создании систем резервного копирования сегодня, в период роста информационных активов?

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

Вернуть к жизни большие СУБД

Средние объемы СУБД за последнее время увеличились с сотен гигабайт до десятков, а то и сотен терабайт. Пока они исправно работают есть иллюзия, что восстановление пройдет быстро и просто, как и при небольшом размере. История одного заказчика показывает, как ожидание и реальность разнятся в этом случае. Речь о крупной компании со зрелой ИТ-инфраструктурой. СУБД работала на двух Oracle Exadata, распределенных по двум технологическим площадкам, с проработанными DR-решениями и настроенной системой резервного копирования. Однажды сотрудник этой компании неправильно установил патч, что привело к сбою в СУБД. Систему решено было откатить. Это окончательно вывело из строя оба экземпляра базы, и все данные оказались испорчены. Компания оказалась без главного информационного ресурса — на эти БД были завязаны все бизнес-процессы. Бизнес встал.

Что делать? Решили восстанавливаться из резервной копии. И здесь масштаб катастрофы проявился в полную силу. Восстановление базы в 5 Тбайт заняло более 30 часов! Полтора дня ушло на восстановление базы на день раньше аварии, а данные, которые появились позже, были потеряны. Их пришлось восстанавливать из других источников еще полтора дня. Ущерб в результате простоя и потери времени на восстановление оказался колоссальным.

Средние объемы СУБД за последнее время увеличились с сотен гигабайт до десятков, а то и сотен терабайт

Последствия подобных «катастроф» можно снизить, если данные чаще резервировать и создать условия для быстрого восстановления, например, с помощью технологий Oracle FlashBack, Veritas Co-Pilot и моментальных снимков на системах хранения данных (snapshot). Oracle FlashBack может «перемотать» базу данных или какую-то ее часть до момента времени в прошлом. Veritas Co-Pilot не только сокращает время резервного копирования СУБД, собирая изменения баз данных и синтезируя из них полную копию без ее фактической передачи по сети, но и позволяет запустить экземпляр СУБД непосредственно из резервной копии. Мгновенные снимки на СХД помогают резервировать и восстанавливать данные за секунды. Важно, что эта технология на ряде современных СХД почти не влияет на производительность, и снимки можно делать каждый час или даже чаще.

Для критичных баз данных лучше иметь две копии в кластере — использовать как экземпляры с синхронной репликацией, так и вариант с базами в режиме Standby. Под кластерные инсталляции подходит продукт Veritas Infoscale. Решение на его основе мы развернули в нескольких банках из топ-10, а также у телеком-операторов. Veritas Infoscale позволяет пережить потерю одного из хранилищ под базами и автоматизирует восстановление экземпляра базы данных без участия администратора при выходе из строя площадки целиком. Само применение кластера дает минимальное время простоя при сбое оборудования. Но резервные копии нужно создавать даже в этом случае, чтобы защититься от логического сбоя или потери каких-то исторических данных — иногда компании об этом забывают.

Моментально воскресить виртуальные машины

Еще несколько лет назад в среднем на предприятии насчитывалось 50-100 виртуальных машин, а сегодня речь идет о 1000-1500 единицах и свыше. При таком богатом «хозяйстве» проблемы начинаются еще при подготовке к резервированию. Данные на виртуальных машинах приводятся в консистентное состояние и, если их немного, то процесс занимает до 2 минут на единицу. Окно резервирования небольшое. После завершения передачи данных по сети происходит консолидация программного снимка, сделанного системой виртуализации, — он удаляется, и к сохраненным данным добавляются те, что были записаны в виртуальную машину во время ее резервирования.

Здесь поджидает проблема, к которой многие компании не готовы. Для виртуальных машин с большим процентом изменений время резервного копирования играет существенную роль. Чем дольше длится резервирование, тем больше копится «дельта» новых данных. Потом их нужно консолидировать с виртуальным снимком, чтобы система продолжила работать корректно. Любой виртуальный снимок замедляет работу системы и при его удалении требуется время на консолидацию, в течение которого массив может оказаться загруженным под 100%.

Виртуализация не требовательна к ресурсам — это факт. Поэтому многие наши заказчики на эти системы выделяют не самые быстрые диски. Но этот подход справедлив только при небольшом количестве виртуальных машин. Если их число значительно, бэкап «спотыкается» о потенциал СХД, так как время на удаление и консолидацию снимков после резервного копирования напрямую зависит от производительности массива. Не говоря уже о том, что с быстрых массивов данные копируются за более короткий срок. Рост количества данных и окна бэкапа дают большую нагрузку на продуктивность первичной СХД, с которой классические архитектуры не справляются.

Что можно предпринять? Во-первых, использовать инструменты, которые сокращают время полного резервного копирования за счет синтеза полных копий на базе журнала Vmware CBT, — Veritas Accelerator. При этом для оперативного восстановления можно применять технологию мгновенного запуска виртуальных машин напрямую из резервной копии — Veritas VMware Instant Recovery. Во-вторых, сокращать окно резервного копирования при помощи аппаратных снимков на СХД. В-третьих, отказаться от медленных дисков и создавать первичное хранилище данных на all-flash. Это не только поможет СХД стать «сильным звеном» в цепи, но и создаст задел для перехода на технологию будущего — организацию вторичного хранилища на all-flash. На таких принципах мы стараемся строить все новые инсталляции. В прошлом году наша команда таким образом провела тотальную модернизацию СРК у нескольких крупных промышленных предприятий. В результате заказчики сократили время на резервирование и восстановление данных, увеличили доступность сервисов в целом и получили контроль над системами.

Реанимировать файловые ресурсы

Еще совсем недавно у предприятий был небольшой массив файловых ресурсов. Но со временем и объемы, и количество файлов увеличились — это неизбежный процесс, при котором новые файлы добавляются, а старые мало кто удаляет. Время резервного копирования при большом объеме файловых ресурсов также возрастает не линейно. Скажем, на резервное копирование 1 млн файлов требуется 6 часов, а на 10 млн — уже несколько дней. Обработчики файловых доступов просто не успевают открывать и закрывать такое количество файлов, чтобы зарезервировать их. С ростом числа запросов к файлам увеличивается общее время на резервное копирование.

В этом случае также нужны другие подходы. Для файлов чаще используется блочный бэкап. Диск приводится в консистентное состояние и считывается поблочно, без открытия файлов, но с возможностью их восстановления из резервной копии с помощью, например, Veritas FlashBackup. Плюс выручают те же snapshots, которые делаются на СХД. Так бэкап занимает несколько минут, а чуть позже СРК может скопировать на себя полученный образ СХД и уже в офлайне передать эти данные во вторичное хранилище. Наши заказчики часто используют синтез полной резервной копии из инкрементальных — NetBackup Accelerator. При этом срок создания полной резервной копии файловых ресурсов сокращается до времени инкрементального бэкапа. Эта технология поддерживается не только для файловых серверов Windows, Unix, Linux, но и сетевых хранилищ на базе оборудования NetApp и Dell EMC.

Использование all-flash серьезно уменьшает любые окна резервного копирования. У себя в компании «Инфосистемы Джет» мы поменяли гибридные и обычные массивы на all-flash даже для систем, которые не требуют особой производительности. Традиционно считается, что эта технология предназначена для критически важных данных, а для прочих используются диски подешевле. Но мы пошли по новому пути и получили «3 в 1» — и дедупликацию, и высокие скорости, и сокращение окна резервного копирования от 2 до 10 раз. Раньше бэкап почтовых баз данных мог длиться сутки, а теперь он укладывается в 2-4 часа.

Чтобы переход на all-flash не был дорогим, лучше покупать хранилище с хорошей дедупликацией, желательно с минимальным влиянием на производительность. Это позволит сжимать и дедуплицировать первичные данные с коэффициентами от 2,5 до 7. Поэтому даже если all-flash дороже обычных дисков, все равно есть эффект экономии — получается хранить больше данных и требуется меньше «железа».

***

Хочешь покоя — готовься к бою. Это выражение лучше всего описывает стратегию построения системы резервного копирования в условиях растущих данных. Даже если эта проблема не актуальна сейчас, лучше позаботится о ней заранее — тогда есть шанс не столкнуться со многими сложностями, описанными выше.

Построение СХД и СРК предполагает комплексный подход с применением множества технологий от разных производителей. В своей практике мы часто используем решения Veritas, которые обеспечивают надежные хранение и резервирование. Плюс они дают возможность заложить в ИТ-систему готовность к будущим изменениям, связанным с ростом данных.