---
title: "Резервне копіювання і відновлення"
description: "Верифіковані межі резервного копіювання і процедури відновлення для клонів Ring на основі PostgreSQL, об'єктного сховища та застарілих firebase-full розгортань"
locale: "uk"
---
# Резервне копіювання і відновлення

> **Info**
> Використовуйте фільтри **Засновник** / **Розробник** у бічній панелі документації. Ця сторінка замінює вигадані інструкції з минулих версій (вигадані TypeScript-менеджери, KPI у $ та мульти-регіональний failover код, якого немає у відкритому репозиторії). Всі дії нижче підтверджуються у `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 / object storage** | Роздільні `file()` провайдери — `ring_filebase` (типово), `vercel_blob`, `local_storage`, або `firebase_storage` ([RingFileBase](/docs/integrations/ring-filebase.md), [Ring CDN](/docs/integrations/ring-cdn.md)) | Високий — зображення товарів, вкладення, генеровані медіа |
| **Runtime secrets** | `.env.local`, K8s Secrets (не у публічному репо) | Критичний — Auth.js, WayForPay/Stripe, FCM service account |
| **Redis cache** | Docker-том `ring-redis-data` | Низький — можна перебудувати; сесії можуть скидатись |
| **FCM tokens** | Postgres `fcm_tokens` JSONB у разі postgres-primary | Покрито бекупом бази даних |

### For founders

## Навіщо вашому клону бекупи

Розгортання Ring — це не просто “сайт”. У Postgres зберігається **стан членства**, **каталоги постачальників**, **журнали замовлень та оплат**, **оголошення можливостей** та **реферали**. Втрата бази без точки відновлення — це повторна реєстрація користувачів і ручне звірення оплат.

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

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

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

  
- **[Керований хостинг Ringdom](/docs/development/oss-vs-enterprise.md)** — На ringdom.org для k8s оператор керує CNPG/MinIO бекупами; при самостійному розгортанні розклад dump-а визначаєте ви.

  
- **[Вимоги до комплаєнсу і аудиту](/docs/features/security.md)** — Записи у `payment_transactions` дають змогу розв'язувати спірні транзакції — обов'язково включайте БД у політику зберігання.

### Планування RTO та RPO (ваші цифри)

Ring Platform **не гарантує** встановлені SLA відновлення у відкритому коді. Визначайте цілі для свого клонованого розгортання:

- **RPO** — скільки даних допустимо втратити (наприклад, “останній нічний дамп” чи “годинний логічний бекуп”).
- **RTO** — як довго розгортання може бути у read-only чи недоступному стані під час відновлення.

Задокументуйте, хто ухвалює рішення про відновлення (оператор чи девелопер), і де зберігаються дампи (зашифроване об'єктне сховище, поза кластером).

  `AUTH_SECRET`, ключі WayForPay та Firebase service account знаходяться у env/Secrets. Збережіть їх через парольний менеджер чи sealed-secrets — дамп Postgres сам по собі не відновить auth.

### 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 формат (паралельне відновлення, стиснення):

{`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 формат:

{`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` та SQL інкрементами у `data/migrations/` (див. [Міграції бази даних](/docs/getting-started/migrations.md)). Перед запуском застосуйте всі відсутні SQL-міграції.

Рядок підключення для власного `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`.

### Перед руйнівними міграціями

Деякі міграції вимагають попереднього бекупу — napриклад, `013_users_email_unique.sql` потребує дедуплікації (`scripts/dedupe-users-by-email.cts`), зазначено у `data/migrations/README.md`. **Завжди робіть dump** перед дедуплікацією чи зміною ролей.

### Object storage

Завантаження використовують провайдер із `file()` — байти об'єктів **не** зберігаються у Postgres. Налаштування (`lib/storage/storage-config.ts`): змінна `NEXT_PUBLIC_STORAGE_PROVIDER` / `STORAGE_PROVIDER` → `ring-config.json` → типово **`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. Postgres може містити таблиці Auth.js залежно від вашого adapter; перевірте свою конфігурацію у [Архітектура аутентифікації](/docs/architecture/authentication.md).

### Kubernetes / Оператори Ringdom

Відкритий репозиторій **не містить** маніфестів `k8s/` ([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[Об'єктне сховище — file() провайдер]
  end
  subgraph Protect[Цілі бекупів]
    PG[(PostgreSQL — pg_dump / CNPG)]
    OBJ[Експорт об'єктного сховища]
    SEC[Сховище секретів — окремо]
  end
  DS --> PG
  App --> Blob --> OBJ
  App -.-> SEC
```

### Мінімальна перевірка відновлення

Відновіть останній дамп на **staging**-БД (ніколи не у production одразу).

Запустіть `npm run build` (або health check) з staging `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) — Той самий workflow: compose сервіси, томи, healthchecks.

  
- [getting-started/migrations](/docs/getting-started/migrations.md) — Далі: послідовність міграцій після відновлення.

  
- [deployment/monitoring](/docs/deployment/monitoring.md) — Той самий workflow: алерти при збої бекупу.