Прямой ответ
Стратегия 3-2-1: три копии данных, на двух разных типах носителей, одна копия вне площадки (offsite — облако/другой город). Но главное правило, которое отличает бэкап от иллюзии: бэкап существует только если проверено восстановление — непроверенная копия является бэкапом ровно настолько, насколько повезёт. Для разработчика практический набор: база — логический дамп (pg_dump/sqlite .backup), а не копирование файлов на живом сервере; файлы (загрузки, конфиги, terraform-state) — инкрементальные инструменты с дедупликацией и шифрованием (restic/borg) в offsite-хранилище; расписание — таймерами/systemd с алертами на непрогон; и ежеквартальный учебный restore на временную машину с замером времени. Бэкапируется не только «продукт»: state инфраструктуры, секреты (в зашифрованном виде), dotfiles и конфигурации — такие же данные.
Что копировать: инвентаризация важного
Первый шаг — список, а не инструмент. Для типового проекта: данные приложения (PostgreSQL — дампы; SQLite — файлы через .backup; redis — обычно не бэкапят, это кеш, но решения осознанные), загрузки пользователей (медиа-каталоги/S3 — у облачных бакетов версионирование вместо «бэкапа», но и оно настраивается), конфигурация как код (репозитории — уже бэкап, если remote не один; серверные конфиги вне git — в бэкап), terraform state (state — сердце инфраструктуры, его потеря дороже потери БД по трудозатратам восстановления), секреты (vault-хранилища имеют свой экспорт; файлы .env — в зашифрованный бэкап), TLS-ключи и сертификаты (продление настроено — но приватные ключи стоит иметь). Правило отсечения: бэкапится то, что нельзя пересоздать автоматически за приемлемое время; кеш, артефакты сборки и node_modules — не данные.
База данных: дамп против файловой копии
pg_dump — логический дамп: консистентный снимок на момент запуска (транзакционный), переносим между версиями и машинами, сжимается — стандарт для баз до сотен гигабайт. Ключевые практики: дамп с флагом формата custom (-Fc) — сжатие и выборочное восстановление таблиц (pg_restore -t); отдельный глобальный дамп (pg_dumpall --globals-only) — роли и табличные пространства не входят в dump отдельной базы (потеря ролей — классическая дыра «всё восстановилось, кроме прав»); на живой базе дамп не блокирует запись, но на больших базах идёт долго — окно планируйте. Файловое копирование каталога данных «на горячую» — битые копии (исключение — снапшоты ФС/LVM на уровне ниже); для баз больше нескольких сотен ГБ — физический бэкап (pgBackRest, бармены) с WAL-архивацией и PITR (point-in-time recovery — откат на «за минуту до аварии»). Локальная разработка в бэкапах не нуждается — она воспроизводится миграциями и сидами (настройка PostgreSQL).
Файлы: restic/borg и offsite
Копирование файлов «в лоб» (rsync на второй диск) — уровень «две копии»; полноценный инструмент даёт дедупликацию (изменённый гигабайтный файл стоит как дифф), инкрементальность, шифрование на стороне хранилища (offsite-провайдер не читает ваши данные) и снапшот-историю («файл как три дня назад» — от случайного удаления и шифровальщиков). restic/borg: репозиторий в S3/B2/на удалённый сервер, restic backup /var/www/uploads --exclude-caches, политика хранения --keep-daily 7 --keep-weekly 4 --keep-monthly 12 (prune чистит старое), пароль репозитория — в секретах и… в бэкапе (потеря пароля restic = потеря бэкапов — мета-ловушка). Offsite-копия — по определению не на той же машине/диске: «бэкап на второй раздел того же диска» не переживает ни смерть диска, ни rm -rf с root-правами, ни пожар в серверной.
Проверка восстановлением: единственный настоящий тест
План drills: раз в квартал (для личных проектов — раз в полгода) взять случайный свежий бэкап и восстановить на временную машину: поднять PostgreSQL, pg_restore, подключить приложение (или хотя бы прогнать миграционные проверки/подсчёт строк в ключевых таблицах), для файлов — выборочная распаковка и сравнение контрольных сумм. Фиксируйте две цифры: RPO (сколько данных максимально теряется — «последний бэкап в 03:00» = до 24 часов потерь) и RTO (сколько занимает восстановление — «поднять сервис с нуля» = полдня); если цифры не устраивают — меняется частота бэкапов/инструменты (WAL-архивация снижает RPO до минут). Автоматизированный минимум между drills: ночная проверка, что бэкап за сегодня существует, больше прошлого по размеру на правдоподобную величину, и восстанавливается заголовок дампа (pg_restore -l без ошибок) — скрипт на bash с алертом (надёжные скрипты).
Практический сценарий: бэкап небольшого прода
Сервер с FastAPI-приложением, PostgreSQL 40 ГБ и uploads 100 ГБ. Ночной таймер systemd (03:00): pg_dump -Fc app > /backup/tmp/app-$(date).dump → restic backup дампа, uploads, /etc, terraform-state → restic forget --keep-daily 7 --keep-weekly 8 --keep-monthly 12 --prune → проверка pg_restore -l + отправка метрики «бэкап ОК, размер, длительность» в мониторинг (алерты); при любой ошибке — алерт немедленно (бэкап, который «молча не делался месяц», находится только алертом на непрогон). Offsite — S3-совместимое хранилище в другом регионе, репозиторий restic зашифрован. Раз в квартал — учебный restore на чистую VM с terraform-поднятой инфраструктурой: цель — сервис работает на вчерашних данных, время уложилось в четыре часа. И отдельная копия критичного — выгрузка дампа раз в неделю в третье место (правило «3» из 3-2-1 не для галочки: потеря провайдера бэкапов — реальное событие).
FAQ
Бэкап в облако — это offsite или доверие провайдеру? И то и другое: offsite-свойство выполняется, но «бэкап в том же облаке, что и прод» не переживает компрометацию облачного аккаунта — отсюда второе offsite-место и шифрование своими ключами (провайдер хранит, но не читает).
Снапшоты диска VM заменяют бэкапы? Частично: снапшот — быстрая точка отката внутри платформы, но он не offsite, не версионируется независимо и часто привязан к живому диску. Пара «снапшоты для быстрых откатов + логические бэкапы offsite» — рабочая комбинация, а не взаимоисключающие варианты.
Как бэкапить секреты, не создавая дыру? Шифрованием до копирования (restic шифрует сам; .env-файлы — в зашифрованном репозитории бэкапа) и хранением пароля/master-ключа отдельно от бэкапов (менеджер паролей, у владельца). Бэкап секретов в открытом виде в общем бакете — частая и дорогостоящая ошибка.
Нужны ли бэкапы «как код»? Да: скрипты бэкапа, расписание и политики — в git рядом с инфраструктурой (ansible-роль/systemd-таймер), чтобы восстановление среды включало и механизм бэкапов; «настроено руками на сервере» не переживает потерю самого сервера.
Источники: документация PostgreSQL (backup), restic и borgbackup — ссылки в шапке.