Бэкап 3-2-1 на практике

Правило 3-2-1: держи 3 копии данных, на 2 разных носителях, и 1 — вне дома (offsite). Это защищает от сбоя диска, шифровальщика, кражи, потопа и «случайно удалил». Команды инструмента restic сверены с офиц. restic.readthedocs.io.

🧭 Картина целиком

Что получишь на выходе: настроенный, автоматический и — главное — ПРОВЕРЕННЫЙ бэкап важных данных. Не «вроде где-то копировал», а система, из которой ты точно умеешь восстановиться.

Почему именно 3-2-1. Одна копия — это ноль копий: умер диск, поймал шифровальщик, украли ноут — и всё. Правило простыми словами:

• 3 копии — оригинал + два бэкапа (одна поломка не уничтожит всё).
• 2 разных носителя — напр. внутренний диск + внешний/NAS (один тип отказа не заберёт обе).
• 1 offsite — одна копия физически в другом месте (облако или диск «у мамы»): пожар/кража/потоп дома не достанут её.

Золотое правило: бэкап, который ни разу не восстанавливали, — это НЕ бэкап, а надежда. Половина гайда — про проверку восстановления.

Путь — 5 шагов: решить что и куда → сделать локальную копию (restic) → отправить offsite-копию → автоматизировать → проверить восстановление (регулярно).

💡 Почему restic: открытый, бесплатный, кроссплатформенный; шифрует данные (offsite-копия в облаке безопасна), дедуплицирует (второй бэкап занимает мало — хранит только изменения), умеет слать в облако (S3, Backblaze B2 и др.).

Шаг 1. Решить, ЧТО и КУДА бэкапить

Что делаем: определяем ценные данные и три места хранения.

1. Что: документы, фото, проекты/код (если не весь в git), базы, конфиги, переписка. НЕ нужно: то, что легко скачать заново (ОС, программы, node_modules, кэш).
2. Куда (план 3-2-1):
   • Копия 1 — оригинал на рабочем компьютере.
   • Копия 2 — локальный бэкап на ДРУГОЙ носитель (внешний диск / NAS / второй диск).
   • Копия 3 — offsite: облачное хранилище (Backblaze B2 / S3-совместимое) или диск, который физически живёт в другом месте.

Как понять, что ОК: у тебя есть список «что бэкапим» и три конкретных места (два носителя + одно offsite). Прикинул объём — хватит ли места в каждом.

Частые ошибки:

• Бэкапишь «всё подряд», включая ОС и кэши → раздувание и медленно. Бэкапь данные, а не то, что переустанавливается.
• «Вторая копия» на том же физическом диске (другой раздел) → это НЕ второй носитель. Умрёт диск — умрут обе. Нужен реально отдельный носитель.
• Обе копии дома → нет offsite. Пожар/кража заберут всё. Одна копия обязана быть вне дома.

Шаг 2. Локальная копия через restic (на внешний диск)

Что делаем: ставим restic, создаём зашифрованный репозиторий на внешнем носителе и делаем первый бэкап.

# установка: macOS — brew install restic; Ubuntu — sudo apt install restic;
# Windows — winget install restic.restic (или скачать с restic.net)

# создать репозиторий на внешнем диске (один раз). Придумай НАДЁЖНЫЙ пароль и сохрани его отдельно:
restic -r /Volumes/Backup/restic-repo init

# первый бэкап нужных папок:
restic -r /Volumes/Backup/restic-repo --verbose backup ~/Documents ~/Pictures ~/Projects

Как понять, что ОК: после init — сообщение, что репозиторий создан. После backup — строка вида snapshot abcd1234 saved. Проверь список копий:

restic -r /Volumes/Backup/restic-repo snapshots   # видно твой снапшот с датой и путями

Частые ошибки:

• Забыл пароль репозитория = данные не достать НИКОГДА. restic шифрует, восстановления пароля нет by design. Сохрани пароль в менеджере паролей СРАЗУ.
• Путь к диску неверный/диск не подключён → ошибка. На macOS внешние — в /Volumes/..., на Linux — точка монтирования, на Windows — буква диска.
• Бэкапишь сетевой/съёмный диск, которого нет на месте → бэкап молча не делается. Для автоматизации проверяй, что носитель подключён (см. Шаг 4).

Шаг 3. Offsite-копия (облако / другое место)

Что делаем: заводим третью копию вне дома. Так как restic шифрует — облако безопасно (провайдер видит только шифр).

# вариант «облако»: репозиторий restic прямо в S3-совместимом хранилище (напр. Backblaze B2).
# ключи доступа — в переменные окружения (не в команду!):
export AWS_ACCESS_KEY_ID=<ключ>
export AWS_SECRET_ACCESS_KEY=<секрет>
restic -r s3:s3.us-west-001.backblazeb2.com/мой-бакет init      # один раз
restic -r s3:s3.us-west-001.backblazeb2.com/мой-бакет backup ~/Documents ~/Pictures

Вариант «без облака»: тот же restic ... backup на ВТОРОЙ внешний диск, который ты хранишь не дома (на работе, у родных) и периодически привозишь обновить.

Как понять, что ОК: restic -r <облако> snapshots показывает снапшот в облачном репозитории; в панели облака виден занятый объём. Offsite-копия существует и обновляется.

Частые ошибки:

• Ключи доступа вписал прямо в команду/скрипт → они утекут в историю shell/в git. Только через переменные окружения или файл с правами 600.
• Перепутал endpoint/регион бакета → ошибка подключения. Сверь адрес S3 с панелью провайдера.
• Думаешь, что облачная синхронизация (Dropbox/iCloud) = бэкап. Это НЕ бэкап: удаление/шифровальщик синхронизируется в облако и затирает файлы там же. Нужен версионируемый бэкап (restic хранит историю снапшотов).

Шаг 4. Автоматизировать (чтобы не забывать)

Что делаем: ставим бэкап на расписание — ручной бэкап рано или поздно забросишь.

1. Собери короткий скрипт backup.sh: бэкап на диск + бэкап в облако + очистка старых копий.

#!/usr/bin/env bash
set -e
export RESTIC_PASSWORD_FILE=~/.restic-pass        # пароль в файле с правами 600, не в скрипте
restic -r /Volumes/Backup/restic-repo backup ~/Documents ~/Pictures ~/Projects
# оставить разумную глубину истории и удалить лишнее:
restic -r /Volumes/Backup/restic-repo forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

2. Поставь на расписание: cron (Linux/macOS, напр. ежедневно ночью) или launchd (macOS) / Планировщик заданий (Windows).

Как понять, что ОК: на следующий день restic snapshots показывает свежий снапшот с сегодняшней датой — расписание сработало само. Лог скрипта без ошибок.

Частые ошибки:

• Пароль/ключи прямо в скрипте → утечка. Используй RESTIC_PASSWORD_FILE и env-переменные, файл — chmod 600.
• forget без --prune → старые снапшоты «забыты», но место на диске не освобождается. --prune реально удаляет данные.
• Расписание есть, но носитель/сеть недоступны в момент запуска → тихий пропуск. Добавь в скрипт проверку и уведомление об ошибке (чтобы заметить, что бэкап не идёт).

Шаг 5. ПРОВЕРИТЬ восстановление (самое важное)

Что делаем: убеждаемся, что из бэкапа реально можно достать данные. Без этого шага всё предыдущее — иллюзия защиты.

# 1) проверить целостность репозитория (не побились ли данные):
restic -r /Volumes/Backup/restic-repo check

# 2) пробное ВОССТАНОВЛЕНИЕ в отдельную папку (НЕ поверх оригинала!):
restic -r /Volumes/Backup/restic-repo restore latest --target ~/restore-test

# 3) восстановить из облачной копии тоже — проверь, что offsite рабочий:
restic -r s3:s3.us-west-001.backblazeb2.com/мой-бакет restore latest --target ~/restore-test-cloud

Открой восстановленные файлы — фото открываются, документы целы, проект запускается.

Как понять, что ОК: check пишет, что всё в порядке («no errors were found»); в ~/restore-test лежат твои файлы и они открываются. Ты лично убедился, что восстановление работает — и из локальной, и из offsite-копии.

Частые ошибки:

• Никогда не проверял восстановление — классическая катастрофа: годами «бэкапил», а в час Х репозиторий битый/пароль забыт/копировались не те папки. Проверяй restore хотя бы раз в пару месяцев.
• Восстанавливаешь --target в ту же папку поверх оригинала → можешь затереть текущие файлы. Всегда восстанавливай в ОТДЕЛЬНУЮ папку и сверяй.
• Проверил только локальную копию, а offsite ни разу → в реальной беде (сгорел дом с диском) окажется, что облачная не настроена. Тестируй обе.

🧠 Для сеньора

• Политика хранения: forget --keep-daily/weekly/monthly/yearly + --prune по расписанию; продумай RPO (как много данных не жалко потерять → частота) и RTO (как быстро надо восстановиться → где держать «горячую» копию).
• Иммутабельность против шифровальщика: offsite в объектном хранилище с Object Lock / immutable-bucket или append-only ключом restic — чтобы вирус/злоумышленник с твоего хоста НЕ удалил бэкапы. Это закрывает главную дыру 3-2-1.
• Мониторинг и тревоги: алерт на провал/устаревание бэкапа (нет свежего снапшота N дней), healthcheck-пинг из скрипта; restic check --read-data-subset периодически читает часть данных, а не только структуру.
• Согласованность БД: не копируй «живые» файлы СУБД на ходу — снимай дамп (pg_dump/mysqldump) или снапшот ФС, иначе бэкап может быть нецелостным.
• Безопасность ключей: пароль repo и ключи S3 — в секрет-менеджере; для серверов — отдельная ограниченная учётка хранилища (append-only), не мастер-ключ.

⚠️ Предупреждения

• Пароль/ключ repo — единственный вход. Потерял = данные потеряны навсегда. restic шифрует без «забыли пароль». Сохрани пароль в менеджере паролей и продублируй в надёжном месте СРАЗУ при init.
• Синхронизация ≠ бэкап. Dropbox/iCloud/Google Drive мгновенно повторяют удаление и шифрование файлов в облаке. Нужен версионируемый бэкап с историей (restic), из которого можно взять состояние «на вчера».
• Шифровальщик метит и в бэкапы. Если бэкап-диск всегда подключён и доступен на запись — вирус зашифрует и его. Отключай носитель между бэкапами и/или делай offsite неизменяемым (immutable).
• Тест восстановления — не «когда-нибудь». Самая дорогая ошибка — узнать, что бэкап не работает, в момент, когда он уже нужен. Проверяй restore регулярно, до беды.

🆘 Промт-спасалка

Помоги настроить бэкап по правилу 3-2-1, объясняй по шагам.
ЧТО БЭКАПЛЮ: <документы / фото / код / базы — и примерный объём>.
ЧТО ЕСТЬ: <внешний диск? NAS? облако (какое)?>. МОЯ ОС: <macOS / Windows / Linux>.
Я ЗАСТРЯЛ: <restic не ставится / ошибка init/backup / не пойму, как сделать offsite / как автоматизировать>.

Что делать:
1) Помоги разложить мои данные по схеме 3-2-1 (2 носителя + 1 offsite) под то, что у меня есть.
2) Дай точные команды restic под мою ОС: init, backup, snapshots, расписание, forget+prune.
3) Обязательно — как проверить восстановление (check + restore в отдельную папку), локально и из offsite.
4) Предупреди про пароль репозитория (потеря = конец), про «синхронизация ≠ бэкап» и про защиту от шифровальщика.

💎 Глубина и ценность

• Спокойствие вместо страха. Потеря фото, проектов, документов — это боль, которую нельзя отменить. Настроенный 3-2-1 переводит «а вдруг сломается/украдут/зашифруют» из катастрофы в мелкую неприятность: восстановился и работаешь дальше.
• Защита не от одной угрозы, а от всех сразу. Три копии на двух носителях с одной offsite закрывают разом сбой диска, шифровальщик, кражу, пожар и собственную ошибку «удалил не то». Ни один отдельный инцидент не уносит всё.
• Проверка — то, что отличает реальный бэкап от иллюзии. Большинство «бэкапит» и теряет данные, потому что ни разу не восстанавливался. Привычка регулярно делать тестовый restore — и есть та зрелость, которая однажды спасёт годы твоей работы и памяти.