UPDATE! Теперь это серия статей по теме RTO/RPO
Список статей:
Часть 1: http://www.veskin.ru/2010/10/rto-rpo.html
Часть 2: http://www.veskin.ru/2017/03/rto-rpo-2.html
Часть 3: http://www.veskin.ru/2017/04/rto-rpo-3.html
Часть 4: http://www.veskin.ru/2017/04/rto-rpo-4.html
Часть 5: http://www.veskin.ru/2017/09/rto-rpo-5.html
Решил статью про одно написать, а углубился в другое... :)
Публикую в качестве ликбеза.
Отмечу, что значения RTO и RPO - это экстремумы - максимальные значения. Т.е. сколько нам максимум времени нам бизнес позволяет на простой, или сколько максимум данных (по времени) мы можем потерять.
Пример. RPO = 1 сутки. Значит копированием производим, по-старинке, раз в день (ночью). Если у нас резервное копирование запускается в 1:00, а у нас произошел сбой в 0:59, то мы и потеряли как раз сутки. Если сбой произошел сразу по успешному завершению резервного копирования - то вы ничего не потеряли.
В идеале оба значения нужно привести к нулю. Тогда система превратиться в неваляшку и будет восстанавливаться в момент сбоя с сохранением всех данных.
Но, как вы понимаете, это утопия. В реальной жизни эти два фактора объединяются с третьим немаловажным - финансовым. И стоимость решения будет расти экспоненциально при попытке приблизить значения RTO и RPO к нулю.
Продолжение...
При разработки технических решений по защите данных и сервисов бизнес-задач предприятия обычно оперируют двумя основными понятиями:
- время восстановления (recovery time objective (RTO)) - допустимое время простоя сервиса в случае сбоя.
- точка возврата (recovery point objective (RPO)) - допустимый объем возможных потерь данных в случае сбоя.
Если вы, допустим, социальная сеть, то простой пару часов - плохо: люди уже начнут смотреть на конкурентов - но еще не критично - тут свою роль играет раскрутка ресурса, и насколько подсажены на этот ресурс пользователи. (RTO)
Но если вы банк, и потеряете данные по платежам... вы можете попрощаться со своим бизнесом - и финансовый и репутационный риски его похоронят со свистом гильотины. (RPO)
RPO и RTO - не просто какие-то абстракции, они имеют совершенно конкретные значения. А чтобы легче было ими вместе оперировать, их приводят к одной шкале - временно́й.
Точка RPO - это время создание последней резервной копии, на момент которой вы можете вернуться в случае сбоя. RTO - время, которое необходимо потратить на восстановление (например, извлечь данные из резервной копии и запустить сервис, предоставляющий эти данные).
Точка RPO - это время создание последней резервной копии, на момент которой вы можете вернуться в случае сбоя. RTO - время, которое необходимо потратить на восстановление (например, извлечь данные из резервной копии и запустить сервис, предоставляющий эти данные).
Отмечу, что значения RTO и RPO - это экстремумы - максимальные значения. Т.е. сколько нам максимум времени нам бизнес позволяет на простой, или сколько максимум данных (по времени) мы можем потерять.
Пример. RPO = 1 сутки. Значит копированием производим, по-старинке, раз в день (ночью). Если у нас резервное копирование запускается в 1:00, а у нас произошел сбой в 0:59, то мы и потеряли как раз сутки. Если сбой произошел сразу по успешному завершению резервного копирования - то вы ничего не потеряли.
Важно! Для RPO, если бизнес поставил значение, резервное копирование должно производится не реже этого значения!То же касается и RTO. Если указано значение, а вы восстановили доступность сервиса/данных раньше - хорошо, соблюли бизнес-требование. Если потратили больше - не хорошо.
В идеале оба значения нужно привести к нулю. Тогда система превратиться в неваляшку и будет восстанавливаться в момент сбоя с сохранением всех данных.
Но, как вы понимаете, это утопия. В реальной жизни эти два фактора объединяются с третьим немаловажным - финансовым. И стоимость решения будет расти экспоненциально при попытке приблизить значения RTO и RPO к нулю.
Продолжение...
