• Опубликовано: 20 сентября 2026 г.

Резервные копии клиники есть — а восстановление никто не проверял: честный тест

В отчёте зелёная строка: резервное копирование выполнено. Архив создан ночью, объём похож на вчерашний, уведомление пришло администратору. Кажется, ещё одна важная задача закрыта.

Но зелёная строка отвечает только на вопрос «процесс что-то записал». Она не говорит, есть ли внутри нужные данные, получится ли расшифровать архив, совместима ли версия программы, кто знает порядок запуска и сколько времени клиника проживёт без системы.

Бэкап становится защитой не после создания файла, а после спокойного восстановления в изолированной среде. До этого у организации есть надежда, а не доказательство.

Для клиники разница особенно заметна. Вернуть один документ — не то же самое, что восстановить МИС. Поднять сайт — не значит вернуть формы и почту. Скопировать каталог DICOM — не значит получить рабочий архив исследований и поиск. Каждая система имеет собственные зависимости, владельца и допустимое время простоя.

Хорошая проверка не должна рисковать production и не требует использовать реальные данные пациентов. Она начинается с карты сервисов, синтетического набора и честных критериев: что именно вернулось, за сколько, с какими потерями и кто смог повторить процедуру без автора инструкции.

Копирование и восстановление — два разных процесса

Задание резервного копирования читает данные из источника и записывает их в хранилище. Восстановление идёт в обратную сторону, но не является зеркальным нажатием кнопки. Оно требует целевой среды, совместимых версий, ключей, свободного места, сети, DNS, лицензий и порядка запуска компонентов.

Поэтому отчёт «backup successful» может сосуществовать с невозможностью вернуть систему. Типовые причины:

• копировался не тот каталог или не вся база;
• архив обрывался, но задача завершалась без критической ошибки;
• ключ шифрования потерян;
• учётная запись восстановления заблокирована;
• версия приложения не читает старый формат;
• резерв находится в том же контуре, что и повреждённая система;
• копия зависит от каталога пользователей или DNS, которые сами недоступны;
• инструкция предполагает знания бывшего подрядчика;
• восстановление никогда не проверялось на чистом сервере.

Зрелый журнал хранит отдельно факт создания копии, проверку целостности и результат контрольного восстановления. Эти события связаны, но не взаимозаменяемы.

Что именно клиника должна уметь вернуть

Фраза «мы копируем сервер» слишком широкая. Сервер — контейнер для разных процессов. Руководителю нужен каталог бизнес-возможностей, которые должны вернуться после сбоя.

Например:

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

RPO и RTO человеческим языком

Два термина полезны, если не превращать их в украшение документа.

RPO отвечает на вопрос: какой объём изменений клиника готова потерять по времени? Если копия создаётся раз в сутки, теоретическое окно потери может быть близко к суткам. Но реальный ответ зависит от журналов транзакций, репликации и конкретной системы.

RTO отвечает: сколько времени допустимо до возврата процесса? Не файла, а работающей функции. Архив может распаковаться за двадцать минут, а настройка лицензии и интеграций занять день.

Сначала обсуждайте не числа, а последствия. Что будет, если расписание недоступно два часа? Можно ли принимать звонки вручную? Как сверить внесённые на бумаге изменения после возврата? Что произойдёт, если PACS недоступен дольше? Кто принимает решение о переносе пациентов?

После этого значения становятся управленческими, а не техническими. Они помогают выбрать частоту копий, инфраструктуру и порядок восстановления.

Карта зависимостей важнее размера архива

Система редко восстанавливается одна. МИС может зависеть от базы, каталога пользователей, лицензии, файлового хранилища и сетевых маршрутов. Сайт — от DNS, сертификата, базы и внешних форм. PACS — от хранилища объектов, индекса, DICOM-настроек и прав.

Нарисуйте граф простыми стрелками:

идентификация → DNS/сеть → хранилище → база → приложение → интеграции → пользовательская проверка

Для каждого узла запишите владельца и способ восстановления. Если база поднялась, но никто не знает пароль сервисной учётной записи, процесс не вернулся. Если файлы на месте, а индекс не восстановлен, поиск не работает. Если сайт открыт, но заявки отправляются в несуществующий webhook, клиника продолжает терять обращения.

Материал о том, почему простой файловый менеджер не заменяет сетевое хранилище, полезен здесь как напоминание: каталог, индекс, рабочее хранилище и резервная копия выполняют разные роли. Один инструмент не должен изображать сразу всё.

Правило 3-2-1 — начало разговора, а не сертификат безопасности

Часто используют ориентир: несколько копий, разные носители, одна копия вне основного контура. Принцип помогает избежать единственной точки отказа, но сам по себе ничего не говорит о полноте, шифровании, неизменяемости и проверке.

Три файла с одной ошибочной базой остаются тремя плохими копиями. Облачная копия под теми же скомпрометированными полномочиями может быть удалена вместе с основной. Офлайн-носитель бесполезен, если его невозможно прочитать или он не обновлялся год.

Руководство CISA по ransomware рекомендует поддерживать offline и зашифрованные копии критичных данных, регулярно проверять их доступность и целостность в сценарии восстановления и возвращать сервисы по заранее определённому приоритету. Это хороший каркас, но конкретная архитектура клиники требует собственного проектирования.

Изоляция от основной среды

Контрольное восстановление не должно случайно подключиться к production-базе, разослать пациентам сообщения или перезаписать рабочие файлы. Тестовый контур проектируют заранее.

Минимальные меры:

• отдельная сеть или жёстко ограниченный сегмент;
• тестовые DNS-имена;
• запрет исходящих сообщений или подмена шлюзов;
• синтетические данные;
• отдельные учётные записи;
• отсутствие маршрута к медицинскому оборудованию;
• контроль внешних интеграций;
• ограниченный срок жизни среды;
• журнал действий и последующее безопасное удаление.

Не переносите production dump «на ноутбук для проверки». Если тест требует реальных данных, это отдельное решение с правовым, организационным и техническим контролем. Для большинства базовых сценариев можно подготовить синтетический набор, который проверяет структуру и функциональность без ПДн.

Синтетический набор должен быть умным

Пустая база подтверждает только запуск приложения. Подготовьте набор, который проверяет важные отношения:

• несколько тестовых ролей с разными правами;
• вымышленные пациенты;
• расписание с кабинетами и ресурсами;
• отменённый и перенесённый визит;
• тестовый документ;
• специально созданный набор изображений без данных реального пациента;
• тестовая заявка сайта;
• один сценарий ошибки.

У каждого элемента есть ожидаемый результат. Например, регистратор видит расписание, но не административные настройки; форма создаёт заявку в тестовой очереди; файл открывается и имеет контрольную сумму; тестовое исследование находится по синтетическому идентификатору.

Так восстановление проверяет работу системы, а не только наличие файлов.

Ключи и доступы часто ломают восстановление раньше дисков

Архив зашифрован — хорошо. Но где ключ? Кто имеет право его получить? Сможет ли второй ответственный сделать это ночью? Не зависит ли хранилище ключей от того же каталога, который требуется восстановить?

Для каждого критичного секрета фиксируют не значение, а маршрут:

• владелец;
• резервный владелец;
• место защищённого хранения;
• условие выдачи;
• журнал доступа;
• порядок ротации;
• процедура при компрометации;
• независимость от восстанавливаемого контура.

В статье о двухфакторной защите и резервном восстановлении доступа разобрано, почему второй фактор без recovery способен сам стать точкой отказа. Для бэкапов это критично: защита от злоумышленника не должна исключать восстановление уполномоченной командой.

Полная копия виртуальной машины не гарантирует запуск

Снимок ВМ выглядит удобным: один большой объект, который можно вернуть целиком. Но внутри могут быть несогласованные состояния приложения и базы. Snapshot иногда зависит от цепочки дисков. После запуска обнаруживаются старые IP-адреса, конфликт имени, неподходящие драйверы или истёкшая лицензия.

Поэтому тест включает:

1. развертывание на альтернативной платформе или в изолированном контуре;
2. проверку целостности дисков;
3. запуск служб в правильном порядке;
4. контроль БД;
5. вход тестовой ролью;
6. функциональный сценарий;
7. измерение времени;
8. очистку среды.

NIST SP 800-34 Rev. 1 рассматривает тестирование плана как способ найти и исправить недостатки, включая восстановление на альтернативной платформе, связность, производительность и возврат к штатной работе. Это федеральное руководство США, а не обязательная норма для российской клиники, но структура проверки практически полезна.

База данных требует своего сценария

Копирование файлов работающей БД без поддержки согласованного backup может дать набор, который невозможно надёжно открыть. Конкретный механизм зависит от СУБД и приложения: дамп, физическая копия, журнал транзакций, snapshot с координацией.

Проверяйте:

• завершился ли штатный механизм backup;
• читается ли каталог копии;
• есть ли контрольные суммы;
• совпадает ли версия СУБД;
• восстанавливаются ли пользователи и права;
• применяются ли журналы до нужной точки;
• работает ли приложение поверх восстановленной базы;
• не содержит ли лог теста секреты и данные.

Не используйте production как площадку эксперимента. Восстановление поверх работающей базы без отдельного плана может превратить учебную проверку в настоящий инцидент.

PACS и DICOM: наличие файлов не равно рабочему архиву

В каталоге могут лежать тысячи объектов, но врач не найдёт исследование через интерфейс. Нужны индекс, метаданные, связи, настройки хранилища и проверка отображения. При переносе также важны UID, порядок серий и совместимость просмотрщика.

Тестируйте только на разрешённом синтетическом наборе, не копируйте реальные DICOM на случайные рабочие станции и не публикуйте их в тикетах. Проверка должна ответить:

• объект принят;
• индекс обновлён;
• исследование находится;
• серии открываются;
• права работают;
• исходный тестовый набор не изменён;
• результат можно удалить по процедуре.

Связанные архитектурные различия между рабочей станцией, PACS, архивом и backup разобраны в статье о том, почему нельзя хранить исследования КТ на одном компьютере.

Облако не отменяет ответственность клиента

Фраза «это в облаке» не говорит, что именно резервирует провайдер. Некоторые сервисы защищают инфраструктуру, но восстановление удалённого пользователем объекта, срок версий и экспорт остаются зоной клиента. SaaS может иметь корзину, но она не равна независимой копии.

По каждому облачному сервису выясните:

• какие данные входят в backup;
• где граница ответственности;
• каков срок хранения версий;
• можно ли экспортировать данные;
• кто может удалить копии;
• есть ли immutable/object lock и как он настроен;
• что произойдёт при блокировке аккаунта;
• как восстановиться к другому поставщику;
• какой выходной формат доступен.

Не обещайте «георезервирование», пока нет документации и теста. Архитектурный выбор локальной, облачной и гибридной модели подробнее разобран в материале «Нужен ли клинике собственный сервер в 2027 году».

Составной сценарий: архивы зелёные, ключа нет

Ниже — иллюстративная реконструкция, не кейс конкретной клиники.

Ночной отчёт несколько лет показывал успешное копирование файлового сервера. После замены оборудования команда решила впервые поднять тестовую копию. Архивы оказались зашифрованы, а путь к ключу в инструкции вёл в личное облако бывшего подрядчика. Сам подрядчик отвечал, но не мог быстро найти нужную версию.

Production не пострадал: проверку проводили в отдельной сети на синтетическом наборе. Команда не стала отключать шифрование. Она создала новый управляемый ключ, оформила двух владельцев, сделала полную копию и повторила восстановление. Затем обнаружила второй разрыв: инструкция предполагала старую версию программы, которая уже не устанавливалась на новый сервер.

За один тест нашлись две проблемы, которые ежедневная зелёная строка не могла увидеть. Ценность проверки была не в красивом времени восстановления, а в том, что слабые места обнаружились в спокойный день.

Кто участвует в тесте

Если восстановление выполняет только автор системы, клиника проверяет его память, а не процесс. Минимальная команда включает:

• владельца бизнес-процесса;
• технического исполнителя;
• второго специалиста или наблюдателя;
• ответственного за данные и безопасность;
• пользователя, который подтверждает функциональный результат;
• руководителя, принимающего остаточный риск.

Роли не обязательно занимают разные люди в небольшой организации, но решения должны быть разделены. Технический специалист сообщает, что база поднялась. Владелец процесса подтверждает, что можно выполнить нужную работу. Ответственный за данные проверяет границы тестового контура.

Как составить runbook, который переживёт отпуск автора

Инструкция должна быть исполнима, но не превращаться в публичный сборник секретов. Хороший runbook содержит:

1. условие запуска;
2. владельца решения;
3. приоритет сервисов;
4. требования к чистой среде;
5. ссылки на защищённые секреты;
6. порядок развертывания;
7. контрольные точки;
8. критерии остановки;
9. функциональную приёмку;
10. возврат к штатной работе;
11. сбор уроков;
12. очистку тестовой среды.

Фразы «настроить как обычно» и «спросить Сергея» — дефекты. Версии, зависимости и владельцы должны быть конкретными. При этом пароль, ключ шифрования и персональные данные в документ не вставляются.

Дайте runbook сотруднику, который не участвовал в настройке. Наблюдайте, где он задаёт вопрос. Каждая остановка — материал для улучшения, а не повод обвинять проверяющего.

Как измерять результат

Тест нельзя оценивать только словами «в целом получилось». Запишите:

Не сравнивайте разные системы одним нормативом. Восстановление статического сайта и PACS несопоставимо. Динамика по одному контуру полезнее рейтинга между сервисами.

Частичный тест, tabletop и полноценное упражнение

Не каждую неделю нужно поднимать весь контур. Используйте уровни.

Tabletop. Команда проходит сценарий по документам: кто звонит, где ключ, что восстанавливается первым. Это быстро выявляет неясные роли, но не доказывает техническую работоспособность.

Проверка объекта. Восстановление файла, базы или небольшой ВМ в изоляции. Проверяет конкретный механизм.

Функциональный тест. Пользователь проходит бизнес-сценарий на восстановленной системе.

Комплексное упражнение. Несколько зависимых систем возвращаются в порядке приоритета с проверкой коммуникации и ручного режима.

Частота определяется критичностью, изменениями и результатами прошлых тестов. После обновления платформы, смены подрядчика, миграции или изменения шифрования тест нужен раньше плановой даты.

Когда тест нужно остановить

Критерии остановки защищают production и данные. Прекратите упражнение, если:

• тестовая среда получила маршрут к рабочим пациентским данным;
• внешние уведомления могут уйти реальным адресатам;
• обнаружен неизвестный ключ или учётная запись;
• восстановление требует отключить действующую защиту production;
• не хватает свободного места и есть риск затронуть рабочее хранилище;
• версия или лицензия не подтверждены;
• нельзя отличить тестовую запись от рабочей;
• появился признак настоящего инцидента.

Остановка не является провалом. Это успешное обнаружение границы, которую нужно исправить до следующей попытки.

Что делать после неудачного теста

Не удаляйте отчёт и не повторяйте сразу теми же руками. Зафиксируйте:

• на каком шаге остановились;
• ожидаемый и фактический результат;
• влияние на RPO/RTO;
• временную компенсацию;
• владельца исправления;
• дату повторной проверки.

Если повреждена последняя копия, проверьте предыдущие поколения, но не объявляйте их рабочими без восстановления. Если отсутствует ключ, эскалируйте как проблему управления доступами. Если копия заразилась вместе с production, подключайте процесс реагирования, а не обычную процедуру восстановления.

План первых действий при шифровальщике вынесен в отдельный материал о 48 часах после ransomware-инцидента в клинике. Не смешивайте учебный restore и живое расследование: во втором случае важно сохранить доказательства и не заразить чистый контур.

План безопасного теста на две недели

День 1. Выберите один процесс и владельца.

День 2. Опишите данные, зависимости, RPO и RTO как бизнес-последствия.

День 3. Подготовьте синтетический набор и ожидаемые результаты.

День 4. Проверьте копии, контрольные суммы, ключи и доступы без распаковки в production.

День 5. Спроектируйте изолированную среду и критерии остановки.

День 6. Проведите tabletop с владельцем процесса и вторым исполнителем.

День 7–8. Выполните техническое восстановление.

День 9. Проведите функциональную приёмку.

День 10. Измерьте фактические RPO/RTO и ручные шаги.

День 11. Закройте тестовый контур и удалите временные данные по процедуре.

День 12. Выпустите отчёт без секретов и ПДн.

День 13. Исправьте runbook и назначьте владельцев.

День 14. Утвердите повторный тест и следующий контур.

Не обещайте восстановление всей клиники на основании одного частичного теста. Результат относится только к проверенному сценарию, версии и дате.

FAQ

Нужно ли восстанавливать всю систему при каждом тесте?

Нет. Используйте уровни: tabletop, восстановление объекта, функциональный тест и комплексное упражнение. Но периодически критичный процесс должен пройти путь целиком, включая пользовательскую приёмку.

Можно ли тестировать на рабочих данных?

По умолчанию используйте синтетический или надлежащим образом подготовленный обезличенный набор в изолированном контуре. Не переносите production dump на случайное устройство. Исключения требуют отдельного согласования и контроля.

Как часто проверять восстановление?

По критичности и изменениям. После миграции, обновления, смены ключей или подрядчика тест проводят вне очереди. Периодичность фиксирует организация, а не универсальная статья.

Что делать, если копия повреждена?

Остановить сценарий, сохранить доказательства, проверить другие поколения и исправить причину. Не считать предыдущую копию рабочей, пока она фактически не восстановлена.

Кто принимает результат?

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

Облачный snapshot считается резервной копией?

Он может быть частью стратегии, но нужно проверить независимость полномочий, срок хранения, неизменяемость, восстановление на другой ресурс и фактическую работоспособность приложения.

Что сделать завтра

Выберите один небольшой процесс, который не требует реальных данных: например, восстановление тестовой версии сайта с синтетической формой или каталога из заранее созданных файлов.

До начала запишите четыре утверждения:

1. что именно должно вернуться;
2. где будет поднята изолированная среда;
3. кто подтверждает технический и пользовательский результат;
4. при каком событии тест немедленно останавливается.

Затем попросите второго человека найти ключи, инструкцию и последнюю копию, не подсказывая устно. Если он не может начать, уже найден полезный разрыв. Не обходите его звонком автору — исправьте маршрут.

Резервная копия не обязана обещать невозможное. Она должна честно показывать, какой процесс клиника умеет вернуть, на какую точку, за какое подтверждённое время и с какими зависимостями. Один спокойный тест даёт больше уверенности, чем год зелёных уведомлений.

Материал носит информационный характер и не заменяет аудит информационной безопасности, план непрерывности, юридическое заключение или инструкции производителей. Не используйте реальные персональные данные, DICOM, записи разговоров, production dumps и секреты в учебном контуре без отдельного разрешённого процесса. Любое восстановление выполняйте с критериями остановки и защитой работающей среды.