Бэкап. Резервное копирование. В современном мире - это краеугольный камень любой информационной системы. Без него невозможно построить "ту самую систему". Точнее, конечно же, можно, но чем сложнее система - тем сложнее будет ее (или ее часть) восстановить в случае сбоя (а он, сбой, будет обязательно. Рано или поздно). Резервное копирование (правильно настроенное) позволит минимизировать риск потери информации и восстановить ее полностью или обеспечит приемлемый для бизнеса процент потери.
Обычно, в начале проектирования резервного копирования для любой информационной системы применяется два основных параметра: RTO и RPO.
RTO (Recovery Time Objective - точка восстановления) - показатель, определяющий время с момента наступления катастрофического события до момента полного восстановления работоспособности системы. Иными словами - сколько допустимо времени с момента неработоспособности ресурса ДО момента полной восстановления работы системы.
RPO (Recovery Point Objective - время восстановления) - показатель, определяющий допустимое количество потери информации с момента наступления инцидента.
Иными словами, RTO - это через какое время система должна продолжить полноценное функционирование, а RPO - сколько данных допустимо потерять.
"Зачем же нужны все эти параметры ? Настроил бэкап и все!" - многие системные администраторы так и делают, просто настраивают резервное копирование и все. Но у бизнеса может быть иное мнение. (Причем, я не говорю про типы бэкапов: полный, дифференциальный, инкрементальный и пр. Это - не для бизнеса. Это - для системных администраторов)
Пример.
Допустим, вы делаете резервную копию (например, базы данных MS SQL) каждый день, в 20:00. И вы знаете, что на момент 20:00 каждого дня у вас есть полноценная резервная копия. В этой схеме RPO - 24 часа (максимальный срок). И системные администраторы говорят, что для полноценного восстановления им хватит 3 часов. Т.е. RTO - 3 часа.
Но вдруг - информационная система - "падает". Не работает. Аут. И предположим, "упала" она в 15:00 (т.е. данные потеряны с 20:00 предыдущего дня до 15:00 текущего). Системные администраторы начинают пытаться восстановить из резервной копии, а не получается. По различным причинам. Сервера нет, нет компетенций, резервная копия не читается, системный администратор в отпуске, болеет и пр. А сервис - не работает. А значит - не приносит деньги (а цель любого бизнеса - получение прибыли). В данном случае - параметр RTO (время восстановления сервиса) начинает стремится к бесконечности. Но предположим, что администраторы восстановили все за 5 часов (а не за положенные 3 часа). А начальство заявляет, что все плохо и бизнес потерял набор данных (и деньги), которые были сделаны 5 часов назад, т.е. в 10:00. А резервная копия только от 20:00 предыдущего дня... И "плюсом" - еще и упустили важного клиента, пока восстанавливали сервис...
В вышеописанном примере было полное несоответствие заявленным требованиям RTO и RPO. RTO был заявлен 3 часа, на практике - 5. RPO был заявлен 24 часа, но для бизнеса этого оказалось недостаточно.
Грамотные системные администраторы настраивая резервное копирование всегда запрашивают у бизнеса эти параметры: "Сколько допустимо время простоя (RTO) и сколько допустимо потерять данных (RPO) ?" Исходя из полученных данных - проектируют систему (в нескольких вариантах реализации) и согласовывают бюджет с руководством. Если руководство согласно и с планом, и выделяет бюджет - наступает фаза реализации. Если нет - то начинают искать компромиссные варианты (дешевле, больше время RTO и пр).
И еще немаловажный момент. Системным администраторам необходимо обеспечить выполнение вышеупомянутых параметров. Не просто делать резервное копирование с соответствии с политикой RPO и иметь "железо" для RTO, но и периодически проверять как резервное копирование, так и площадку для восстановления. Ведь принимать прописанные врачом лекарства без периодического контроля анализов - очень глупо, бессмысленно, а иногда и опасно. Так и в резервном копировании - глупо просто иметь резервную копию, если ее нельзя применить по назначению.
В моей личной практике такое было в одной из региональных компаний. Системный администратор настроил резервное копирование пользовательских данных (в том числе, клиентскую базу данных) и просто проверял, что процесс бэкапа выполняется. И даже согласовал параметры RTO и RPO с руководством. Но в тот момент, когда "произошел крах" - он не смог восстановить данные из резервных копий. Просто потому, что он никогда этого не делал и не проверял. И в процессе восстановления - обнулил библиотеку резервных копий... Результат - потеря клиентской базы, неработоспособность офиса компании на 2 дня....
Резервное копирование и его грамотная настройка - это латинская фраза "Si vis pacem, para bellum", примененная в рамках каждой отдельной Компании. Это очень важный элемент работы любого бизнес-процесса. От резервного копирования, в том числе, зависит и прибыль организации, и зарплата сотрудников. И определять параметры RPO и RTO должен не системный администратор (просто потому что так захотелось), а те люди, которые РАБОТАЮТ с данными и которым эти данные НУЖНЫ. Системный администратор должен обеспечить выполнение резервного копирования по указанным параметрам.
Ведь если процесс резервного копирования не налажен или работает неверно - то возможны серьезные потери. Как репутационные, так и финансовые.
И напоследок, некоторое количество смешных (и не только) фраз и картинок, которые очень точно показывают необходимость резервного копирования (бэкапа):
"Состояние любого бэкапа неизвестно, пока его не попробуют восстановить" (Бэкап Шредингера)
"ИТ-шники делятся на две категории: которые НЕ делают бэкап и которые УЖЕ делают бэкап"
"Лучше пусть бэкап будет и не пригодится, чем его не будет, когда он нужен"
