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

Оператор: Индивидуальный предприниматель Аведикян Карен Самвелович ИНН: (указать в реквизитах) ОГРНИП: (указать в реквизитах) Домен: 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. Восстановление данных

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

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

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

Оператор фиксирует инцидент в журнале событий (см. Политика защиты данных, раздел «Реагирование на инциденты»).
Создаётся временный branch в Neon на точку до инцидента.
Проверяется целостность восстановленных данных (prisma migrate status, сверка checksums).
Восстановленные данные переносятся в production через направленные SQL-операции; полный ролл-бэк прода из бэкапа допускается только при утрате работоспособности системы.
По окончании временный 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 года.