Loading documentation...
Preparing Ring content
Концепции, ценность и типичные сценарии клонирования — меньше кода.
Концепции, ценность и типичные сценарии клонирования — меньше кода.
Preparing Ring content
Preparing Ring content
Preparing Ring content
Используйте фильтр 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, Ring CDN) | Высокий — изображения товаров, вложения, сгенерированные медиа |
| Секреты среды | .env.local, секрееты k8s (не в публичном репозитории) | Критичный — Auth.js, WayForPay/Stripe, FCM service account |
| Redis-кеш | Docker-том ring-redis-data | Низкий — можно сбросить/пересоздать; сессии сбросятся |
| FCM-токены | Postgres JSONB fcm_tokens при использовании postgres-primary | Покрываются резервной копией БД |
Ring — это не просто сайт. Postgres хранит статус членства, каталоги продавцов, заказы и платежи, объявления возможностей, рефералов. Потеря базы без точки восстановления = ручная перерегистрация пользователей и сверка платежей.
Снимите резервную копию после применения схемы и исходных данных — сможете откатить неудачную миграцию или сбросить стейджинг.
Заказы и остатки — в Postgres, изображения товаров могут быть в Blob. Бекапьте и то, и другое.
Пользователи ringdom.org на k8s используют расписания CNPG/MinIO, самостоятельные хостеры сами отвечают за резервные копии.
Предпосылка: коллекции JSONB присутствуют в дампах Postgres.
Подробно: когда владеет данными Postgres, а когда Firestore.
Тот же подход: compose сервисы, тома, health-check.
Следующий шаг: порядок применения миграций после восстановления.
Используйте фильтр 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, Ring CDN) | Высокий — изображения товаров, вложения, сгенерированные медиа |
| Секреты среды | .env.local, секрееты k8s (не в публичном репозитории) | Критичный — Auth.js, WayForPay/Stripe, FCM service account |
| Redis-кеш | Docker-том ring-redis-data | Низкий — можно сбросить/пересоздать; сессии сбросятся |
| FCM-токены | Postgres JSONB fcm_tokens при использовании postgres-primary | Покрываются резервной копией БД |
Ring — это не просто сайт. Postgres хранит статус членства, каталоги продавцов, заказы и платежи, объявления возможностей, рефералов. Потеря базы без точки восстановления = ручная перерегистрация пользователей и сверка платежей.
Снимите резервную копию после применения схемы и исходных данных — сможете откатить неудачную миграцию или сбросить стейджинг.
Заказы и остатки — в Postgres, изображения товаров могут быть в Blob. Бекапьте и то, и другое.
Пользователи ringdom.org на k8s используют расписания CNPG/MinIO, самостоятельные хостеры сами отвечают за резервные копии.
Предпосылка: коллекции JSONB присутствуют в дампах Postgres.
Подробно: когда владеет данными Postgres, а когда Firestore.
Тот же подход: compose сервисы, тома, health-check.
Следующий шаг: порядок применения миграций после восстановления.
Используйте фильтр 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, Ring CDN) | Высокий — изображения товаров, вложения, сгенерированные медиа |
| Секреты среды | .env.local, секрееты k8s (не в публичном репозитории) | Критичный — Auth.js, WayForPay/Stripe, FCM service account |
| Redis-кеш | Docker-том ring-redis-data | Низкий — можно сбросить/пересоздать; сессии сбросятся |
| FCM-токены | Postgres JSONB fcm_tokens при использовании postgres-primary | Покрываются резервной копией БД |
Ring — это не просто сайт. Postgres хранит статус членства, каталоги продавцов, заказы и платежи, объявления возможностей, рефералов. Потеря базы без точки восстановления = ручная перерегистрация пользователей и сверка платежей.
Снимите резервную копию после применения схемы и исходных данных — сможете откатить неудачную миграцию или сбросить стейджинг.
Заказы и остатки — в Postgres, изображения товаров могут быть в Blob. Бекапьте и то, и другое.
Пользователи ringdom.org на k8s используют расписания CNPG/MinIO, самостоятельные хостеры сами отвечают за резервные копии.
Предпосылка: коллекции JSONB присутствуют в дампах Postgres.
Подробно: когда владеет данными Postgres, а когда Firestore.
Тот же подход: compose сервисы, тома, health-check.
Следующий шаг: порядок применения миграций после восстановления.
Ring Platform не гарантирует фиксированные SLA восстановления в OSS-репозитории. Определяйте для каждого клона:
Задокументируйте ответственных за восстановление (оператор или разработчик) и где хранятся дампы (зашифрованное объектное хранилище, off-site).
AUTH_SECRET, ключи WayForPay и сервис-аккаунты Firebase хранятся в среде/Secret-сторах. Экспортируйте их менеджером паролей или workflow sealed-secrets — дампа Postgres недостаточно для восстановления авторизации.
lib/storage/storage-config.tsNEXT_PUBLIC_STORAGE_PROVIDERSTORAGE_PROVIDERring-config.jsonstorage.providerring_filebasering_filebasevercel_bloblocal_storagefirebase_storagefirebase-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-конфигурации; проверьте это на Архитектура аутентификации.
Публичный OSS-репозиторий не содержит k8s/ manifests (OSS vs enterprise). На управляемых кластерах обычно используется CloudNativePG ScheduledBackup в совместимое с S3 хранилище (например, MinIO). Runbooks операторов хранятся вне этого репозитория; настройте политику хранения копий согласно классу хранилища и требованиям off-site.
Восстановите последний дамп в стейджинговую БД (не production).
Запустите npm run build (или health check) с новым DATABASE_URL.
Проверьте логин, чтение одной сущности, просмотр списка возможностей и /api/health.
Запишите возраст дампа, длительность восстановления и пропущенные данные — пересмотрите расписание бэкапа при неудовлетворительном RPO.
Тот же подход: алертинг при фейле бэкап-джобов.
Ring Platform не гарантирует фиксированные SLA восстановления в OSS-репозитории. Определяйте для каждого клона:
Задокументируйте ответственных за восстановление (оператор или разработчик) и где хранятся дампы (зашифрованное объектное хранилище, off-site).
AUTH_SECRET, ключи WayForPay и сервис-аккаунты Firebase хранятся в среде/Secret-сторах. Экспортируйте их менеджером паролей или workflow sealed-secrets — дампа Postgres недостаточно для восстановления авторизации.
lib/storage/storage-config.tsNEXT_PUBLIC_STORAGE_PROVIDERSTORAGE_PROVIDERring-config.jsonstorage.providerring_filebasering_filebasevercel_bloblocal_storagefirebase_storagefirebase-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-конфигурации; проверьте это на Архитектура аутентификации.
Публичный OSS-репозиторий не содержит k8s/ manifests (OSS vs enterprise). На управляемых кластерах обычно используется CloudNativePG ScheduledBackup в совместимое с S3 хранилище (например, MinIO). Runbooks операторов хранятся вне этого репозитория; настройте политику хранения копий согласно классу хранилища и требованиям off-site.
Восстановите последний дамп в стейджинговую БД (не production).
Запустите npm run build (или health check) с новым DATABASE_URL.
Проверьте логин, чтение одной сущности, просмотр списка возможностей и /api/health.
Запишите возраст дампа, длительность восстановления и пропущенные данные — пересмотрите расписание бэкапа при неудовлетворительном RPO.
Тот же подход: алертинг при фейле бэкап-джобов.
Ring Platform не гарантирует фиксированные SLA восстановления в OSS-репозитории. Определяйте для каждого клона:
Задокументируйте ответственных за восстановление (оператор или разработчик) и где хранятся дампы (зашифрованное объектное хранилище, off-site).
AUTH_SECRET, ключи WayForPay и сервис-аккаунты Firebase хранятся в среде/Secret-сторах. Экспортируйте их менеджером паролей или workflow sealed-secrets — дампа Postgres недостаточно для восстановления авторизации.
lib/storage/storage-config.tsNEXT_PUBLIC_STORAGE_PROVIDERSTORAGE_PROVIDERring-config.jsonstorage.providerring_filebasering_filebasevercel_bloblocal_storagefirebase_storagefirebase-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-конфигурации; проверьте это на Архитектура аутентификации.
Публичный OSS-репозиторий не содержит k8s/ manifests (OSS vs enterprise). На управляемых кластерах обычно используется CloudNativePG ScheduledBackup в совместимое с S3 хранилище (например, MinIO). Runbooks операторов хранятся вне этого репозитория; настройте политику хранения копий согласно классу хранилища и требованиям off-site.
Восстановите последний дамп в стейджинговую БД (не production).
Запустите npm run build (или health check) с новым DATABASE_URL.
Проверьте логин, чтение одной сущности, просмотр списка возможностей и /api/health.
Запишите возраст дампа, длительность восстановления и пропущенные данные — пересмотрите расписание бэкапа при неудовлетворительном RPO.
Тот же подход: алертинг при фейле бэкап-джобов.