Политика резервного копирования
Цель — уметь восстановить сервис после потери узла, ошибки обновления или повреждения данных. Резервная копия, из которой ни разу не восстанавливались, считается непроверенной.
Схема 3-2-1
- 3 копии данных: рабочая и две резервные.
- 2 разных носителя: диск узла и внешнее хранилище.
- 1 копия вне основной площадки.
Расписание и хранение
| Тип | Частота | Хранение | Где |
|---|---|---|---|
| Инкрементальная | каждые 6 часов | 7 дней | внешнее хранилище |
| Полная | раз в неделю | 4 недели | внешнее хранилище |
| Архивная | раз в месяц | 12 месяцев | холодное хранилище |
| Конфигурации | при каждом изменении | вечно | git-репозиторий |
Проверка восстановления
Раз в квартал поднимается тестовый стенд и на нём восстанавливается случайный набор данных. Результат фиксируется: что восстанавливали, сколько заняло, что сломалось. Если восстановление не уложилось в целевое время — политика пересматривается.
# пример проверки целостности архива
restic snapshots --last 3
restic check --read-data-subset=10%
Важно. Ключи шифрования хранятся отдельно от резервных копий. Потеря
ключа приравнивается к потере копии, поэтому ключи дублируются в двух независимых местах.