Существует два понятия, которые настолько часто произносятся вместе, что их начинают воспринимать как нечто единое. В мире информационных технологий и обеспечения непрерывности бизнеса — это неудивительно. Мы поговорим о таких понятиях, как РПО, Recovery Point Objective и РТО, Disaster Recovery.
Почему-то многие руководители используют эти аббревиатуры как синонимы. Но на самом деле RPO и РТО отвечают на два совершенно разных вопроса. И путать их – это все равно, что перепутать тормоз и руль в автомобиле. У них разные функции, и цена ошибки несопоставима.
RPO – это Recovery Point Objective, то есть целевая точка восстановления, которую предлагает компания IT-Solutions. Этот показатель будет отвечать на вопрос, какой именно объем данных может потерять компания при сбоях. Оно определяется минутами, часами. И в зависимости от того, насколько часто будет произведено резервное копирование, определяется и само RPO. Нулевое RPO будет значить, что потеряна не может быть ни одна операция. И это самый дорогой и сложный режим защиты. поскольку здесь используются современные технологии и решения, которые обеспечивают максимальную непрерывность бизнеса.
РТО – это Disaster Recovery, время восстановления после отказа. То есть здесь вы получаете ответ на вопрос, как долго система может восстанавливаться после сбоев или ошибок. Если ваше РТО составляет 2 часа, то значит, что вы должны восстановить свою работу в течение 2 часов. А РТО равно 0, это значит то, что система должна быть доступна всегда, без перерывов. Это требует кластеризации и архитектуры высокой доступности.
Почему опасно путать эти два понятия? Потому что стратегии достижения маленького RPO и маленького РТО кардинально различаются по технологиям и стоимости. РТО может быть коротким и равняться нескольким минутам. Но если РТО будет занимать сутки и более, то это может не соответствовать потребностям самой компании.
Классическая ошибка бизнеса и даже некоторых IT-директоров – это то, что они попросту формулируют фразу «нам нужно быстрое восстановление» и «нам нужна минимальная потеря данных». Они вовсе не разделяют понятие целевой точки восстановления и времени восстановления после отказа, а смешивают их в одну расплывчатую фразу. В результате будет спроектирована система, которая либо неоправданно дорога, либо, что еще хуже, оказывается несбалансированной, которая прекрасно защищает от потери данных, но не дает никаких гарантий по времени подъема сервиса. Истинная беда наступает в момент реальной аварии, когда выясняется, что ожидания руководства и возможности инфраструктуры расходятся кардинально.
