Что мы бэкапим, сколько храним и что значит «восстановить».

Бэкапы и retention

Эта страница — справочник: что в бэкапе, где он лежит, сколько живёт и что делает/не делает restore. Процедура «инженер на смене во время инцидента» — в DR runbook.

Что бэкапим

Компонент	Метод	Частота	Где
PostgreSQL (основная БД)	WAL-G continuous + базовые	WAL непрерывно + base ежедневно	Зашифрованный S3 в вашем регионе хранения
Typesense (данные поиска)	Snapshot API	Каждые 6 часов	Зашифрованный S3 в вашем регионе
Загруженные файлы (knowledge, аттачи)	Прямой S3 с cross-region replication	Real-time	S3 в регионе + cross-region реплика
Код и конфигурация приложения	Git (версионируется)	На деплой	GitHub
Audit log	То же, что PG (она в БД)	Непрерывно	То же, что PG

PostgreSQL-бэкапы — ground truth. Остальное либо смотрит в PG, либо реконструируется из неё.

Retention

Тип бэкапа	Retention
PostgreSQL WAL	30 дней (rolling)
PostgreSQL дневные base	30 дней (rolling)
Typesense snapshots	30 дней (rolling)
Загруженные файлы	Версионируются в S3; предыдущие версии — 30 дней
Audit log (в БД)	365 дней (Business+) / 90 дней (Starter), потом purge
Остатки удалённого аккаунта	Сертификат удаления в течение 30 дней после последнего дня сервиса

После окна retention данных нет. Не сохраним. Планируйте экспорты — см. экспорт аудита.

Что значит restore

Restore проигрывает WAL до целевого времени и поднимает БД на этой точке. Всё в БД откатывается одновременно. Восстановить данные одной организации, не трогая остальных, нельзя.

Если нужно только ваше — см. восстановление документов одного арендатора ниже: это путь через снапшоты, а не полный restore.

RTO и RPO

RTO (цель): 1 час для общего кластера.
RPO (цель): 15 минут для PostgreSQL, 6 часов для Typesense.

Typesense RPO выше, потому что мы восстанавливаем Typesense из снапшота плюс реиндексируем из PostgreSQL — зазор между последним снапшотом и инцидентом проигрывается из БД, у которой более короткий RPO.

Enterprise-клиенты согласовывают более жёсткие RTO/RPO на выделенном кластере — см. Dedicated cluster.

Восстановление документов одного арендатора

Если случайно удалили свои документы и хотите без нашего участия — путь зависит от источника истины:

Источник есть где-то ещё (БД продуктов). Прогоните через обычный ingest. Буфер их флашит, алиас обслуживает существующую коллекцию.
Источника нет. Тикет в течение 30 дней. Прогоним из нужного снапшота Typesense в новую коллекцию вашего проекта. Это не атомарный rollback — документы возвращаются на значения из снапшота, не на состояние до удаления, если в промежутке были апдейты.

Чужие данные восстанавливать в обход их владельца мы не будем. Правило двух лиц на recovery — такое же строгое, как на деплои.

Где лежат бэкапы

В зашифрованных S3-бакетах в том же регионе хранения, что и кластер, который они бэкапят. Кросс-регионной репликации бэкапов нет, если контрактно не запросили. Это правильный дефолт — перемещение бэкапов через регион меняет картину data residency.

Если по контракту нужен off-region бэкап — запрашивайте явно через Procurement.

Что не бэкапится

State браузера/мобайла. localStorage, in-memory кэш, scoped-токены в руках клиента. Эфемерно.
Ваши прикладные данные. Мы бэкапим search-индекс и нашу БД. Вашу e-commerce БД / CRM / CMS — вы.
API-ключи после revoke. Отозванный ключ не вернуть даже restore-ом. Сознательно — иначе security-regression.
Строки буфера старше 90 дней. Буфер rolling; после успешного flush или 90 дней failed — purge (audit log при этом сохраняет действие).

Как проверить бэкапы (с вашей стороны)

Self-serve verification мы не выставляем. Внутри прогоняем restore еженедельно на копии прода. Последний verification report — по запросу под NDA, см. Procurement.

Если нужны свои проверки — поддерживаемый путь: периодический экспорт:

Документы → searchIndex.export (CSV или NDJSON всех документов индекса)
Аудит → auditLog.export (см. экспорт аудита)
Синонимы, курации, аналитика — через соответствующие admin-эндпоинты

Кладите в своё object storage. Это и есть «customer-controlled backups» — наш restore никогда не отдаёт вам ваши данные в ваш регион.

Частые ошибки

Считать реиндекс — restore. Реиндекс собирает из вашего источника истины. Источник потерял — реиндекс не вернёт.
«Бэкапы хранятся вечно». Нет. 30-дневное скользящее окно. Нужны годы — экспортируйте.
«Восстановите аккаунт, удалённый вчера». Удаление финально через 30 дней. В эти 30 дней — срочно к sales, recovery возможен, но через amendment.

См. также

DR runbook — процедура инженера на смене
Экспорт аудита — как держать свои копии
Регион хранения — почему бэкапы регионально

Бэкапы и хранение данных