Что стоит помнить при планировании бюджета на аварийное восстановление?

    Когда в последний раз падал ваш сервер? Как это отразилось на работе вашей организации? В 2013 г. институтом Ponemon, который занимается независимыми исследованиями в сфере информационной безопасности, был проведен опрос, показавший, что 91% организаций столкнулись с проблемой простоя в работе ЦОД. И хотя эта статистика не так ужасна сама по себе, по подсчетам экспертов 30% пострадавших так и не смогли восстановить работу, а это уже серьёзный повод для тревоги.

    Руководители предприятий всегда думают, что все эти ужасы произойдут с кем-то другим, но только не с их организацией, хотя так рассуждают не только они. Большинству людей при слове «бедствие» на ум приходят ураганы и землетрясения, но оно, на самом деле, не всегда носит природный характер. Бедствием может обернуться человеческая ошибка или кибер-атака. Именно поэтому всегда стоит иметь «план Б» для защиты своих критически важных приложений и данных. Также важно знать, что пятиминутный простой – это не просто потеря возможной в это время прибыли. Это возможность потери репутации бренда и лояльности клиентов.

    image

    О чём стоит вспомнить, когда Вы или Ваше руководство решите сэкономить на мерах для восстановления?

    Аварийное восстановление экономически эффективно


    По исследованию института Ponemon, среднему предприятию требуется в среднем 2 дня на восстановление работы. Средний годовой убыток на компанию (похоже на среднюю температуру по больнице, но всё же) составляет $366363. Есть также и скрытые убытки – это упущенная выгода и потеря репутации бренда. Например, если на 8 часов «падает» система резервирования билетов в крупной авиакомпании, в следующий раз клиенты, потерявшие кучу времени на борьбу с накладками, дважды подумают прежде, чем забронировать в ней рейс.

    Организации, которые прибегают к помощи провайдеров аварийного-восстановления-как-услуги (disaster-recovery-as-a-service, DRaaS), оценили экономию как ключевое преимущество использования публичного облака для аварийного восстановления. Таковы результаты исследования Aberdeen Group – исследовательской компании, которая позволяет бизнес-структурам понять последствия и результаты от внедрения технологий. Не стоит бояться необходимости слишком больших капитальных вложений в повышение надёжности, можно просто подписать договор с провайдером DRaaS.

    Затраты колеблются от $60 до $120 в месяц за один сервер в зависимости от количества серверов, необходимых для резервирования данных организации, и от размеров этих данных, а также зависят от таких факторов, как контрольная точка восстановления (recovery-point objective, RPO), контрольное время восстановления (recovery-time objective, RTO), и т.д.

    image

    Восстановление легко организовать


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

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

    Снижается потеря данных


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

    Представьте, что вы руководите кампанией в Delray Beach во Флориде. Это здорово… пока не случился ураган. Такое произошло с компанией Fleet Lease Disposal в октябре 2005 после урагана Wilma, который разрушил офис компании и один из ее главных дата-центров. К счастью компания быстро оправилась от потерь и спокойно работала следующие 4 месяца из резервного дата-центра в Нью Джерси. Спустя 4 года компания узнала, что на дополнительном сайте также не хватило соответствующего оборудования и пропускной способности для резервного восстановления.

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

    Восстановление проходит быстро и эффективно


    По данным опроса, проведенного Aberdeen Group, компании, которые используют DRaaS, быстрее восстанавливают свою работу – это второе преимущество использования облачных сервисов.

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

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

    Тестирование 1, 2, 3…


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

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

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

    Задача тестирования в том, чтобы убедиться в доступности и восстанавливаемости всех систем, которые необходимы в работе. Ведь когда сбой происходит на самом деле. Думать об этом уже поздно.
    ua-hosting.company
    Хостинг-провайдер: серверы в NL до 300 Гбит/с

    Comments 6

      0
      Тестирование необходимо, поскольку даже при проработанных планах всегда всплывет что-то неожиданное.
      К примеру, восстановление работает как по маслу в пределах датацентра, а вот реплицированные бекап образы (по идее, идентичные) в резервном датацентре уже не восстанавливаются, выдавая ошибки, о которых что-нить внятное способен сказать только вендор софта и\или железа для бекапа.
      И хорошо, если это всплывет на тесте, а не в реальной аварийной ситуации.
        +1
        Планируя аварийное восстановление у наших клиентов, мы неоднократно задумывались о возможности резервного копирования данных в облако, но, увы, вынуждены были отказаться от этой идеи. Причина проста — крайне высокие операционные расходы. Для того, чтобы просто перелить за ночное окно хотя бы 300-400 Гбайт данных нужен канал Интернет со скоростью в 100 Мбит/с. А 300-400 Гбайт данных — это компания в 10-20 человек, которым 10 Мбит Интернета хватает для всего. Разница же в цене на канал Интернет позволяет арендовать офис в соседнем здании и докинуть туда оптический линк, либо же дотянуть линк до ближайшего дата-центра, что мы и делаем в большинстве случаев, когда это действительно необходимо.

        Также надо понимать, что когда твоя локальная серверная «полыхнула огнем», (а по большому счету только в этом сценарии нам может потребоваться аварийное восстановление в другой локации), у компании уже куда больше проблем, чем только серверная ИТ-инфраструктура. И в такой ситуации даже героически восстановленные в облаке сервисы могут оказаться не востребованными в моменте. В общем случае, при планировании аварийного восстановления, надо не забывать, что его первоочередная цель — обеспечение непрерывности бизнеса компании и что в некоторых сценариях даже полностью работоспособное ИТ не сможет обеспечить полноценное функционирование бизнеса. Если перейти на булщитинг, то план аварийного восстановления ИТ-инфраструктуры должен соотносится с планом по обеспечению непрерывности бизнеса компании в целом.
          0
          В МСК так плохо с Интернетом? Разница в стоимости между 10 Мбит / с и 100 Мбит / с смешная. Во всяком случае в Киеве такой канал стоит около $10 / месяц, на целых 5 долларов дороже, чем канал в 10 мегабит :)

          10 Мбит на 20 человек для всего? ну если ютьюб никто не включает и идет исключительно работа — то реально. Только вот такое нереально в реальности :)
            0
            Вы, безусловно, демонстрируете хорошие познания касательно стоимости интернета для физических лиц. Для юридических лиц, если бы разница в цене между 10 Мбит и 100 была всего 5$, то тарифов на 10 Мбит просто бы не существовали, т.к. их никто бы не покупал.

            Также вы не поняли мою основную мысль — даже 100 Мбит мало для нормального резервного копирования.
              0
              Честно говоря, есть сомнение, что 300-400 ГБ данных генерируется/изменяется ежедневно. Может, нужно просто поискать другой инструмент для передачи этих данных?

              Приведу личный пример — есть контейнер TrueCrypt на 600 ГБ. Он монтируется и данные внутри него изменяются ежедневно. Ночью контейнер размонтируется и запускается BTSync, который вычисляет какие блоки в этом контейнере изменились и передаёт на другую сторону только изменения. Обычно это всего-лишь несколько ГБ из 600.
              Вся процедура, конечно, всё-равно занимает несколько часов, т.к. BTSync'у нужно сначала прохешировать все 600 ГБ на одной стороне, а потом те же 600 ГБ на другой, чтобы найти какие блоки изменились, но канал при этом не занят. Заняты только винты и частично CPU.
                0
                300-400 Гб данных конечно же не изменяются ежедневно в компаниях на 10-20 человек. Если вести речь о дифференциальных копиях, то для небольших компаний это вопрос нескольких гигабайт, ну и плюс гигов 20-30 баз данных, чьи полные копии надо создавать ежедневно.

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

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

        Only users with full accounts can post comments. Log in, please.