Бэкап перед каждым изменением: минута, которая спасает вечер

MAATRIX

Вы правите конфиг nginx, разворачиваете миграцию базы или обновляете пакет — и что-то идёт не так. Первый вопрос в этот момент не «что сломалось», а «к чему откатываться». Если ответ — «к ночному бэкапу, ему восемь часов» — вы теряете не только время на восстановление, но и все изменения за эти восемь часов. Точечный бэкап прямо перед правкой стоит одну команду и тридцать секунд, а разница между ним и плановым бэкапом — это разница между «откатились и пошли дальше» и «восстанавливаем сервер и разбираемся, что потеряли».

Плановый бэкап и точечный снапшот решают разные задачи

Плановый бэкап по расписанию — это защита от катастроф: сгорел диск, слетела ОС, сервер физически недоступен. Он работает по календарю, а не по факту риска: cron запустил его в 3:00, и неважно, что происходит на сервере в 15:00, когда вы садитесь править конфиг. К моменту, когда что-то пошло не так, этому бэкапу может быть от нескольких минут до суток — и чаще ближе к максимуму, потому что проблемы обычно случаются не сразу после полуночи.

Точечный бэкап перед изменением решает другую задачу: гарантировать откат ровно к состоянию непосредственно перед правкой. Не «где-то в течение суток», а секунда в секунду. Это не замена плановому бэкапу и не резервирование в полном смысле — это расходный материал для одной конкретной операции, который вы, скорее всего, удалите через час, если всё прошло гладко.

Разница особенно заметна на конкретных числах. Если плановый бэкап базы делается раз в сутки в 3:00, а вы редактируете схему в 16:00, то откат к плановому бэкапу отбросит вас на 13 часов — то есть удалит все транзакции, заказы, регистрации пользователей за это время. Точечный дамп конкретной таблицы перед ALTER TABLE стоит несколько секунд и возвращает вас точно туда, где вы были минуту назад, без потери всего остального дня.

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

Конфигурация: git-коммит или copy перед правкой — не полагайтесь на память

Самая частая рискованная операция на сервере — это правка конфига: nginx, systemd unit, docker-compose.yml, файл переменных окружения. И самая частая ошибка — понадеяться, что «я помню, как было», хотя через пять минут после третьей правки подряд уже не помните.

Если каталог конфигурации под git (это разумно для nginx sites-available, конфигов приложений, docker-compose файлов), перед правкой достаточно проверить, что нет незакоммиченных изменений, и сделать коммит-точку:

cd /etc/nginx
git status
git add -A && git commit -m "checkpoint: перед правкой upstream для api.example.com"

Откат в этом случае — git diff покажет, что именно поменялось, а git checkout -- sites-available/api.conf вернёт файл целиком. Если правка сломала конфиг настолько, что nginx не стартует, разбор типичных причин такой поломки есть в статье про nginx, который не запускается после правки конфига — но откат из git избавляет от необходимости искать причину под давлением, когда сайт уже лежит.

Если каталог не под git — а на практике многие серверы годами живут без версионирования конфигов — минимальная альтернатива это copy с таймстампом прямо перед правкой:

cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak-$(date +%Y%m%d-%H%M%S)

Или для целого каталога:

tar czf /root/pre-change-backups/nginx-$(date +%Y%m%d-%H%M%S).tar.gz /etc/nginx/

Это грубее git — нет диффа, нет истории, только точка возврата целиком. Но тридцать секунд перед правкой кратно дешевле, чем восстанавливать рабочий конфиг по памяти в 23:00, когда сайт уже недоступен. Привычка «копировать конфиги с тестового стенда прямо в прод без ревизии» — отдельная частая причина инцидентов, разбор такого случая есть в статье скопировали конфиг с тестового и получили режим отладки.

База данных: точечный дамп конкретной таблицы, а не всей базы

Полный дамп базы перед каждой мелкой правкой — избыточен и медленен, если база большая. Но перед изменением схемы, массовым UPDATE или DELETE вам чаще всего нужен не весь дамп, а дамп конкретной таблицы или даже конкретной выборки строк.

Для PostgreSQL — дамп одной таблицы перед ALTER или миграцией:

pg_dump -U app_user -d app_db -t orders -F c -f /root/pre-change-backups/orders-$(date +%Y%m%d-%H%M%S).dump

Формат -F c (custom) сжат и восстанавливается выборочно через pg_restore, что удобно, если нужно вернуть только эту таблицу, не трогая остальную базу:

pg_restore -U app_user -d app_db -t orders --clean /root/pre-change-backups/orders-20260828-1602.dump

Для MySQL/MariaDB — аналогично, дамп конкретной таблицы:

mysqldump -u app_user -p app_db orders > /root/pre-change-backups/orders-$(date +%Y%m%d-%H%M%S).sql

Если правка — это UPDATE или DELETE с условием, ещё точнее и быстрее сохранить только те строки, которые собираетесь менять, через SELECT ... INTO для отдельной таблицы-снапшота:

CREATE TABLE orders_snapshot_20260828 AS SELECT * FROM orders WHERE status = 'pending';

Это работает за секунды даже на многомиллионной таблице при узком условии выборки, а откат — это INSERT ... SELECT обратно или прямая замена строк по id. Полный дамп многогигабайтной базы ради правки одной таблицы — лишние минуты ожидания и лишняя нагрузка на диск, когда вы просто хотите проверить гипотезу. При этом полный дамп «на всякий случай» перед изменением, которое трогает много таблиц сразу (например, миграция с добавлением внешних ключей), оправдан — подойдёт обычный pg_dump -F c app_db без -t. Техника снятия консистентного дампа на живой базе без блокировки описана в статье бэкап баз данных без остановки — она про плановый процесс, но приём тот же самый.

Если правка — DDL-миграция (ALTER TABLE, добавление индекса), важно помнить, что дамп таблицы не откатывает саму миграцию мгновенно: сначала нужно откатить схему (через down-миграцию инструмента вроде Flyway или Liquibase, если он есть), и только затем восстановить данные, если они пострадали. Дамп перед миграцией — это подстраховка на случай, если сама миграция что-то испортит в данных, а не замена продуманного плана отката. Как выглядит такой план — в статье план отката миграции.

Файлы и volume: снимок состояния без полного архива

Для файловых изменений — обновление приложения, правка кода на проде (даже если так делать не стоит — но иногда приходится хотфиксить), замена статики — точечный бэкап чаще всего сводится к одной из трёх техник, в зависимости от масштаба изменения.

Один файл или несколько файлов — просто копия с таймстампом рядом:

cp -a /var/www/app/config/settings.py /var/www/app/config/settings.py.$(date +%s)

Каталог приложения целиком перед деплоем — архив с исключением тяжёлых директорий, которые и так есть в git или можно пересобрать:

tar czf /root/pre-change-backups/app-$(date +%Y%m%d-%H%M%S).tar.gz \
  --exclude='node_modules' --exclude='.git' --exclude='vendor' \
  /var/www/app/

Docker volume перед изменением, которое трогает данные контейнера (обновление образа с миграцией данных, смена формата хранения) — снимок volume через временный контейнер:

docker run --rm -v app_data:/data -v /root/pre-change-backups:/backup \
  alpine tar czf /backup/app_data-$(date +%Y%m%d-%H%M%S).tar.gz -C /data .

Частые ошибки здесь разобраны в статье про бэкап docker volume на сервере — например, попытка архивировать volume без остановки контейнера, когда внутри активно пишущая база, даёт несогласованный снимок.

Отдельно стоит сказать про снапшоты гипервизора (LVM, ZFS, снапшот виртуальной машины у провайдера) — они выглядят как идеальный точечный бэкап перед изменением: одна команда, секунды, откат мгновенный. Это действительно быстрый и удобный инструмент именно для точечной защиты перед рискованной правкой на уровне всей системы. Но важно не путать его с полноценным бэкапом на длинную дистанцию — снапшот живёт на том же диске, зависит от той же виртуалки, и старый забытый снапшот способен просесть по производительности или неожиданно вырасти в размере. Подробнее о том, почему снапшот — не замена бэкапу, если его держать долго, — в статье миф: снапшот виртуалки заменяет бэкап. Для точечной защиты «на 20 минут, пока правлю» — это ровно тот случай, для которого снапшот и создан: сделали, проверили изменение, удалили.

Привычка: встройте бэкап в сам процесс изменения, а не держите в голове

Главная причина, по которой точечные бэкапы не делаются, — не лень, а забывчивость под давлением. Когда нужно быстро подправить что-то в проде, мозг занят самой правкой, а не ритуалом «сначала скопировать». Решение — сделать бэкап частью команды, которую вы и так набираете, а не отдельным шагом, который легко пропустить.

Простой приём — alias или shell-функция, которая оборачивает редактирование конфига автоматическим бэкапом:

# в ~/.bashrc на сервере
editcfg() {
  local f="$1"
  cp -a "$f" "${f}.bak-$(date +%Y%m%d-%H%M%S)"
  ${EDITOR:-vim} "$f"
}

Тогда editcfg /etc/nginx/nginx.conf вместо vim /etc/nginx/nginx.conf даёт бэкап без дополнительного усилия — он встроен в привычный способ открыть файл. Для команды из нескольких человек эффективнее держать это не в личных алиасах, а в общем деплой-скрипте или Makefile проекта — тогда привычка не зависит от того, кто сегодня катит изменение:

deploy:
	@mkdir -p /root/pre-change-backups
	@pg_dump -U app_user -Fc app_db > /root/pre-change-backups/pre-deploy-$$(date +%Y%m%d-%H%M%S).dump
	@docker compose pull && docker compose up -d

Второй важный элемент привычки — ротация этих точечных бэкапов. Они не должны копиться бесконечно: это расходный материал на день-два, а не архив. Простой cron-джоб раз в сутки удаляет файлы из /root/pre-change-backups/ старше 3-7 дней:

find /root/pre-change-backups/ -type f -mtime +5 -delete

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

Когда точечный бэкап не нужен — и как не превратить привычку в ритуал ради ритуала

Не каждое изменение требует отдельного снимка. Если делать точечный бэкап перед абсолютно любым действием на сервере, привычка быстро превращается в формальность, которую выполняют не думая, — а это так же плохо, как не делать её вовсе.

Разумный критерий — задать себе один вопрос: если это изменение пойдёт не так, сколько будет стоить откат без свежего снимка? Если ответ «переставлю один параметр обратно за 10 секунд» — снимок избыточен. Если ответ «придётся восстанавливать из ночного бэкапа и объяснять, куда делись данные за день» — снимок обязателен.

Таблица ниже — не строгий регламент, а ориентир для быстрой оценки:

Если сомневаетесь — делайте снимок. Тридцать секунд на дамп таблицы почти никогда не бывает решающей потерей времени, а вот отсутствие снимка в тот единственный раз, когда правка пошла не так, обходится часами. Тем не менее плановые окна с заранее продуманным чек-листом — для регулярных, предсказуемых работ вроде обновления пакетов или ротации сертификатов — снимают часть этого решения заранее: там точечный бэкап уже прописан как обязательный шаг регламента, и не нужно каждый раз заново оценивать риск. Пример такого чек-листа — в статье плановое обслуживание с окном простоя: регламент.

Отдельно стоит сказать про случаи, когда правки вносятся прямо на проде без подготовки — это отдельная и опасная привычка сама по себе, разобранная в статье про антипаттерн: конфиги правятся на проде. Точечный бэкап не оправдывает такой подход и не делает его безопасным — он лишь уменьшает цену одной конкретной ошибки. Правильная последовательность — тестовый стенд, ревью изменения, и только потом прод с точечным снимком как последней страховкой, а не единственной.

Частые вопросы