Резервное копирование и восстановление данных

СТАНДАРТНАЯ ОПЕРАЦИОННАЯ ПРОЦЕДУРА

Резервное копирование и восстановление данных в компьютеризированной системе «n-tst.ru»

Номер СОП: СОП-КС-06

Версия: 1.0

Дата эффективности: 01.11.2026

Планируемая дата пересмотра СОП: 01.11.2028

           ФИО   Должность                                 Подпись   Дата

Утвердил Генеральный директор
Разработал Специалист по клиническим исследованиям

История изменений документа

Версия Дата эффективности Изменения Необходимость тренинга

СОП-КС-06, версия 1.0 01.11.2026 Первоначальный документ. Да

  1. НАЗНАЧЕНИЕ ПРОЦЕДУРЫ

Настоящая процедура устанавливает порядок резервного копирования (Backup) и восстановления (Restore) данных компьютеризированной системы «n-tst.ru». Целью процедуры является обеспечение сохранности и доступности первичных данных клинического исследования (eCRF), а также минимизация рисков потери данных в случае сбоев оборудования, человеческого фактора или кибератак.

  1. ОБЛАСТЬ ПРИМЕНЕНИЯ

Процедура применима к серверной инфраструктуре, базе данных (PostgreSQL) и исходному коду программного обеспечения (Backend/Frontend), развернутым в Production-среде системы «n-tst.ru».

  1. НОРМАТИВНО-ПРАВОВАЯ БАЗА

    • Решение Совета Евразийской экономической комиссии № 63 от 01.08.2025 г. (п. 5.5.3, 5.5.4).

    • 21 CFR Part 11: Electronic Records; Electronic Signatures (США).

    • ISPE GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems..

  2. ОПРЕДЕЛЕНИЯ И СОКРАЩЕНИЯ

Термин Определение

Полный бэкап (Full Backup) Резервная копия всей базы данных и кода, содержащая все данные на момент создания. RPO (Recovery Point Objective) Целевая точка восстановления. Максимально допустимый период времени, за который данные могут быть потеряны (для данной системы --- 24 часа). RTO (Recovery Time Objective) Целевое время восстановления. Максимально допустимое время простоя системы с момента сбоя до полного восстановления (для данной системы --- 4 часа). Cron Планировщик задач в операционной системе Linux, обеспечивающий автоматический запуск скриптов. pg_dump Стандартная утилита PostgreSQL для создания логических дампов базы данных.

  1. ОБЯЗАННОСТИ

<!-- -->
1. Администратор системы (IT): обеспечивает настройку Cron-задач, ежемесячное тестирование процедуры восстановления на тестовом стенде (Staging) и ведение Журнала резервного копирования.

  1. QA (Гарантия качества): проводит периодический аудит (не реже 1 раза в квартал) наличия и целостности файлов резервных копий. Утверждает результаты тестовых восстановлений.

  2. Разработчик: предоставляет актуальные скрипты резервного копирования при изменении структуры БД или кода.

<!-- -->
6. ОПИСАНИЕ ПРОЦЕДУРЫ

6.1. Состав резервной копии

В состав резервной копии входят:

  1. Дамп базы данных (Формат pg_dump -F c): cодержит все данные клинического исследования (пациенты, визиты, аудит, подписи).

  2. Архив исходного кода (Формат tar.gz): cодержит актуальные версии файлов Backend и Frontend (без папки node_modules).

6.2. Частота выполнения и хранение

  • Ежедневно (в 03:00 по МСК): Автоматический запуск скрипта backup_irk.sh.

  • Еженедельно: полная копия переносится на внешний (off-site) сервер для защиты от физической потери основного сервера.

  • Срок хранения: ежедневные бэкапы хранятся в течение 30 календарных дней. Бэкапы, сделанные перед процедурой «Управления изменениями» (Change Control), хранятся до конца клинического исследования.

6.3. Процедура автоматического резервного копирования

  1. В 03:00 Cron автоматически запускает скрипт /root/scripts/backup_irk.sh.

  2. Скрипт создает дамп базы данных: pg_dump -d irk_db -F c -f /root/backups/irk_db_YYYY-MM-DD.dump.

  3. Скрипт архивирует код: tar -czf /root/backups/irk_code_YYYY-MM-DD.tar.gz /var/www/irk/backend /var/www/irk/frontend --exclude=\'node_modules\'.

  4. Скрипт автоматически удаляет файлы старше 30 дней.

  5. Администратор системы раз в неделю проверяет логи выполнения Cron и наличие файлов в директории /root/backups/.

6.4. Процедура восстановления данных (Restore)

Восстановление выполняется Администратором системы только в случае критического сбоя или по запросу Владельца системы.

  1. Остановить сервис бэкенда: systemctl stop irk-backend.

  2. Пересоздать базу данных (при необходимости): удалить текущую и создать пустую irk_db.

  3. Восстановить дамп базы: pg_restore -d irk_db /root/backups/irk_db_YYYY-MM-DD.dump.

  4. Распаковать код (если требуется откат версии): tar -xzf /root/backups/irk_code_YYYY-MM-DD.tar.gz -C /var/www/irk/.

  5. Запустить сервис бэкенда: systemctl start irk-backend.

  6. Проверить работоспособность системы через эндпоинт curl -s http://127.0.0.1:3000/api/health.

  7. Зафиксировать факт восстановления в Журнале восстановления (Приложение 2).

6.5. Верификация (Тестирование восстановления)

Не реже одного раза в месяц Администратор системы обязан провести тестовое восстановление:

  • Создать временную базу данных irk_db_test.

  • Развернуть в неё последний дамп.

  • Убедиться, что данные считываются (выполнить тестовый SELECT-запрос, например, к таблице patients).

  • Оформить Акт тестирования восстановления (Приложение 3).

  • ПЕРЕЧЕНЬ ПРИЛОЖЕНИЙ

Приложение 1. Журнал резервного копирования.

Приложение 2. Журнал восстановления данных.

Приложение 3. Акт тестирования процедуры восстановления.

Приложение 1. Журнал резервного копирования.

Дата Время Тип (БД / Код) Имя файла Размер (КБ) Статус (Успех/Ошибка) Подпись администратора

Приложение 2. Журнал восстановления данных

(Заполняется только в случае реального сбоя)

Дата и время сбоя Причина сбоя Дата и время восстановления Использованный бэкап (Имя файла) RTO (Факт. время) Подпись QA

Приложение 3. Акт тестирования процедуры восстановления

(Заполняется ежемесячно при тестовом развертывании)

  1. Дата тестирования: «___» _________ 20__ г.

  2. Тестируемый бэкап: ___________________________

  3. Среда восстановления (Staging): [ ] irk_db_test

  4. Результаты проверки (чек-лист):

  5. Дамп БД успешно развернут без ошибок.

  6. Таблицы patients, visits, electronic_signatures содержат данные.

  7. Сервис irk-backend успешно запускается и отвечает на запросы.

  8. Хеш-сумма восстановленного файла совпадает с оригиналом (если применимо).

  9. Заключение: Процедура восстановления прошла успешно. Данные целостны и доступны.

  10. Подпись исполнителя (IT): _____________ / _____________ / «__» _____ 20__ г.

  11. Подпись QA: _____________ / _____________ / «__» ______ 20__ г.