Резервное копирование есть или уже есть? О чём стоит задуматься руководителям бизнеса?!

Администраторы бывают двух типов:

у кого есть резервные копии и у кого они УЖЕ есть (с).

 

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

 

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

 

Если подробности и примеры вам не интересны — можете смело переходить к послесловию.

ВСТУПЛЕНИЕ

 

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

 

На рынке представлено значительное количество поставщиков ПО для резервного копирования. Рассматривать каждого из них в отдельности — лишено смысла в рамках данной статьи так как обобщенно их можно разделить на два вида:

  • Для малого и среднего бизнеса (mid-range);
  • Для крупного бизнеса (enterprise).

 

Ключевое отличие между этими двумя категориями, как правило, сводится к возможностям масштабирования. Любой продукт резервного копирования можно отнести к одной из этих категорий.

 

Системы резервного копирования для малого и среднего бизнеса – это, как правило, ALL-In-One решения. Это очень удобные и доступные решения потому, что все компоненты можно разместить на одном сервере. Они замечательно выполняют свою роль, успешно демонстрируются в пилотных проектах и зачастую обладая крайне дружественным интерфейсом — не испытывают внутреннего отторжения со стороны эксплуатирующего персонала.

 

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

 

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

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

  • Резервное копирование предназначено для восстановления информационных систем;
  • Архивное хранение данных нацелено на долговременное хранение данных.

 

Решения, покрывающие все аспекты управления и хранения данными — называются «Data Management Software» и как правило состоят из совокупности продуктов одного поставщика. Сейчас мы поговорим именно о резервном копировании.

 

ПРОБЛЕМАТИКА

 

От резервных копий зависит выживание бизнеса!(с)

 

Резервное копирование зачастую недооценено руководителями бизнес-подразделений которые прямо или косвенно задействованы в утверждении бюджетов или согласовании закупок.

 

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

 

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

 

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

 

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

 

Напомним, что в 2017-м году в Украине была масштабная вирусная атака Petya.А. Вектор распространения шел через вполне легитимное программное обеспечение, которому доверяли. Антивирусы доверяли исполняемым файлам, работающим от привилегированного пользователя. Межсетевые экраны разрешали сетевое взаимодействие. Срабатывания систем защиты классифицировались как ложно-положительные. Никто не верил в то, что гром грянет со стороны коммерческой компании с огромной клиентской базой.

 

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

 

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

 

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

 

Вирус Petya.А наглядно продемонстрировал всем, что системы резервного копирования являются синонимом выживания бизнеса. Правильное резервное копирование — это не продукт — это процесс с использованием продукта. К сожалению, этот момент постоянно ускользает из внимания руководителей бизнеса. На изменение восприятия какого-то продукта, как важной части процесса - требуется время.

Возникли вопросы?

 

Свяжитесь с нами для консультации

РЕКОМЕНДАЦИИ

 

Постараемся немного рассказать о том, как правильно выбирать продукты резервного копирования.

 

Ключевое - при выборе продуктов, необходимо руководствоваться двумя ключевыми параметрами:

  • RTO -  recovery time objective - это параметр, определяющий временное окно, за которое система должна быть восстановлена.  Это может быть час, сутки или неопределенное время, в зависимости от специфики бизнеса и критичности информационной системы. Параметр определяется для каждой системы в рамках заказчика.
  • RPO – recovery point objective - это параметр, определяющий временное окно, за которое допустима потеря данных. Например, час, сутки, неделя и т. д. Параметр также определяется для каждой системы в рамках заказчика.

 

Два этих параметра лежат в основе проектирования любой системы резервного копирования. Они определяют допустимую потерю данных и допустимый простой бизнеса или сервисов с которыми взаимодействуют ваши клиенты.

 

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

 

В случае с RTO - для наглядности приведём несколько живых примеров , когда при проектировании системы резервного копирования не были учтены требования RTO/RPO и рассмотрим первопричины проблем.

 

Компания спроектировала и внедрила в свою ИТ-инфраструктуру систему резервного копирования без учёта требований RTO. Всё успешно работало, данные накапливались и узких мест (bottleneck) в системе никто не наблюдал. Системой резервного копирования успешно пользовались, при необходимости восстанавливали отдельно взятые системы.

 

После инцидента с Petya.А - пришлось одновременно восстанавливать много разных информационных систем. Количество серверов, используемых для резервного копирования оказалась узким местом (bottleneck) этого решения.  Восстановление систем выполнялось успешно, но происходило не с такой скоростью, как того требовал бизнес. Естественно, что представителям бизнеса хотелось, чтобы всё восстановилось в течение нескольких часов, максимум суток, но система резервного копирования восстанавливала данные на протяжении нескольких дней упираясь в дисковые системы и пропускную способность сети. Одно дело, когда вы в течении суток забираете несколько терабайт информации (измененных данных), другое дело — когда вам надо прокачать сотни терабайт, которые накапливаются неделями.

 

Игнорирование требований RTO, привело к приостановке бизнес-процессов и к существенным финансовым потерям.

 

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

 

В случае с RPO — это параметр, который косвенно влияет на количество трудозатрат, которые придется возложить на плечи конечных пользователей систем. В каких-то случаях перепроверить корректность данных после восстановления и внести в системы недостающие данные, например проведя сверку складской документации — это вопрос нескольких часов или дней, если объем изменений небольшой. Сверить и «подбить» итоги банковских транзакций по десяткам и сотням тысяч клиентов банка — это принципиально другие трудозатраты.

 

К техническим проблемам следует отнести производительность. Даже для сетевых инженеров, понимание того, что 10Гбит/с сеть дает всего 3,2ТБ/ч реальных данных было «неожиданным» открытием. Для сравнения 1Гбит/с (наиболее популярный сейчас тип сетевого подключения) — предоставляет примерно 300ГБ/ч. Да, мы не ошиблись: для восстановления 1ТБ данных по 1Гбит/с сети вам потребуется около 3 часов, при условии что вы не упретесь в производительность сервера, который восстанавливаете.  Те кто не уперся в сеть — упирались в системы хранения данных. Их обычно покупают исходя из объема. Редкие заказчики ценят производительность.

 

Бытует миф, что для резервного копирования не надо иметь быстрых систем хранения данных. Однако, если у вас 10Гбит/с сеть и вы ожидаете получить свои 3,2ТБ/ч — ваша система хранения должна отдавать порядка 1ГБ/с (гигабайта в секунду) операций чтения в условиях смешанного ввода-вывода. Для систем 5,7,10-и летней давности, которые по остаточному принципу отдают в СРК — это очень высокие значения.

 

Теперь представим себе, что у вас в организации, скажем 60ТБ критичных данных, которые вы ожидаете восстановить в течении 6 часов. Реальное восстановление займет больше времени, т.к. потребуется участие персонала, где-то возникнут трудности, которые мы сейчас упустим. Исходя из постановки задачи — вам надо прокачивать через свою сеть 10ТБ/ч — это около 40Гбит/с. Дисковые системы СРК должны вычитывать более 4ГБ/с. Системы хранения данных продуктивных систем — должны успевать принимать этот поток данных. Вы уверены, что текущая архитектура вашей сети с учетом маршрутизаторов, межсетевых экранов и просто исходя из топологии способна пропустить такие объемы данных? Эта проблематика зачастую не изучается и упускается, когда вам продают коробку, а не решение.

 

К организационным проблемам следует отнести тот факт, что мнение о критичности систем с точки зрения бизнеса и ИТ-персонала зачастую не совпадает. Бизнесу важно показать внешним заказчикам что компания успешно функционирует (ради сохранения имиджа), в то время как ИТ-специалисты восстанавливали системы, которые не заметны для внешнего наблюдателя и критичны только для части внутренних подразделений. Действует принцип "восстанавливаем то, за что нас могут спросить в первую очередь."

 

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

 

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

 

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

 

Очень важно иметь на сменных (off-line) носителях экземпляры программного обеспечения критичного для бизнеса и техническую документацию (инструкции, паспорта систем, ключи шифрования и т.п.). Иметь хотя бы общий план действий, в котором чётко сказано: что должны делать сотрудники, как меняются их полномочия, как будут приниматься решения, кто и как должен  проинформировать партнёров, способы коммуникации со СМИ.

 

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

 

ПОСЛЕСЛОВИЕ

 

Не смотря на наше стремление сократить статью — она вылилась в значительный объем и потребовала немало вашего времени. Надеемся что оно было потрачено не зря.

 

Повторим самые главные тезисы, которые мы хотели до вас донести:

  • От процесса резервного копирования зависит выживание бизнеса;
  • Резервное копирование — это не программный продукт или подсистема — это процесс;
  • Данные и информационные системы должны быть классифицированы и для них должны быть определены значения RTO. RPO;
  • На случай инцидента — бюрократические процедуры должны быть упрощены. Персонал должен знать о своих полномочиях. Время — деньги;
  • Тестовые восстановления, тренировки и учения — это не трата времени и денег. Персонал должен понимать процедуры, знать и иметь все технические средства, необходимые для восстановления работоспособности вверенных им систем. Знать кто и чем может помочь;
  • Слаженные действия персонала, минимизация фактора неожиданности, понимание последовательности действий — сокращают время, необходимо на возвращение бизнеса в рабочее русло, что является синонимом минимизации финансовых потерь.

 

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

 

Компания «ИТ Специалист» произведёт для вашего бизнеса правильную оценку ИТ-инфраструктуры: оценит стек технологий, проведет аудит, не забудет о сетевом взаимодействии и создаст все предпосылки для создания и внедрения системы резервного копирования, которая вас не подведет.

 

Связывайтесь с нашими консультантами прямо сейчас.

 

Резервное копирование есть или уже есть? О чём стоит задуматься руководителям бизнеса?! обновлено: Май 22, 2018 автором: Dmytro Monakov