Думаю, никто не будет спорить, что иметь надежную инфраструктуру резервного копирования и резервного копирования — это всегда хорошо.
Число природных и техногенных катастроф в мире растет с каждым годом, а ущерб от них измеряется сотнями миллиардов долларов.
Хотя вероятность пострадать от крупного инцидента не так уж и велика, с локальными неприятностями, такими как отключение электроэнергии, наводнение или пожар в серверной комнате, мы сталкиваемся довольно часто.
Всякое бывает — иногда обиженные сотрудники мстят бизнесу, иногда оборудование конфискуют правоохранительные органы, иногда Роскомнадзор случайно блокирует иностранные IP-адреса, а однажды в локальную серверную нашего клиента въехал грузовик — прямо через стену со стороны улица.
Всем ли компаниям нужен горячий резерв, позволяющий быстро переключиться на вторую площадку? Не совсем.
Резервное копирование в реальном времени актуально, если бизнес-процессы, критически важные для непрерывного обслуживания клиентов, сильно зависят от программного обеспечения, работающего на центральных серверах.
В этом случае потери имиджа пугают, а стоимость простоя достаточно легко посчитать, поэтому деньги обычно находятся в дата-центре.
Более того, такие ИТ-системы зачастую изначально проектируются в катастрофоустойчивом варианте.
Если недоступность ИТ-систем приводит лишь к потере рабочего времени сотрудников и гипотетически может привести к штрафам за несвоевременную сдачу отчетности или плохое обслуживание тайных покупателей, то бизнес неохотно одобряет затраты на горячий резерв.
Сложность в том, что если вы придете к системному интегратору с задачей резервного копирования, то, в соответствии с накопленным опытом, вам, скорее всего, предложат проверенный временем подход с анализом бизнес-рисков, разработкой DRP и аппаратным решением с функция аппаратной синхронизации.
Помимо высокой стоимости, у таких решений есть еще один недостаток – их сложно реализовать без существенной модернизации основного сайта, который, как правило, никто не хочет лишний раз трогать.
Тем не менее, для действительно критичных бизнес-систем это оправданные риски и затраты, потому что иначе невозможно, а что, если системы недостаточно критичны для «зрелого» и красивого проекта? Можно, конечно, смириться и ничего не делать, а если что-то случится, опустить руки и ударить по делу.
Вы можете нанять интегратора, чтобы он просчитал резервный дата-центр, сделал пилот, прикинул бюджет, презентовал решение бизнесу, получил ответ «денег пока нет» и отложил проект до лучших времен.
Это, конечно, не спасет компанию от простоя, но в случае форс-мажорных обстоятельств сложно предъявить претензии ИТ-отделу, потому что «ну мы вам предложили», а новых знаний о рынке DR-решений не будет. быть лишним.
Такие варианты тоже имеют право на жизнь, но бизнес может не пережить потерю данных, и тогда ему придется искать новую работу.
Вам не обязательно инвестировать в полноценный резервный дата-центр, но вы можете облегчить себе жизнь в будущем, настроив вторичное (или даже первичное) резервное копирование данных в облако.
Сегодня услуги BaaS (резервное копирование как услуга) предлагаются многими поставщиками услуг и основаны на широком спектре программного обеспечения.
Если вы используете какое-либо популярное решение для резервного копирования внутри компании, вы, вероятно, сможете найти аналогичный сервис с удобной встроенной интеграцией с вашим текущим программным обеспечением.
Либо, как вариант, можно арендовать у провайдера недорогое S3-совместимое хранилище и хранить там резервные копии — работа по протоколу S3 сегодня поддерживается решениями многих вендоров.
Плюсы такого подхода очевидны — за разумные деньги вы получаете страховку от риска остаться без физического доступа к данным и возможность восстановления в том же облаке в случае необходимости.
Насколько быстро вы сможете восстановить свои системы из резервной копии, зависит от предыдущих усилий, затраченных на тестирование, наличия предоплаченного пула ресурсов для восстановления и процедуры аварийного восстановления, написанной совместно с поставщиком услуг.
Однако даже если у вас есть только голая резервная копия, вы все равно запустите свои бизнес-системы в облаке, пусть и не очень быстро, и поддержка BaaS-провайдера вам в этом поможет. 
Что, если ущерб от простоя ИТ-систем очевиден для всех, но не настолько велик, чтобы оправдать траты на полноценный проект аварийного восстановления с анализом бизнес-рисков и оборудованием для второй площадки?
И здесь на помощь снова приходят поставщики услуг, предлагающие облачную инфраструктуру, уже распределенную по нескольким географическим точкам.
Все, что вам нужно сделать, это переместить ваши серверы в облако, а поставщик услуг позаботится обо всем остальном.
Если вы по каким-то причинам не хотите полностью переходить в облако (например, если вы недавно потратили деньги на собственное оборудование и серверную комнату), то подойдет вариант программной синхронизации в облаке для нескольких особо ценных серверов.
У облачного провайдера вы можете арендовать вычислительные ресурсы и хранилище, доступное программное обеспечение для синхронизации и предоставить развернутое решение аварийного восстановления для поддержки.
Это достаточно удобный вариант, и вам не придется платить за обследование ваших ИТ-систем, подготовку технического проекта и другие этапы полноценного проекта – вы можете ограничиться недорогой стандартной настройкой.
Использование облачных сервисов избавляет от необходимости прогнозировать количество необходимых лицензий для программного обеспечения аварийного восстановления и ежегодно платить за продление поддержки поставщика для сохранения доступа к обновлениям.
В случае затруднений можно быстро получить техническую помощь на русском языке от поддержки провайдера (вместо психологической помощи на английском, как это часто бывает у вендоров).
Ведь хостер знает свой сервис, так как он сам его настроил и обслуживает, а вот производителю ПО придется мучительно разбираться по логам и переписке, что и как у вас настроено внутри.
В целом аренда облачного сервиса по сравнению с покупкой оборудования для проекта имеет довольно существенное преимущество, даже если не сравнивать стоимость владения.
Это низкие затраты, если что-то пойдет не так.
Если не взлетит, то просто отказываемся от услуг хостера и все, но от своего железа отказаться нельзя.
Подобные истории на самом деле знакомы многим ИТ-руководителям.
Пару лет назад мы проводили исследование готовности облака в инжиниринговой компании, и одной из предпосылок перехода в облако была медленная работа бизнес-систем.
Все данные приложений хранились на хранилище начального уровня, и его производительности просто не хватало.
Однако в ходе аудита мы обнаружили, что у клиента имеется отличное хранилище среднего класса от авторитетного вендора, выполняющее роль файлообменника.
В ответ на наш молчаливый вопрос «почемуЭ» заказчик рассказал историю о потере данных из-за редкого бага и нежелании лишний раз рисковать, хотя вендор уже давно исправил баг.
Собственно, в практике ActiveCloud было немало ситуаций, когда купленное оборудование не могло быть использовано по первоначальному назначению или вводилось в строй с задержкой в несколько месяцев.
Стоит ли брать на себя эти риски, когда можно переложить их на провайдера? Это интересный вопрос.
ActiveCloud предлагает своим клиентам оба служба резервного копирования в облачное хранилище на базе программного обеспечения Veeam, и служба горячего бронирования в облаке на базе программного обеспечения Carbonite (ранее Double-Take).
Сервисы позволяют периодически выполнять резервное копирование или синхронизацию оборудования и виртуальных серверов на всех популярных гипервизорах с облаком в режиме реального времени.
Услуги предоставляются по модели аренды и включают в себя все необходимое: облачные ресурсы, необходимое программное обеспечение, круглосуточную поддержку и быструю стартовую настройку.
Если у вас похожая проблема и вы хотите ее обсудить, пишите [email protected] .
Теги: #информационная безопасность #ИТ-инфраструктура #облачные сервисы #Резервное копирование #Облачные вычисления #облачные серверы #защита данных #облачные провайдеры #activecloud #резервный дата-центр
-
Как Сделать Правильный Выбор Профессии
19 Oct, 24 -
Дилемма Выбора Языка
19 Oct, 24
