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

> Базовое правило резервного копирования — три копии данных, на двух разных носителях, одна из них в другом месте; плюс практика проверки восстановления.

Источник: https://llmdocs.ru/wiki/backup-3-2-1/ · обновлено 2026-11-09 · лицензия CC BY-SA 4.0

- **Формула**: 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](https://llmdocs.ru/wiki/ssh.md) или в S3-совместимое хранилище.[5]

```bash
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](https://llmdocs.ru/wiki/cron-systemd-timers.md), с оповещением о неудаче (см. [Мониторинг и алертинг](https://llmdocs.ru/wiki/monitoring-alerting.md)): тихо сломавшийся бэкап — классический сценарий катастрофы.

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

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

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

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

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

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

## См. также

- [rsync](https://llmdocs.ru/wiki/rsync.md)
- [Управление секретами](https://llmdocs.ru/wiki/secrets-management.md)
- [Репликация](https://llmdocs.ru/wiki/replication.md)
- [Infrastructure as Code](https://llmdocs.ru/wiki/infrastructure-as-code.md)

## Источники

1. [US-CERT — Data Backup Options (2012)](https://www.cisa.gov/sites/default/files/publications/data_backup_options.pdf)
2. [Backblaze — The 3-2-1 Backup Strategy](https://www.backblaze.com/blog/the-3-2-1-backup-strategy/)
3. [NIST SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems](https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final)
4. [CISA — #StopRansomware Guide](https://www.cisa.gov/stopransomware/ransomware-guide)
5. [restic Documentation](https://restic.readthedocs.io/)
6. [PostgreSQL Docs — Backup and Restore](https://www.postgresql.org/docs/current/backup.html)