Резервное копирование в стоматологии: как вернуть данные

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

Разберём, как составить такой план и что спросить у поставщика МИС — медицинской информационной системы, в которой клиника ведёт приём и документацию.

Резервная копия, синхронизация, зеркало и архив — зачем различать термины

Эти четыре слова в разговоре с ИТ-подрядчиком часто звучат как синонимы, но по сути это разные вещи. Если руководитель клиники путает их, можно принять доступность файлов за возможность восстановить их прежнее состояние.

Резервная копия, или бэкап (от английского backup — дублирование) — это отдельная версия данных, сделанная на определённый момент времени и хранящаяся независимо от рабочей системы. Если сегодня вечером вы скопировали базу, а завтра в обед кто-то случайно удалил записи пациентов, отдельная сохранённая версия позволит попытаться восстановить состояние на момент копирования.

Для этого сама копия должна быть исправной и защищённой от последующей перезаписи.

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

Зеркало дисков — один из способов повышения устойчивости оборудования. Оно может быть реализовано средствами RAID (redundant array of independent disks — избыточный массив независимых дисков). У RAID есть разные схемы, и не каждая выдерживает отказ накопителя; зеркалирование позволяет продолжить работу при предусмотренном схемой отказе.

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

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

Что именно нужно сохранять: карта данных клиники

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

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

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

Снимки КЛКТ (конусно-лучевая компьютерная томография — трёхмерный рентгеновский снимок челюсти) и панорамные снимки — обычно это крупные файлы, которые лежат на отдельной станции рентген-кабинета или в архиве изображений (PACS — система хранения и передачи медицинских изображений). Их объём быстро растёт, и именно они чаще всего «не помещаются» в стандартный бэкап, если про них забыли на этапе планирования.

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

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

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

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

RPO и RTO простыми словами — сколько часов клиника готова потерять

Два термина, без которых разговор о резервном копировании превращается в абстрактные рассуждения про «надёжность». RPO (recovery point objective — целевая допустимая потеря данных по времени) отвечает на вопрос: сколько данных по времени клиника готова потерять, если сбой случится прямо сейчас.

RTO (recovery time objective — целевое время восстановления работы) отвечает на другой вопрос: сколько времени клиника готова простоять без работающей системы, пока всё не вернётся в строй.

Разница принципиальная. RPO — это про объём потерянной информации, RTO — про простой в работе. Можно иметь отличный RPO (копия делается каждый час) и при этом ужасный RTO (восстановление из этой копии займёт два дня, потому что никто не проверял процесс заранее).

Условный пример редакции: последняя исправная копия создана вчера в 22:00, сбой произошёл сегодня в 15:00. Между этими моментами 17 часов. Из одной этой копии не вернуть изменения за такой интервал; возможность восстановить их из других источников проверяют отдельно. Если клиника заранее установила RPO в 4 часа, текущая схема этой цели не достигла.

Аналогично, при целевом RTO в 2 часа фактическое восстановление за 6 часов означает превышение цели на 4 часа.

RPO и RTO — целевые показатели, с которыми сравнивают результат проверки. Клиника сама определяет, сколько часов работы она готова потерять и сколько часов простоя допустима, исходя из своей нагрузки и рисков, а не берёт произвольное «копировать каждый час», если для этого нет оснований по объёму данных и стоимости хранения.

Правило 3-2-1 — инженерная рекомендация, а не гарантия

Правило 3-2-1 часто подаётся как магическая формула надёжности, хотя это обычная инженерная рекомендация, описанная в документах американского Национального института стандартов и технологий — NIST (National Institute of Standards and Technology). Отдельное хранение и проверку восстановления также рассматривает британский Национальный центр кибербезопасности — NCSC (National Cyber Security Centre).

Важно понимать: это не обязательная норма российского законодательства, а здравый инженерный подход, который можно адаптировать под размер клиники.

Суть правила простая. Три — нужно хранить минимум три копии важных данных: одну рабочую и две резервные. Два — копии должны лежать на двух разных типах носителей, чтобы одна и та же поломка (например, отказ конкретной модели диска) не затронула обе сразу.

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

Правило не говорит, с какой частотой делать копии и какой именно инструмент использовать — это клиника определяет сама исходя из RPO и RTO. 3-2-1 отвечает только на вопрос «сколько копий и где», но не отменяет необходимости проверять, что эти копии действительно открываются.

Как выбрать частоту копирования по риску, а не «на всякий случай каждый час»

Частота копирования — не универсальная цифра, а результат ответа на вопрос: сколько часов работы клиника готова потерять по каждому типу данных отдельно. Записи о приёмах и платежах обычно критичнее, чем, например, фотографии для портфолио врача, поэтому и частота копирования у них разная.

Ошибка, которую часто совершают, — настраивать копирование базы МИС каждый час «для надёжности», не считая, во что это обходится по нагрузке на сервер и объёму хранилища, и при этом не копировать снимки КЛКТ вообще, потому что «они и так лежат на диске аппарата». Частота должна быть осознанным выбором, а не привычкой.

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

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

Как правильно копировать базу МИС — и почему нельзя просто скопировать папку

Соблазн сэкономить время и просто скопировать папку с файлами базы МИС через проводник — понятен, но технически рискован. Большинство баз данных в момент работы держат файлы открытыми и периодически записывают в них информацию частями.

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

Производитель МИС обычно предоставляет штатный, совместимый способ создания копии: встроенную функцию экспорта базы, утилиту для снятия снимка в момент паузы записи, или интеграцию со стандартными средствами резервного копирования СУБД (системы управления базами данных), на которой построена МИС. Совместимый штатный способ уменьшает риск несогласованной копии.

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

Кто отвечает за копии: поставщик сервиса и клиника

Один из самых запутанных вопросов — где заканчивается ответственность облачного сервиса МИС и начинается ответственность самой клиники. Многие руководители искренне считают, что раз МИС облачная, то резервные копии «уже входят» в сервис и отдельно думать об этом не нужно. Это предположение стоит проверять в договоре, а не принимать на веру.

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

Граница ответственности прописывается в договоре на обслуживание, и если там нет отдельного пункта про резервное копирование данных клиента и условия его восстановления, предполагать это «по умолчанию» не стоит.

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

Шифрование копий и хранение ключей доступа

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

Шифрование данных в состоянии покоя (на диске) и при передаче (во время копирования по сети) снижает риск, что копия станет доступна посторонним при краже носителя или перехвате трафика. Но шифрование работает только вместе с грамотным управлением ключами доступа: если ключ доступен тому же постороннему лицу, что и копия, защита ослабевает.

Если ключ известен только одному недоступному сотруднику, клиника рискует сама не получить доступ к своему архиву.

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

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

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

Для проверки пригодности нужно открыть восстановленные данные в совместимом приложении.

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

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

Результат теста стоит фиксировать письменно: дату, кто проводил, что именно проверялось, сколько заняло восстановление, какие записи и снимки открылись корректно, а какие — нет. Без фиксации тест превращается в разовое действие, о котором никто не вспомнит через полгода.

Сколько времени займёт восстановление: условный расчёт редакции

Чтобы RTO не оставался абстрактным числом, полезно прикинуть хотя бы теоретический минимум времени восстановления по объёму данных и скорости канала связи. Это не обещание фактического срока — реальное восстановление почти всегда занимает дольше из-за проверки целостности, развёртывания системы, настройки и человеческого фактора.

Условный пример редакции: клиника хранит резервную копию объёмом 120 ГБ (гигабайт) в облачном хранилище, скорость интернет-канала для скачивания — 50 Мбит/с (мегабит в секунду). Переводим гигабайты в мегабиты: 120 ГБ × 8 = 960 Гбит, или 960 000 Мбит. Делим на скорость канала: 960 000 ÷ 50 = 19 200 секунд, это 320 минут, или 5 часов 20 минут.

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

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

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

Разговор с ИТ-подрядчиком или поставщиком МИС про резервное копирование стоит строить вокруг конкретных вопросов, а не общей фразы «у вас всё защищено?». Вот предметные вопросы, ответы на которые должны быть зафиксированы письменно:

1. Как создаётся согласованная копия базы МИС? Подтверждён ли способ её поставщиком?
2. Входят ли в копию вложения, снимки и файлы сканов? Где перечислены исключения?
3. Какой возраст последней исправной копии и соответствует ли он принятому RPO?
4. Где находится отдельный экземпляр и защищён ли он от удаления через обычную рабочую учётную запись?
5. Как защищены передача, носитель и ключи? Кто получит доступ при недоступности основного специалиста?
6. Когда провели последнее восстановление и сколько времени заняло открытие рабочей системы?
7. Какие данные проверили после запуска? Кто подтвердил результат и что осталось неисправным?

Для записи результата можно использовать такую форму редакции:

Журнал теста восстановления не обязан быть сложным документом — достаточно фиксировать несколько полей после каждой проверки: дата теста, кто проводил, какой тип данных восстанавливался, фактическое время восстановления от начала до рабочего состояния, что именно проверялось при открытии (карта, снимок, подписи, метаданные), результат — успешно или с замечаниями, и дата следующей плановой проверки.

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

Если инцидент уже случился: что делать и чего не делать

Если данные уже потеряны, повреждены или клиника подозревает заражение вредоносной программой, в первую очередь важно не усугубить ситуацию самостоятельными действиями. Любые шаги по восстановлению и анализу происшествия стоит согласовывать со специалистом — ИТ-подрядчиком или специализированной службой, а не предпринимать хаотично, пытаясь «быстро всё починить своими силами».

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

Также не стоит пытаться восстановить рабочую базу поверх повреждённой без предварительной проверки резервной копии в отдельном контуре — это рискует испортить и единственный рабочий бэкап.

Первый практический шаг — изолировать затронутую систему от сети, чтобы остановить возможное распространение проблемы, и связаться с тем, кто отвечает за резервное копирование по договору. Дальнейшие действия — восстановление из проверенной копии, оценка объёма потерь по сравнению с последним актуальным бэкапом — выполняются по согласованному со специалистом плану, а не методом проб и ошибок на живой системе.

Если клиника планирует разбираться в комплектации рабочего места и инфраструктуре клиники системно — в том числе понять, какие узлы вообще формируют цифровой контур клиники и как они связаны между собой, от МИС до рентген-кабинета и цифровой лаборатории, — на DentalPortal.pro собраны предложения поставщиков оборудования и ИТ-услуг: можно сравнить условия и запросить документы, по интересующим классам оборудования и условиям обслуживания.

Состав конкретных предложений и пригодность для своей системы оценивают отдельно.

Частые вопросы

Чем резервная копия отличается от синхронизации с облаком?

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

Если МИС облачная, нужен ли отдельный бэкап?

Это зависит от условий договора с поставщиком МИС. Облачная платформа обычно отвечает за работоспособность своей инфраструктуры, но не всегда гарантирует восстановление данных конкретной клиники после случайной ошибки пользователя — этот момент стоит уточнить письменно, а не предполагать по умолчанию.

Как часто нужно копировать снимки КЛКТ и панорамные изображения?

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

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

Это сигнал, что текущая схема копирования не работает, и его стоит зафиксировать в журнале проверки, не дожидаясь реального инцидента. Дальше нужно разбираться со способом создания копии вместе с поставщиком МИС или ИТ-подрядчиком — возможно, копирование идёт не штатным способом производителя.

Обязательно ли шифровать резервные копии?

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

Правило 3-2-1 — это обязательное требование в России?

Нет, это инженерная рекомендация зарубежных организаций — NIST (США) и NCSC (Великобритания), а не норма российского законодательства. Клиника может адаптировать количество копий и мест хранения под свой размер и риски, сохраняя саму логику — несколько копий на разных носителях, включая одну вне помещения.

Кто должен тестировать восстановление данных — сама клиника или подрядчик?

Это стоит прямо прописать в договоре с поставщиком МИС или ИТ-подрядчиком, потому что по умолчанию сторона может считать, что тестированием занимается другая. Практический выход — закрепить ответственного за первую и последующие плановые проверки письменно, с указанием периодичности.

План первой проверки

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

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

Источники

• NIST NCCoE, «Protecting Data from Ransomware and Other Data Loss Events: A Guide for Managed Service Providers to Conduct, Maintain and Test Backup Files» — инженерное руководство, 2020, используется для определений RPO/RTO, правила 3-2-1 и рекомендаций по планированию и тестированию резервного копирования
• NCSC (National Cyber Security Centre, Великобритания), «Mitigating malware and ransomware attacks» — официальное инженерное руководство по регулярному копированию, офлайн-копиям вне основной сети и ограничению доступа к резервным копиям