Бэкап и восстановление Strapi

MAATRIX

Strapi хранит данные не в одном месте: контент лежит в базе, файлы — в public/uploads (или во внешнем S3), а ключи доступа и настройки окружения — в .env и конфигах проекта. Если бэкапить только базу «на всякий случай», при реальном восстановлении вы получите сайт без картинок и без доступа в админку. Ниже — рабочая схема бэкапа всех трёх частей, автоматизация через cron и пошаговое восстановление на новом сервере.

Что входит в бэкап Strapi и почему одной базы мало

У Strapi три независимых компонента, которые нужно бэкапить отдельно:

1. База данных — весь контент: записи коллекций, single types, роли, права доступа, настройки полей. В продакшене это обычно PostgreSQL или MySQL/MariaDB; в небольших и личных проектах на Strapi 5 официально поддерживается и SQLite.
2. Файлы медиатеки — если используется локальный provider (@strapi/provider-upload-local), это папка public/uploads. Если подключён S3-совместимый провайдер (AWS S3, MinIO, Cloudflare R2), файлы физически лежат вне сервера, а бэкапить нужно уже само хранилище.
3. Код и секреты — .env (там APP_KEYS, ADMIN_JWT_SECRET, API_TOKEN_SALT, TRANSFER_TOKEN_SALT, JWT_SECRET, данные подключения к БД), папка config/, package.json и package-lock.json. Сам код обычно живёт в git, но .env в репозиторий никогда не попадает — и именно его чаще всего забывают бэкапить.

Отдельно стоит встроенный инструмент strapi export — он умеет упаковать контент из базы и файлы медиатеки (при локальном провайдере) в один архив. Это удобно для переноса между окружениями, но он не сохраняет .env, кастомный код и системные настройки — так что как единственный способ бэкапа он не годится, а вот как дополнение к дамп-скрипту — да.

Быстрый бэкап через встроенный strapi export

У Strapi есть CLI-команда export, которая работает поверх запущенного приложения и обращается к базе через ORM — не нужно знать тип БД или её конфигурацию:

cd /opt/strapi-app
npm run strapi export -- --file backup-$(date +%F) --encrypt --key "СИЛЬНЫЙ_ПАРОЛЬ"

Флаги, которые пригодятся:

• --no-compress — если архив и так пойдёт в уже сжатый бэкап (редко нужно);
• --only content,files — экспортировать только контент и файлы, без конфигурации ролей/прав;
• --exclude files — если медиатека хранится в S3 и её не нужно тащить в архив ещё раз.

Результат — файл backup-2026-08-30.tar.gz.enc (с --encrypt) или .tar.gz без него. Хранить такой архив без шифрования не стоит: внутри полный дамп контента, включая пользовательские данные.

Восстановление из этого архива:

npm run strapi import -- --file backup-2026-08-30.tar.gz.enc --key "СИЛЬНЫЙ_ПАРОЛЬ"

Важный нюанс: import по умолчанию требует пустую базу и откажется перезаписывать существующие данные без подтверждения. Для форс-импорта добавьте --force, но это удалит всё, что уже есть в целевой базе, — используйте на чистом окружении или при полном восстановлении после аварии.

Бэкап базы данных напрямую

CLI-экспорт удобен, но для продакшена держите ещё и прямой дамп СУБД — он не зависит от версии Strapi и восстанавливается стандартными средствами.

PostgreSQL (рекомендуемая СУБД для продакшена):

pg_dump -h 127.0.0.1 -U strapi -d strapi_prod -F c -f /opt/backups/strapi_prod_$(date +%F).dump

Восстановление:

pg_restore -h 127.0.0.1 -U strapi -d strapi_prod --clean --if-exists /opt/backups/strapi_prod_2026-08-30.dump

MySQL / MariaDB:

mysqldump -u strapi -p --single-transaction strapi_prod > /opt/backups/strapi_prod_$(date +%F).sql

Восстановление:

mysql -u strapi -p strapi_prod < /opt/backups/strapi_prod_2026-08-30.sql

SQLite (Strapi 5, лёгкие проекты): файл базы обычно лежит в .tmp/data.db. Копировать его «на живую» рискованно — используйте встроенный механизм бэкапа SQLite, а не cp:

sqlite3 .tmp/data.db ".backup '/opt/backups/data_$(date +%F).db'"

Так вы получите консистентную копию даже при активной записи, без остановки процесса.

Бэкап файлов медиатеки

Если провайдер загрузки — локальный, файлы физически лежат в public/uploads. Простой архив:

tar czf /opt/backups/uploads_$(date +%F).tar.gz -C /opt/strapi-app public/uploads

Для больших медиатек лучше rsync с инкрементальным копированием на отдельный диск или другой сервер — это быстрее, чем каждый раз паковать всё заново:

rsync -avz --delete public/uploads/ backup-user@backup-host:/backups/strapi/uploads/

Если используется S3-совместимое хранилище (например, MinIO — как в гайдах по разворачиванию MinIO в Docker Compose), сама Strapi файлы не хранит — бэкапить нужно бакет. У большинства S3-совместимых хранилищ есть версионирование объектов и репликация бакетов, но это отдельная настройка на стороне хранилища, а не на стороне Strapi.

Автоматизация: скрипт и cron

Собираем всё в один скрипт — дамп базы, архив аплоадов, копия .env (зашифрованная отдельно), ротация старых копий и синхронизация на удалённое хранилище:

#!/usr/bin/env bash
set -euo pipefail

APP_DIR="/opt/strapi-app"
BACKUP_DIR="/opt/backups/strapi"
DATE=$(date +%F)
RETENTION_DAYS=14

mkdir -p "$BACKUP_DIR"

# База (PostgreSQL)
pg_dump -h 127.0.0.1 -U strapi -d strapi_prod -F c -f "$BACKUP_DIR/db_$DATE.dump"

# Аплоады
tar czf "$BACKUP_DIR/uploads_$DATE.tar.gz" -C "$APP_DIR" public/uploads

# Секреты — отдельно и зашифрованно
gpg --batch --yes --symmetric --cipher-algo AES256 \
    --passphrase-file /etc/strapi-backup.key \
    -o "$BACKUP_DIR/env_$DATE.gpg" "$APP_DIR/.env"

# Ротация локальных копий
find "$BACKUP_DIR" -type f -mtime +"$RETENTION_DAYS" -delete

# Синхронизация во внешнее хранилище
rclone copy "$BACKUP_DIR" remote:strapi-backups --transfers 4 --checksum

Задача в cron (запуск в 3 ночи, лог отдельно):

0 3 * * * /opt/scripts/strapi-backup.sh >> /var/log/strapi-backup.log 2>&1

Про настройку самого rclone и подключение S3-совместимого remote — в статье про MinIO как приёмник бэкапов. Если вместо rclone предпочитаете дедуплицирующий инструмент с версионированием, посмотрите на BorgBackup — для проектов с большой медиатекой он экономит место за счёт дедупликации между снапшотами.

Хранение бэкапов: шифрование, ротация, копия вне сервера

Три правила, которые снимают большинство рисков:

• Бэкап на том же диске — не бэкап. Если сервер выйдет из строя целиком (диск, хостинг, DDoS с последующей переустановкой), локальная копия пропадёт вместе с оригиналом. Синхронизируйте архивы на отдельный сервер или в S3-совместимое хранилище хотя бы раз в сутки.
• Дамп базы и .env содержат чувствительные данные — пользовательские email, хэши паролей, ключи API. Шифруйте их перед отправкой во внешнее хранилище (в скрипте выше это делает gpg для .env; для дампа базы можно так же прогнать через gpg --symmetric, если хранилище не доверенное).
• Проверяйте restore, а не только backup. Бэкап, который ни разу не разворачивали на тестовом сервере, с одинаковой вероятностью может оказаться битым или рабочим — узнаете только в момент аварии.

Ориентировочная схема хранения для среднего проекта: ежедневные копии — 14 дней, еженедельные — 8 недель, ежемесячные — 6–12 месяцев. Конкретные сроки зависят от того, как часто меняется контент и насколько критична потеря последних правок.

Восстановление Strapi на новом сервере

Пошагово, от чистой VPS до работающего приложения:

1. Подготовьте окружение. Установите тот же major-релиз Node.js, что использовался на исходном сервере (Strapi чувствителен к версии Node — проверяйте engines в package.json), и системные зависимости для сборки нативных модулей (build-essential, python3 — нужны для sharp и better-sqlite3).

1. Разверните код. Клонируйте репозиторий или распакуйте архив проекта (без node_modules — их поставит установка зависимостей):

git clone git@github.com:your-org/strapi-app.git /opt/strapi-app
cd /opt/strapi-app
npm ci --omit=dev

1. Восстановите .env с теми же значениями, что были на исходном сервере — особенно APP_KEYS, ADMIN_JWT_SECRET, API_TOKEN_SALT, TRANSFER_TOKEN_SALT. Это не обязательно технически (Strapi сгенерирует новые ключи, если их нет), но если вставить новые ключи вместо старых, все текущие сессии администраторов, выданные API-токены и подписанные cookie мгновенно станут невалидными. Расшифровка сохранённого .env:

gpg --batch --yes --passphrase-file /etc/strapi-backup.key -d env_2026-08-30.gpg > .env

1. Восстановите базу данных — pg_restore, mysql < dump.sql или .restore для SQLite, командами из раздела выше. Убедитесь, что имя базы и пользователь в дампе совпадают с тем, что указано в .env (DATABASE_NAME, DATABASE_USERNAME), либо создайте базу и роль заранее под те же имена.

1. Восстановите public/uploads и выставьте владельца файлов на пользователя, от которого работает Strapi:

tar xzf uploads_2026-08-30.tar.gz -C /opt/strapi-app
chown -R strapi:strapi /opt/strapi-app/public/uploads

Если использовался S3-провайдер — восстанавливать физические файлы не нужно, достаточно, чтобы в .env/конфиге были корректные ключи доступа к бакету.

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

NODE_ENV=production npm run build

1. Запустите приложение через process-менеджер (например, PM2) и проверьте логин в админку, отображение медиафайлов и ответ публичного API.

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