Обновление и бэкапы

Как накатить новую версию и что сохранять, чтобы не потерять проект

Что бэкапить

Обязательны все три:

Что	Где	Почему нельзя пропустить
База данных	ваш MySQL/MariaDB	Всё содержимое проекта
Папка `storage`	корень репозитория	Скины, плащи, иконки товаров, картинки новостей
`.env`	корень репозитория	Без `ENCRYPTION_KEY` дамп базы бесполезен

Ключ отдельно от дампа

Пароли, секреты 2FA и пароли RCON лежат в базе в зашифрованном виде. Дамп без ENCRYPTION_KEY не восстановить, войти не сможет никто. Но и хранить ключ рядом с дампом плохо, тогда шифрование ничего не защищает. Держите их в разных местах и с разными доступами.

Минимальный скрипт бэкапа:

mysqldump -u unicore -p unicore | gzip > backup-$(date +%F).sql.gz
tar czf storage-$(date +%F).tar.gz storage/

Обновление

Сделать бэкап

Да, каждый раз. Схема базы синхронизируется автоматически, и откатиться назад без дампа не выйдет.

Подтянуть код

git pull
pnpm install

Сравнить `.env` с примером

diff <(grep -o '^[A-Z_]*' .env | sort -u) <(grep -o '^[A-Z_]*' .env.example | sort -u)

Переменные, которых нет в вашем .env, появились в свежей версии. Обычно у них есть значения по умолчанию, но лучше посмотреть глазами.

Собрать

pnpm run build

Погасите dev-серверы

Если параллельно крутится pnpm run dev, сборка фронтов упадёт на блокировке файлов. Сначала остановить, потом собирать.

Перезапустить

pm2 restart ecosystem.config.js

Или, если через Docker:

docker compose --profile prod up -d --build

Базу трогать не нужно: сервер сам применит накопившиеся изменения схемы при старте и только потом начнёт принимать запросы.

Что происходит с базой при старте

Сервер ведёт журнал применённых изменений в таблице unicore_migrations и при каждом запуске делает три вещи:

Берёт блокировку, чтобы под pm2 в кластере или в нескольких контейнерах схему обновлял только один процесс.
Применяет изменения, которых нет в журнале. Каждое написано так, что повторный запуск ничего не портит.
Досоздаёт то, что появилось в коде, но отсутствует в базе: новые таблицы, колонки, индексы — в том числе таблицы установленных расширений.

Досоздание никогда не удаляет и не сужает: DROP любого вида, удаление колонок и изменение типов пропускаются. Если такое расхождение есть, сервер напишет в лог, сколько их и какой командой посмотреть — решение остаётся за вами.

Дамп перед обновлением обязателен

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

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

На крайний случай есть MIGRATIONS_SKIP=true — сервер поднимется, не трогая базу, и будет напоминать об этом при каждом старте. Это способ вернуть сайт, пока разбираетесь, а не режим работы.

Команды для разработки

Команда	Что делает
`pnpm run migrate:status`	Показывает журнал: что применено и есть ли ожидающие изменения
`pnpm run align`	Досоздаёт недостающее в схеме, не дожидаясь старта сервера
`pnpm run sync`	Полная синхронизация TypeORM. Умеет удалять колонки, на боевой базе не запускать

Откат

git checkout <предыдущий-тег>
pnpm install
pnpm run build
gunzip < backup-2026-08-01.sql.gz | mysql -u unicore -p unicore
tar xzf storage-2026-08-01.tar.gz
pm2 restart ecosystem.config.js

Порядок важен: сначала код, потом база. В обратном порядке новый код увидит старую схему и посыплется.

Обновление и бэкапы

Содержание