Обычно 2 цели:
- восстановление после аппаратного сбоя
- восстановление какой-то версии в прошлом после программного сбоя или изменений данных людьми
Есть 2 основные метрики:
- RPO (Recovery Point Objective) – кол-во времени от последней копии до аварии (сколько данных потеряно может быть). Например, мы можем потерять 20 часов данных. RPO=20ч
- RTO (Recovery Time Objective) – кол-во времени от аварии до восстановления работы (сколько по времени займет восстановление с последней копии). Например, мы должны восстановиться за час после аварии. RTO=1ч
Копии бывают:
- полные (содержат все данные)
- инкрементальные (содержат изменение данных с момента предыдущей копии) – менее надежны, но экономят место
Часть копий может храниться сутки, другая неделю, третья “всегда”.
Обычно нужно копии хранить в различных физических местах для большей сохранности.
Отдельно нужно озаботится невозможностью изменить уже созданные копии, т.к. иначе вирус или хакер могут их испортить. Обычно это означает запись на сменные носители (компакт-диски, ленты). Можно еще шифровать и загружать в облако из-под аккаунта с минимальными правами.
Крайне важно время от времени тестировать восстановление из резервной копии. Может оказаться, что, например, файл бекапа пустой или битый. Или что что-то поменялось в программе и нужно разрабатывать и документировать новую процедуру восстановления, т.к. старая уже не работает.
Обычно выстраивается расписание копий, например:
- копии делаются каждый час
- первая полная копия в сутках, остальные инкрементальные
- копии по умолчанию живут сутки, полная копия пн живет неделю, копия от 1-ого числа месяца живет год, а копия от первого числа года живет без ограничения
- ежемесячные и ежегодные копии дополнительно отправляются в облако
- каждая ежемесячная копия проверяется на восстановление
Обычно для каждой информационной системы нужно отдельно определять и прописывать все эти детали.