Резервное копирование

Обычно 2 цели:

  • восстановление после аппаратного сбоя
  • восстановление какой-то версии в прошлом после программного сбоя или изменений данных людьми

Есть 2 основные метрики:

  • RPO (Recovery Point Objective) – кол-во времени от последней копии до аварии (сколько данных потеряно может быть). Например, мы можем потерять 20 часов данных. RPO=20ч
  • RTO (Recovery Time Objective) – кол-во времени от аварии до восстановления работы (сколько по времени займет восстановление с последней копии). Например, мы должны восстановиться за час после аварии. RTO=1ч

Копии бывают:

  • полные (содержат все данные)
  • инкрементальные (содержат изменение данных с момента предыдущей копии) – менее надежны, но экономят место

Часть копий может храниться сутки, другая неделю, третья “всегда”.

Обычно нужно копии хранить в различных физических местах для большей сохранности.

Отдельно нужно озаботится невозможностью изменить уже созданные копии, т.к. иначе вирус или хакер могут их испортить. Обычно это означает запись на сменные носители (компакт-диски, ленты). Можно еще шифровать и загружать в облако из-под аккаунта с минимальными правами.

Крайне важно время от времени тестировать восстановление из резервной копии. Может оказаться, что, например, файл бекапа пустой или битый. Или что что-то поменялось в программе и нужно разрабатывать и документировать новую процедуру восстановления, т.к. старая уже не работает.

Обычно выстраивается расписание копий, например:

  • копии делаются каждый час
  • первая полная копия в сутках, остальные инкрементальные
  • копии по умолчанию живут сутки, полная копия пн живет неделю, копия от 1-ого числа месяца живет год, а копия от первого числа года живет без ограничения
  • ежемесячные и ежегодные копии дополнительно отправляются в облако
  • каждая ежемесячная копия проверяется на восстановление

Обычно для каждой информационной системы нужно отдельно определять и прописывать все эти детали.