Comments 6
Тестирование необходимо, поскольку даже при проработанных планах всегда всплывет что-то неожиданное.
К примеру, восстановление работает как по маслу в пределах датацентра, а вот реплицированные бекап образы (по идее, идентичные) в резервном датацентре уже не восстанавливаются, выдавая ошибки, о которых что-нить внятное способен сказать только вендор софта и\или железа для бекапа.
И хорошо, если это всплывет на тесте, а не в реальной аварийной ситуации.
К примеру, восстановление работает как по маслу в пределах датацентра, а вот реплицированные бекап образы (по идее, идентичные) в резервном датацентре уже не восстанавливаются, выдавая ошибки, о которых что-нить внятное способен сказать только вендор софта и\или железа для бекапа.
И хорошо, если это всплывет на тесте, а не в реальной аварийной ситуации.
Планируя аварийное восстановление у наших клиентов, мы неоднократно задумывались о возможности резервного копирования данных в облако, но, увы, вынуждены были отказаться от этой идеи. Причина проста — крайне высокие операционные расходы. Для того, чтобы просто перелить за ночное окно хотя бы 300-400 Гбайт данных нужен канал Интернет со скоростью в 100 Мбит/с. А 300-400 Гбайт данных — это компания в 10-20 человек, которым 10 Мбит Интернета хватает для всего. Разница же в цене на канал Интернет позволяет арендовать офис в соседнем здании и докинуть туда оптический линк, либо же дотянуть линк до ближайшего дата-центра, что мы и делаем в большинстве случаев, когда это действительно необходимо.
Также надо понимать, что когда твоя локальная серверная «полыхнула огнем», (а по большому счету только в этом сценарии нам может потребоваться аварийное восстановление в другой локации), у компании уже куда больше проблем, чем только серверная ИТ-инфраструктура. И в такой ситуации даже героически восстановленные в облаке сервисы могут оказаться не востребованными в моменте. В общем случае, при планировании аварийного восстановления, надо не забывать, что его первоочередная цель — обеспечение непрерывности бизнеса компании и что в некоторых сценариях даже полностью работоспособное ИТ не сможет обеспечить полноценное функционирование бизнеса. Если перейти на булщитинг, то план аварийного восстановления ИТ-инфраструктуры должен соотносится с планом по обеспечению непрерывности бизнеса компании в целом.
Также надо понимать, что когда твоя локальная серверная «полыхнула огнем», (а по большому счету только в этом сценарии нам может потребоваться аварийное восстановление в другой локации), у компании уже куда больше проблем, чем только серверная ИТ-инфраструктура. И в такой ситуации даже героически восстановленные в облаке сервисы могут оказаться не востребованными в моменте. В общем случае, при планировании аварийного восстановления, надо не забывать, что его первоочередная цель — обеспечение непрерывности бизнеса компании и что в некоторых сценариях даже полностью работоспособное ИТ не сможет обеспечить полноценное функционирование бизнеса. Если перейти на булщитинг, то план аварийного восстановления ИТ-инфраструктуры должен соотносится с планом по обеспечению непрерывности бизнеса компании в целом.
В МСК так плохо с Интернетом? Разница в стоимости между 10 Мбит / с и 100 Мбит / с смешная. Во всяком случае в Киеве такой канал стоит около $10 / месяц, на целых 5 долларов дороже, чем канал в 10 мегабит :)
10 Мбит на 20 человек для всего? ну если ютьюб никто не включает и идет исключительно работа — то реально. Только вот такое нереально в реальности :)
10 Мбит на 20 человек для всего? ну если ютьюб никто не включает и идет исключительно работа — то реально. Только вот такое нереально в реальности :)
Вы, безусловно, демонстрируете хорошие познания касательно стоимости интернета для физических лиц. Для юридических лиц, если бы разница в цене между 10 Мбит и 100 была всего 5$, то тарифов на 10 Мбит просто бы не существовали, т.к. их никто бы не покупал.
Также вы не поняли мою основную мысль — даже 100 Мбит мало для нормального резервного копирования.
Также вы не поняли мою основную мысль — даже 100 Мбит мало для нормального резервного копирования.
Честно говоря, есть сомнение, что 300-400 ГБ данных генерируется/изменяется ежедневно. Может, нужно просто поискать другой инструмент для передачи этих данных?
Приведу личный пример — есть контейнер TrueCrypt на 600 ГБ. Он монтируется и данные внутри него изменяются ежедневно. Ночью контейнер размонтируется и запускается BTSync, который вычисляет какие блоки в этом контейнере изменились и передаёт на другую сторону только изменения. Обычно это всего-лишь несколько ГБ из 600.
Вся процедура, конечно, всё-равно занимает несколько часов, т.к. BTSync'у нужно сначала прохешировать все 600 ГБ на одной стороне, а потом те же 600 ГБ на другой, чтобы найти какие блоки изменились, но канал при этом не занят. Заняты только винты и частично CPU.
Приведу личный пример — есть контейнер TrueCrypt на 600 ГБ. Он монтируется и данные внутри него изменяются ежедневно. Ночью контейнер размонтируется и запускается BTSync, который вычисляет какие блоки в этом контейнере изменились и передаёт на другую сторону только изменения. Обычно это всего-лишь несколько ГБ из 600.
Вся процедура, конечно, всё-равно занимает несколько часов, т.к. BTSync'у нужно сначала прохешировать все 600 ГБ на одной стороне, а потом те же 600 ГБ на другой, чтобы найти какие блоки изменились, но канал при этом не занят. Заняты только винты и частично CPU.
300-400 Гб данных конечно же не изменяются ежедневно в компаниях на 10-20 человек. Если вести речь о дифференциальных копиях, то для небольших компаний это вопрос нескольких гигабайт, ну и плюс гигов 20-30 баз данных, чьи полные копии надо создавать ежедневно.
Возможность сделать полную копию всех данных за одну ночь нужна на случай сбоя в работе системы резервного копирования. К примеру, если в выходные отключили свет во всем здании или прервался канал Интернет или возникла ошибка в работе ПО для резервного копирования, то в начале недели у вас может не оказаться полных резервных копий. В этом случае вам нужна возможность за ночь с понедельника на вторник сделать полные копии.
По сути, возможность пересоздать полные копии за одно окно резервного копирования — это мера обеспечения непрерывности резервного копирования, которая крайне важна при планировании аварийного восстановления. В целом, вопрос планирования аварийного восстановления и в частности форс-мажорного планирования — это более многогранная тема и приведенное в статье выше решение помогает в этом очень отдаленно. Свою практику планирования аварийного восстановления я изложил ранее в целом цикле статей на хабре.
Возможность сделать полную копию всех данных за одну ночь нужна на случай сбоя в работе системы резервного копирования. К примеру, если в выходные отключили свет во всем здании или прервался канал Интернет или возникла ошибка в работе ПО для резервного копирования, то в начале недели у вас может не оказаться полных резервных копий. В этом случае вам нужна возможность за ночь с понедельника на вторник сделать полные копии.
По сути, возможность пересоздать полные копии за одно окно резервного копирования — это мера обеспечения непрерывности резервного копирования, которая крайне важна при планировании аварийного восстановления. В целом, вопрос планирования аварийного восстановления и в частности форс-мажорного планирования — это более многогранная тема и приведенное в статье выше решение помогает в этом очень отдаленно. Свою практику планирования аварийного восстановления я изложил ранее в целом цикле статей на хабре.
Sign up to leave a comment.
Что стоит помнить при планировании бюджета на аварийное восстановление?