В этой статье я бы хотел подробно остановиться на двух магических показателях, с которыми необходимо определиться до того, как планировать резервное копирование и восстановление не только баз данных Microsoft SQL Server, но и любых других хранилищ информации. Не понимая и не зная этих двух чисел, вы рискуете неправильно оценить риски для бизнеса и составить неверный план восстановления.

Итак, RPO (recovery point objective) это максимальный период времени, за который могут быть потеряны данные в результате инцидента. Например, у нас имеется информационная система и RPO для нее мы определили в 1 час. Это значит, что, если вдруг происходит авария, мы готовы к тому, что систему удастся восстановить, но в ней будут потеряны данные не более, чем за последний час. Количество потерянных данных может быть меньше, если нам повезет, но не более 1 часа. Этот показатель говорит нам о том, как часто мы должны делать резервные копии нашей системы, и какие технологии применять, чтобы удержать этот показатель. Может ли он быть ноль? Теоретически да, но на практике организовать это очень сложно. Это можно организовать, только, если запись идет как минимум в 2 разных хранилища. Использование AlwaysOn Availability Groups или Database Mirroring вам не поможет, т.к. эти технологии не спасут от случайного удаления таблицы.

RTO (recovery time objective) это промежуток времени, в течение которого система может оставаться недоступной в случае аварии. Например, в центре обработки данных произошел пожар, но мы хотим, чтобы система была снова доступна для работы через 2 часа. Это и есть наш RTO. Мы должны планировать так, чтобы за этот промежуток восстановить работоспособность информационной системы на резервном оборудовании или площадке. Это можно реализовать с помощью различных технологий отказоустойчивости или же простым восстановлением из резервных копий на другой сервер. В любом случае мы должны обеспечить этот показатель при инциденте.

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