---
title: "Резервное копирование и восстановление"
description: "Проверенные процедуры резервного копирования и восстановления для PostgreSQL-клонов Ring, объектного хранилища и устаревших развертываний на Firebase"
locale: "ru"
---
# Резервное копирование и восстановление

> **Info**
> Используйте фильтр **Founder** / **Developer** в боковой панели документации. Эта страница заменяет устаревшие фиктивные материалы (выдуманные TypeScript-менеджеры, KPI в долларах, много-региональные сценарии failover, которые отсутствуют в OSS-репозитории). Всё, что описано ниже, проверено по `data/schema.sql`, `env.local.template` и документации по развертыванию.

Клоны Ring с **`DB_BACKEND_MODE=k8s-postgres-fcm`** (боевой режим по умолчанию) используют **PostgreSQL как основной источник** для пользователей, сущностей, возможностей, заказов, платежей и большей части CRM-данных. Резервное копирование должно охватывать **базу данных**, **загруженные файлы** и **секреты/конфигурацию** — это три разных артефакта с отдельными этапами восстановления.

## Что защищается резервным копированием

| Актив | Обычное расположение | Приоритет восстановления |
|-------|---------------------|-------------------------|
| **PostgreSQL** | кластер `DATABASE_URL` или Docker-том | Критичный — идентификаторы, торговля, контент |
| **Схема + миграции** | `data/schema.sql`, `data/migrations/*.sql` | В git под контролем версий; повторно применить после “пустого” восстановления |
| **Blob / объектное хранилище** | Провайдер file() — `ring_filebase` (по умолчанию), `vercel_blob`, `local_storage`, или `firebase_storage` ([RingFileBase](/docs/integrations/ring-filebase.md), [Ring CDN](/docs/integrations/ring-cdn.md)) | Высокий — изображения товаров, вложения, сгенерированные медиа |
| **Секреты среды** | `.env.local`, секрееты k8s (не в публичном репозитории) | Критичный — Auth.js, WayForPay/Stripe, FCM service account |
| **Redis-кеш** | Docker-том `ring-redis-data` | Низкий — можно сбросить/пересоздать; сессии сбросятся |
| **FCM-токены** | Postgres JSONB `fcm_tokens` при использовании postgres-primary | Покрываются резервной копией БД |

### For founders

## Почему бэкап важен для вашего клона

Ring — это не просто сайт. Postgres хранит **статус членства**, **каталоги продавцов**, **заказы и платежи**, **объявления возможностей**, **рефералов**. Потеря базы без точки восстановления = ручная перерегистрация пользователей и сверка платежей.

### Типовые сценарии

  
- **[Клон до запуска](/docs/getting-started/migrations.md)** — Снимите резервную копию после применения схемы и исходных данных — сможете откатить неудачную миграцию или сбросить стейджинг.

  
- **[Мультивендорный маркетплейс](/docs/features/store.md)** — Заказы и остатки — в Postgres, изображения товаров могут быть в Blob. Бекапьте и то, и другое.

  
- **[Менеджмент на Ringdom Hosting](/docs/development/oss-vs-enterprise.md)** — Пользователи ringdom.org на k8s используют расписания CNPG/MinIO, самостоятельные хостеры сами отвечают за резервные копии.

  
- **[Соответствие и аудит](/docs/features/security.md)** — Транзакции PaymentConductor (`payment_transactions`) поддерживают обработку споров — база должна входить в политику хранения.

### Планирование RTO и RPO (ваши метрики)

Ring Platform **не гарантирует** фиксированные SLA восстановления в OSS-репозитории. Определяйте для каждого клона:
- **RPO** — сколько данных допустимо потерять (например, последний ночной дамп, или почасовые бэкапы).
- **RTO** — сколько времени ваш клон может быть “read-only” или офлайн при восстановлении.

Задокументируйте ответственных за восстановление (оператор или разработчик) и где хранятся дампы (зашифрованное объектное хранилище, off-site).

  `AUTH_SECRET`, ключи WayForPay и сервис-аккаунты Firebase хранятся в среде/Secret-сторах. Экспортируйте их менеджером паролей или workflow sealed-secrets — дампа Postgres недостаточно для восстановления авторизации.

### For developers

## PostgreSQL-primary (`k8s-postgres-fcm`/`supabase-fcm`)

Данные проходят через `DatabaseService` → `PostgreSQLAdapter`. Бекап = **логический дамп базы клона** (по одному на клон, например, `ring_platform`, `ring_greenfood_live`).

### Логический бэкап (Docker-разработка — описано в `data/SCHEMA-README.md`)

### Дамп в файл

{`mkdir -p backups

docker exec ring-postgres-dev pg_dump -U ring_user ring_platform \
  > backups/ring_platform_$(date +%Y%m%d).sql`}

Для больших БД в проде лучше использовать “custom format” (для параллельного восстановления и сжатия):

{`docker exec ring-postgres-dev pg_dump -U ring_user -Fc ring_platform \
  > backups/ring_platform_$(date +%Y%m%d).dump`}

### Восстановление в пустую базу

{`docker exec -i ring-postgres-dev psql -U ring_user -d ring_platform \
  < backups/ring_platform_20250204.sql`}

Custom format:

{`docker exec -i ring-postgres-dev pg_restore -U ring_user -d ring_platform \
  --clean --if-exists < backups/ring_platform_20250204.dump`}

### Применение миграций поверх старого дампа

После восстановления сравните схему с эталонным `data/schema.sql` и инкрементальными `data/migrations/`. Используйте [Database migrations](/docs/getting-started/migrations.md) и применяйте пропущенные миграции до запуска приложения.

Переменная для нативного `psql`/`pg_dump` (без Docker):

{`export DATABASE_URL=postgresql://user:pass@host:5432/ring_platform
pg_dump "$DATABASE_URL" -Fc -f backups/ring_platform.dump`}

Читайте [Конфигурацию окружения](/docs/deployment/environment.md) по переменным `DB_*` и файлу `env.local.template`.

### До опасных миграций

Перед определёнными миграциями нужен бэкап — например, `013_users_email_unique.sql` требует дедупликации (`scripts/dedupe-users-by-email.cts`, детали в `data/migrations/README.md`). **Всегда делайте дамп** перед дедупликацией или скриптами нормализации ролей.

### Объектное хранилище

Файлы загружаются через выбранный провайдер file() — объекты **НЕ** лежат в Postgres. Разрешение (`lib/storage/storage-config.ts`): переменные окружения `NEXT_PUBLIC_STORAGE_PROVIDER`/`STORAGE_PROVIDER` → `ring-config.json` `storage.provider` → по умолчанию **`ring_filebase`**. Задействованы: `ring_filebase` (по умолчанию) | `vercel_blob` | `local_storage` | `firebase_storage`. Бэкапьте объекты отдельно (или принимайте риск потери медиа); см. [RingFileBase](/docs/integrations/ring-filebase.md), [Ring CDN](/docs/integrations/ring-cdn.md).

### Режим `firebase-full` (устаревший/комьюнити)

Если `DB_BACKEND_MODE=firebase-full`, основная бизнес-логика в Firestore (`shouldUseFirebaseForDatabase()` в `lib/database/backend-mode-config.ts`). Используйте **Google Cloud Firestore export/import** в GCS — не команды Postgres. Auth.js может оставаться в Postgres в зависимости от adapter-конфигурации; проверьте это на [Архитектура аутентификации](/docs/architecture/authentication.md).

### Kubernetes / Ringdom Operator

Публичный OSS-репозиторий **не содержит** `k8s/` manifests ([OSS vs enterprise](/docs/development/oss-vs-enterprise.md)). На управляемых кластерах обычно используется **CloudNativePG** `ScheduledBackup` в совместимое с S3 хранилище (например, MinIO). Runbooks операторов хранятся вне этого репозитория; настройте политику хранения копий согласно классу хранилища и требованиям off-site.

```mermaid
flowchart TB
  subgraph App[Ring Next.js]
    DS[DatabaseService]
    Blob[Object storage — file() provider]
  end
  subgraph Protect[Backup targets]
    PG[(PostgreSQL — pg_dump / CNPG)]
    OBJ[Object storage export]
    SEC[Secrets store — separate]
  end
  DS --> PG
  App --> Blob --> OBJ
  App -.-> SEC
```

### Минимальная тренировка восстановления

Восстановите последний дамп в **стейджинговую** БД (не production).

Запустите `npm run build` (или health check) с новым `DATABASE_URL`.

Проверьте логин, чтение одной сущности, просмотр списка возможностей и `/api/health`.

Запишите возраст дампа, длительность восстановления и пропущенные данные — пересмотрите расписание бэкапа при неудовлетворительном RPO.

## Связанная документация

  
- [architecture/data-model](/docs/architecture/data-model.md) — Предпосылка: коллекции JSONB присутствуют в дампах Postgres.

  
- [architecture/backend-modes-and-databases](/docs/architecture/backend-modes-and-databases.md) — Подробно: когда владеет данными Postgres, а когда Firestore.

  
- [deployment/docker](/docs/deployment/docker.md) — Тот же подход: compose сервисы, тома, health-check.

  
- [getting-started/migrations](/docs/getting-started/migrations.md) — Следующий шаг: порядок применения миграций после восстановления.

  
- [deployment/monitoring](/docs/deployment/monitoring.md) — Тот же подход: алертинг при фейле бэкап-джобов.