Backup & Migration
Бэкапы через Dokploy, восстановление, миграция на другой сервер.
1. Что нужно бэкапить
| Компонент | Критичность | Метод | Частота |
|---|---|---|---|
| PostgreSQL | Критичен | Dokploy → S3 (автоматически) | Ежедневно |
| Dokploy конфигурация | Важен | Dokploy Server Backup → S3 | При изменениях |
| Environment variables | Критичен | Password Manager | При изменениях |
| Код (Git) | Есть в GitHub | — | Автоматически |
| SSL сертификаты | Автовосстановление | Let's Encrypt | Не нужен |
Dokploy умеет бэкапить PostgreSQL и собственную конфигурацию прямо в S3-совместимое хранилище. Не нужно настраивать cron-задачи или bash-скрипты вручную.
2. Предварительно: S3 Destination
Перед настройкой бэкапов нужно подключить S3-совместимое хранилище.
Поддерживаемые провайдеры: AWS S3, Cloudflare R2, Backblaze B2, Google Cloud Storage, DigitalOcean Spaces и любые S3-совместимые.
Настройка
- Dokploy UI → Settings → S3 Destinations
- + Add Destination
- Заполнить:
| Поле | Описание |
|---|---|
| Name | Понятное имя (например, goloot-backups) |
| Access Key | Ключ доступа от провайдера |
| Secret Key | Секретный ключ от провайдера |
| Bucket | Имя бакета в хранилище |
| Region | Регион бакета |
| Endpoint | URL эндпоинта (для не-AWS провайдеров) |
- Save → проверить что destination появился в списке
Access Key и Secret Key от S3 — сохрани в Password Manager. Если потеряешь доступ к S3 — потеряешь и бэкапы.
3. Бэкап PostgreSQL
Настройка автоматического бэкапа
- Dokploy UI → проект goLoot → сервис PostgreSQL
- Вкладка Backups
- Выбрать S3 Destination (созданный в шаге 2)
- Настроить Schedule (cron-расписание):
| Расписание | Cron | Описание |
|---|---|---|
| Ежедневно в 03:00 | 0 3 * * * | Рекомендуемый вариант |
| Каждые 12 часов | 0 */12 * * * | Для production с активными данными |
| Еженедельно (вс) | 0 3 * * 0 | Для staging/dev |
- Save
Dokploy автоматически выполняет pg_dump, сжимает и загружает в S3 по расписанию.
Ручной бэкап
Для создания бэкапа прямо сейчас (например, перед опасной миграцией):
Dokploy UI → PostgreSQL → Backups → Create Backup
Восстановление через Dokploy UI
- Dokploy UI → PostgreSQL → Backups
- Найти нужный бэкап в списке
- Restore
Активные подключения от Backend могут помешать восстановлению. Перед Restore:
- Dokploy UI → Backend → Stop
- Выполнить Restore
- Dokploy UI → Backend → Deploy
4. Бэкап Dokploy конфигурации
Dokploy хранит всю свою конфигурацию в SQLite базе (/etc/dokploy/dokploy.db):
- Все сервисы и их настройки
- Environment variables всех сервисов
- Домены и SSL конфигурация
- Git провайдеры
- История деплоев
Настройка Server Backup
- Dokploy UI → Settings → Server → Backups
- Выбрать S3 Destination
- Настроить расписание (или выполнить вручную)
Dokploy создаёт .zip архив с /etc/dokploy + внутренней PostgreSQL базой и загружает в S3.
Восстановление
- Dokploy UI → Settings → Server → Backups
- Выбрать бэкап → Restore
- После восстановления:
- Обновить IP сервера (если изменился)
- Проверить Git провайдеры
- Обновить DNS записи (если нужно)
5. Бэкап Environment Variables
Хотя env vars сохраняются в dokploy.db (и покрываются Server Backup), рекомендуется хранить отдельную копию. Если потеряешь и S3, и сервер — env vars не восстановить.
Рекомендация: Password Manager
Сохрани env vars в 1Password, Bitwarden или аналоге. Группируй по сервисам:
📁 goLoot Production
├── 📄 Backend ENV
├── 📄 Frontend ENV
├── 📄 Admin ENV
├── 📄 PostgreSQL ENV
├── 📄 Redis ENV
├── 📄 Redirect Service ENV
└── 📄 S3 Credentials
Когда обновлять: каждый раз при изменении env vars в Dokploy — сразу обнови копию в Password Manager.
6. Восстановление PostgreSQL вручную
Когда нужен ручной pg_dump / восстановление?
- Миграция на новый сервер — Dokploy на новом сервере ещё не настроен, нельзя использовать UI Restore
- Dokploy Server Backup не работает — проблемы с S3 или Dokploy
- Нужен гранулярный контроль — восстановить конкретные таблицы, а не всю базу
Определение имени контейнера
docker ps --format '{{.Names}}' | grep -i postgres
Создание дампа
docker exec $(docker ps -q -f name=postgres) pg_dump -U goloot goloot | gzip > goloot_$(date +%Y%m%d_%H%M).sql.gz
-U goloot goloot — первый goloot это имя пользователя, второй — имя базы. Замените на значения из Environment Variables вашего PostgreSQL сервиса (POSTGRES_USER и POSTGRES_DB).
Восстановление из дампа
1. Остановить backend:
Dokploy UI → Backend → Stop
2. Отключить соединения и пересоздать базу:
# Завершить все активные подключения
docker exec -i $(docker ps -q -f name=postgres) psql -U goloot -d postgres -c \
"SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname='goloot' AND pid <> pg_backend_pid();"
# Пересоздать базу (подключаемся к служебной БД postgres, т.к. нельзя удалить текущую)
docker exec -i $(docker ps -q -f name=postgres) psql -U goloot -d postgres -c \
"DROP DATABASE goloot; CREATE DATABASE goloot OWNER goloot;"
3. Восстановить:
gunzip -c goloot_20250210_0300.sql.gz | docker exec -i $(docker ps -q -f name=postgres) psql -U goloot goloot
4. Запустить backend: Dokploy UI → Backend → Deploy
7. Миграция на другой сервер
Пошаговый план
Шаг 1-2: Новый сервер
Следуй Server Setup и Dokploy Installation.
Шаг 3-4: Перенос данных
Вариант A: Через Dokploy Server Backup (рекомендуется)
Если версии Dokploy совпадают:
- На старом сервере: Dokploy UI → Settings → Server → Backups → Create Backup
- На новом сервере: настроить тот же S3 Destination
- Dokploy UI → Settings → Server → Backups → выбрать бэкап → Restore
Это восстановит все сервисы, env vars, домены — всю конфигурацию целиком.
Вариант B: Вручную (если версии Dokploy отличаются)
# На старом сервере: создать дамп PostgreSQL
docker exec $(docker ps -q -f name=postgres) pg_dump -U goloot goloot | gzip > goloot_migration.sql.gz
# Перенести на новый
scp goloot_migration.sql.gz root@NEW_SERVER:/root/
На новом сервере:
- Создать сервисы заново по Services Deployment
- Восстановить БД (см. секцию 6 — ручное восстановление)
- Env vars взять из Password Manager
Шаг 5: Обновить DNS
Измени A-записи для всех доменов на IP нового сервера.
# Проверить когда DNS обновится
dig api.goloot.online +short
# Должен показать IP нового сервера
Шаг 6: Проверка
# Health check
curl https://api.goloot.online/health
# Frontend
curl -s -o /dev/null -w "%{http_code}" https://goloot.online
Шаг 7: Выключить старый
Не выключай старый сервер сразу! Подожди 24-48 часов на случай проблем.
8. Disaster Recovery
Сценарий: Полная потеря сервера
| Шаг | Действие | Время |
|---|---|---|
| 1 | Создать новый VPS | 5 мин |
| 2 | Server Setup | 20 мин |
| 3 | Dokploy Installation | 10 мин |
| 4 | Настроить S3 Destination | 5 мин |
| 5 | Restore Server Backup из S3 | 10 мин |
| 6 | Restore PostgreSQL из S3 | 10 мин |
| 7 | DNS + SSL | 10 мин |
| Итого | ~1.5 часа |
При полной потере сервера S3 бэкап — единственный источник данных. Без него придётся настраивать всё с нуля (env vars из Password Manager, сервисы вручную, данные потеряны).
Сценарий: Потеря БД (но сервер цел)
- Dokploy UI → PostgreSQL → Backups → выбрать последний бэкап → Restore
- Dokploy UI → Backend → Redeploy
Сценарий: Потеря env vars
Восстановить из:
- Dokploy Server Backup (env vars хранятся в
dokploy.db) - Password Manager (отдельная копия)
9. Чеклист
- S3 Destination настроен (Settings → S3 Destinations)
- Автоматический бэкап PostgreSQL настроен (Database → Backups)
- Dokploy Server Backup настроен (Settings → Server → Backups)
- Env vars сохранены в Password Manager
- S3 credentials сохранены в Password Manager
- Тестовое восстановление выполнено хотя бы раз
Related
- CI/CD Setup — предыдущий шаг
- Database Setup — настройка БД
- Deployment Overview — общая карта