llmdocsсправочник разработчика

Бэкапы: правило 3-2-1

Материал из llmdocs — справочник разработчика
Портал: Git, CI/CD, DevOps
Бэкапы: правило 3-2-1
Формула3 копии, 2 типа носителей, 1 копия вне площадки
Автор формулировкиПитер Крог (The DAM Book, фотографы)
Расширения3-2-1-1-0 (одна неизменяемая/офлайн копия, 0 ошибок при проверке)
Ключевые метрикиRPO (допустимая потеря данных), RTO (время восстановления)
Инструментыrestic, BorgBackup, Kopia, rclone, pgBackRest, Veeam
Главная угроза сегоднявымогатели, шифрующие и сами бэкапы

Правило 3-2-1 — простая и общепринятая формула резервного копирования: храните 3 копии данных, на 2 разных типах носителей, причём 1 копия должна находиться вне основной площадки.[1][2] Его сформулировал фотограф Питер Крог в книге о хранении цифровых архивов, а затем правило стало стандартной рекомендацией и для домашних пользователей, и для компаний. Смысл в том, чтобы ни одна единичная беда — отказ диска, пожар, кража, ошибка администратора или вирус-вымогатель — не уничтожила все копии сразу.

Разбор формулы

  • Три копии — рабочие данные плюс две резервные. Вероятность одновременной потери трёх независимых копий ничтожна.
  • Два типа носителей — например, диск сервера и облачное хранилище, или NAS и внешний диск. Однотипные носители из одной партии часто выходят из строя похожим образом и в одно время.
  • Одна копия вне площадки — в другом здании, городе или облаке. Пожар, затопление или изъятие оборудования не затронут её.

Современная версия 3-2-1-1-0 добавляет: ещё одна копия должна быть неизменяемой (immutable) или отключённой от сети (air-gapped), и ноль ошибок при проверке восстановления. Первое — ответ на вымогателей, которые сначала находят и удаляют резервные копии, а затем шифруют основные данные.[4]

Что не является бэкапом

Механизм Почему не бэкап
RAID защищает от отказа диска, но не от удаления файла или шифрования — изменения мгновенно попадают на все диски
Синхронизация (Dropbox, rsync --delete) удалённый или испорченный файл тут же удаляется или портится и в копии
Снимки (snapshots) на том же томе спасают от ошибок, но погибают вместе с массивом
Репликация базы данных DROP TABLE реплицируется на все узлы за доли секунды

Бэкап — это независимая копия с историей версий, из которой можно восстановить состояние на определённый момент в прошлом.

RPO и RTO

Перед выбором схемы определяют две величины:[3]

  • RPO (Recovery Point Objective) — сколько данных допустимо потерять. Ночной бэкап означает RPO до 24 часов; для базы с журналом транзакций — минуты или секунды.
  • RTO (Recovery Time Objective) — за сколько нужно восстановиться. Скачать 5 ТБ из облачного «холодного» хранилища может занять сутки.

Разные данные требуют разных значений: база заказов — минуты, архив логов — дни.

Практика

Файлы и серверы. Инструменты с дедупликацией и шифрованием на стороне клиента — restic, BorgBackup, Kopia — хранят много версий почти без лишнего места и пишут в локальный каталог, по SSH или в S3-совместимое хранилище.[5]

restic -r s3:https://s3.example.com/backups init
restic -r s3:https://s3.example.com/backups backup /etc /srv/data --exclude-caches
restic -r s3:https://s3.example.com/backups forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune
restic -r s3:https://s3.example.com/backups check --read-data-subset=5%
restic -r s3:https://s3.example.com/backups restore latest --target /tmp/restore-test

Запуск — по расписанию через cron или таймеры systemd, с оповещением о неудаче (см. Мониторинг и алертинг): тихо сломавшийся бэкап — классический сценарий катастрофы.

Базы данных. Копировать файлы работающей PostgreSQL нельзя — получится несогласованный снимок. Используют логические дампы (pg_dump) для небольших баз и физические бэкапы с архивом журнала WAL (pgBackRest, WAL-G) — они позволяют восстановить базу на любую секунду (point-in-time recovery).[6]

Неизменяемость. Object Lock в S3-совместимых хранилищах, режим «только добавление» (append-only) у Borg и restic через rest-server, отдельные учётные данные: сервер может записывать новые копии, но не удалять старые. Права на удаление — только у отдельной, хорошо защищённой учётной записи (см. Принцип наименьших привилегий).

Шифрование. Копия вне площадки должна быть зашифрована, а ключ — храниться отдельно от неё и от основного сервера. Потерянный ключ означает потерянный бэкап.

Главное — проверка восстановления

Резервная копия, которую ни разу не восстанавливали, — это надежда, а не бэкап. Регулярно:

  1. Восстанавливайте случайные файлы и целые системы на тестовый стенд.
  2. Проверяйте целостность хранилища (restic check, borg check).
  3. Засекайте время полного восстановления и сравнивайте с RTO.
  4. Записывайте процедуру восстановления так, чтобы её мог выполнить другой человек — в стрессовой ситуации и без доступа к упавшей системе.

См. также

Источники

  1. US-CERT — Data Backup Options (2012)
  2. Backblaze — The 3-2-1 Backup Strategy
  3. NIST SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems
  4. CISA — #StopRansomware Guide
  5. restic Documentation
  6. PostgreSQL Docs — Backup and Restore
Категории: