docs(backups): стратегия бэкапов PostgreSQL (RPO/RTO), проверка восстановления

Шаг 1.8 плана production-готовности: дамп 2026-09-07 03:00 восстановлен
в scratch-БД без ошибок (125 таблиц), процедура задокументирована в DOCKER.md

DOCKER.md

@@ -278,3 +278,34 @@ docker compose --profile with-postgres --profile with-minio --profile with-ollam
 | + MinIO + WebDAV (без PostgreSQL) | `docker compose --profile with-minio up --build` |
 | + локальные LLM (Ollama) | `docker compose --profile with-ollama up --build` |
 | Всё сразу | `docker compose --profile with-postgres --profile with-minio --profile with-ollama up --build` |
+
+---
+
+## Бэкапы PostgreSQL (production)
+
+**Автоматические (на сервере, cron):**
+- 3:00 — `pg_dump -Fc | gzip` → `/opt/crm/backups/crm-YYYYMMDD-HHMMSS.dump.gz` (скрипт `/opt/crm/scripts/backup-db.sh`), ротация 14 дней;
+- 3:30 — CSV-экспорт основных таблиц → `/opt/crm/backups/csv/YYYYMMDD-HHMMSS/` (скрипт `/opt/crm/scripts/backup-csv.sh`), 7 копий;
+- логи: `/var/log/crm-backup.log`.
+
+**RPO/RTO:**
+- RPO (точка потери данных): до 24 часов (дамп раз в сутки). Для уменьшения — чаще расписание или WAL-архивация (не настроено).
+- RTO (время восстановления): ~15–30 минут (остановка app, pg_restore ~11 МБ дампа за минуты, запуск).
+
+**Восстановление из дампа:**
+```bash
+docker compose stop app document-worker
+docker exec crm-db-1 psql -U appuser -d postgres -c 'DROP DATABASE appdb'
+docker exec crm-db-1 psql -U appuser -d postgres -c 'CREATE DATABASE appdb'
+zcat /opt/crm/backups/crm-<дата>.dump.gz | docker exec -i crm-db-1 pg_restore -U appuser -d appdb --no-owner --no-privileges
+docker compose up -d
+```
+
+**Проверка восстановления:** выполнена 2026-09-07 — дамп за 03:00 восстановлен в scratch-БД без ошибок (125 таблиц, данные консистентны). Повторять такую проверку после изменений схемы бэкапа.
+
+**Не входит в pg_dump (бэкапить отдельно):**
+- файлы MinIO (`minio_data`) — tar volume вручную;
+- модели Ollama (`ollama_data`) — tar volume вручную;
+- `/app/data` (`crm_data` — JSON-конфиги финансов, google-токены).
+
+**Известный риск:** бэкапы лежат на том же VPS — при отказе диска/сервера потеряются вместе с продом. Требуется выгрузка наружу (S3/другой хост) — в бэклоге.

IMPLEMENTATION_LOG.md

@@ -267,3 +267,13 @@
   - `server/index.ts` — redactSensitive() в captureErrorLog: маскировка password/token/secret/Bearer в записываемых сообщениях.
 - Как проверялось: auth-роуты возвращают статичные тексты без секретов; vitest 96/96.
 - Влияние на поиск/UX: нет.
+
+---
+
+## [1.8] Бэкапы PostgreSQL: документирование + проверка восстановления
+
+- Статус: ✅ done
+- Зачем: задокументированная стратегия восстановления (RPO/RTO), подтверждённая практикой (Фаза 1).
+- Что изменено: `DOCKER.md` — раздел «Бэкапы PostgreSQL (production)»: расписание (3:00 pg_dump + 3:30 CSV, ротация 14/7), RPO 24ч/RTO 15–30 мин, команды восстановления, что НЕ входит в дамп (MinIO/Ollama/crm_data), риск «бэкапы на том же VPS» (выгрузка наружу — в бэклог).
+- Как проверялось: восстановление свежего дампа (2026-09-07 03:00, 11 МБ) в scratch-БД на сервере — 0 ошибок pg_restore, 125 таблиц, 990 задач/49 пользователей/14 форм/6024 значений полей, последняя миграция 0078 (дамп предшествует 0079/0080 — консистентно). Scratch-БД удалена.
+- Влияние на поиск/UX: нет.