# Политика резервного копирования персональных данных

**Оператор:** Индивидуальный предприниматель Аведикян Карен Самвелович
**ИНН:** *(указать в реквизитах)*
**ОГРНИП:** *(указать в реквизитах)*
**Домен:** [remcard.ru](https://remcard.ru)
**Редакция:** 1.0 от 24 апреля 2026 года
**Основание:** Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных» (ст. 18.1, 19), Постановление Правительства РФ от 01.11.2012 № 1119.

---

## 1. Назначение документа

Настоящая Политика определяет правила резервного копирования, восстановления и уничтожения резервных копий информационных систем Оператора, в которых обрабатываются персональные данные (далее — ПДн), в том числе данные клиентов, партнёров и их сотрудников.

## 2. Область действия

Политика распространяется на все среды обработки ПДн:

- **Production-база данных** — PostgreSQL под управлением Neon Inc. (регион Frankfurt, проект `dawn-mountain-28018070`), содержит основную БД `User`, `Project`, `ClientOrder`, `Consent`, `AuditLog` и иные модели, перечисленные в `prisma/schema.prisma`.
- **Файловое хранилище** — S3-совместимое хранилище Yandex Object Storage (регион `ru-central1`), используется для аватаров, вложений обращений и экспортов.
- **Среды preview и development** — не содержат реальных ПДн, в них используются тестовые фикстуры.

## 3. Режим резервного копирования

### 3.1. Provider-managed бэкапы PostgreSQL

Резервное копирование production-базы выполняется провайдером Neon в автоматическом режиме средствами платформы:

- **Point-in-Time Recovery (PITR)** — непрерывная запись WAL-журнала, глубина восстановления — **7 календарных дней** от момента обращения.
- **Именованные снапшоты** — создаются Оператором перед миграциями, меняющими структуру или объём ПДн (например, `pre-p120a-wipe-2026-04-23`). Срок хранения снапшота — **не более 14 календарных дней**, после чего снапшот удаляется вручную.

### 3.2. Резервное копирование файлового хранилища

Yandex Object Storage обеспечивает геораспределённую репликацию объектов в пределах региона `ru-central1`. Версионирование включено; предыдущие версии хранятся **30 календарных дней**, после чего удаляются автоматически.

### 3.3. Локальные дампы

Локальные дампы БД (`pg_dump`) на рабочих станциях Оператора **запрещены**. При необходимости отладки используется read-only branch в Neon, удаляется немедленно по окончании работы.

## 4. Защита резервных копий

- Бэкапы Neon шифруются провайдером «в покое» алгоритмом AES-256, ключи управляются Neon (режим KMS).
- Доступ к консоли Neon имеет только Оператор; аутентификация — OAuth через корпоративный Google-аккаунт с включённой двухфакторной аутентификацией.
- Доступ к консоли Yandex Cloud — аналогично, под учётной записью Оператора с 2FA и SMS-подтверждением.
- Экспорт бэкапов за пределы консоли провайдера **запрещён**, за исключением случаев, предусмотренных п. 5.

## 5. Восстановление данных

Восстановление данных из резервной копии допускается в следующих случаях:

1. Аварийное повреждение production-базы.
2. Ошибочное удаление или изменение данных Оператором.
3. Запрос субъекта ПДн о восстановлении его данных, если утрата произошла по вине Оператора.
4. Требование уполномоченного государственного органа (РКН, суд, следственные органы).

Процедура восстановления:

1. Оператор фиксирует инцидент в журнале событий (см. Политика защиты данных, раздел «Реагирование на инциденты»).
2. Создаётся временный branch в Neon на точку до инцидента.
3. Проверяется целостность восстановленных данных (`prisma migrate status`, сверка checksums).
4. Восстановленные данные переносятся в production через направленные SQL-операции; **полный ролл-бэк прода из бэкапа допускается только при утрате работоспособности системы**.
5. По окончании временный branch удаляется; факт восстановления заносится в `AuditLog` с action `DATA_RESTORED`.

## 6. Уничтожение резервных копий

- PITR-окно — 7 дней, далее старые WAL-сегменты удаляются провайдером автоматически.
- Именованные снапшоты — удаляются Оператором вручную не позднее 14 дней после создания.
- Версии файлов в Object Storage — удаляются автоматически через 30 дней.
- При прекращении обработки ПДн конкретного субъекта (см. ст. 21 ФЗ-152) **дополнительная очистка резервных копий не выполняется**: уничтожение данных субъекта производится в production-среде; ожидается, что через 7 дней (окно PITR) сведения о субъекте исчезнут из всех активных копий естественным образом. До истечения этого срока бэкапы имеют статус «ограниченный доступ — только для восстановления».

## 7. Контроль исполнения

Ответственный за исполнение Политики — сам Оператор. Проверка выполнения:

- Ежеквартально — проверка доступности и корректности PITR (создание тестового branch, `SELECT count(*) FROM "User"`).
- При каждом значимом инциденте — запись в `AuditLog`.
- При изменении архитектуры хранения — пересмотр Политики.

## 8. Действие и пересмотр

Политика вступает в силу с момента утверждения и действует бессрочно. Пересмотр — не реже одного раза в год или при существенном изменении состава обрабатываемых ПДн, перечня используемых провайдеров, требований законодательства.

---

**Утверждено:** ИП Аведикян К.С., 24 апреля 2026 года.