Резервное копирование и восстановление ПЛК/SCADA: Как проверить, что бэкап реально работает
2026-04-20 09:56
Бэкап в АСУ ТП часто существует формально: файлы где-то лежат, копия сделана «по регламенту», а при аварии выясняется, что восстановить можно не всё, версия не та, или образ не поднимается на железе. В OT это особенно болезненно: простой растягивается не на часы восстановления файла, а на поиск совместимости, ключей лицензий, сетевых настроек и подтверждения безопасного возврата в работу.
Ниже - как построить резервное копирование и восстановление ПЛК/SCADA так, чтобы оно было проверяемым: полнота, целостность, offline-тест, RTO/RPO для инженерных систем и квартальный DR-drill на одну страницу.
Короткий ответ
Бэкап считается рабочим только если регулярно выполняется восстановление в изолированную среду с фиксированными критериями успеха. Полнота копии, контроль целостности и понятные RTO/RPO для инженерных систем должны быть задокументированы заранее, иначе «бэкап есть» превращается в иллюзию.
Что именно должно входить в «полный» бэкап
Полнота - это не только файл проекта ПЛК. Для восстановления контура обычно нужны связанные артефакты: прошивки и пакеты обновлений известных версий, экспорт тегов и экранов SCADA, конфигурации OPC, параметры historian, сетевые настройки и VLAN, учетные записи сервисов (без хранения паролей в открытом виде), лицензионные ключи и процедуры их активации, а также описание зависимостей между узлами.
Если в наборе нет хотя бы одного критичного элемента, восстановление превращается в расследование «что еще забыли».
Контроль целостности: без этого бэкап может быть битым годами
Практика простая: после создания копии фиксируются контрольная сумма или подпись, хранится журнал версий и сроков. Периодически выполняется проверка чтения архива и сопоставление с эталоном. Это дешевле, чем однажды обнаружить повреждение в момент аварии.
Для инженерных систем полезно разделять «холодное» хранение (оффлайн-копия) и оперативные снимки на площадке. У каждого типа хранения свой риск: носитель, права доступа, срок службы диска, человеческий фактор при копировании.
Offline-тест восстановления: единственный доказательный метод
Тест восстановления должен повторять реальность максимально близко: тот же класс контроллера или эмулятор, те же версии среды разработки, те же ограничения по сети. Цель - не «поднялось окно», а подтвержденный функциональный минимум: загрузка, связь с тестовым полем или эмуляцией, корректность ключевых тегов, работоспособность критичных экранов и журналирования.
Результат теста фиксируется одной записью: дата, версия, кто проводил, что проверено, отклонения, ссылка на тикет.
RTO и RPO для инженерных систем: как не смешивать «IT-цифры» с OT
RPO для SCADA/historian часто определяется допустимой потерей трендов и событий. RTO - временем до возвращения безопасного управления и наблюдаемости. Для ПЛК отдельно важно время на загрузку проекта, проверку безопасных состояний и повторную синхронизацию с полем.
Эти показатели должны быть согласованы с производством и зафиксированы как часть DR-плана, иначе при инциденте начинается спор, «достаточно ли быстро».
Регламент квартального DR-drill (на одну страницу)
Используйте как ежеквартальный сценарий учений. Длительность ориентировочно 4 часа, масштаб подберите под площадку.
Время
Этап
Действия (кратко)
Ответственный
Критерий успеха
T+0
Старт
объявить учение, зафиксировать версию плана DR
координатор DR
запись в журнале, команда на связи
T+0:15
Выбор объекта
выбрать контур/узел из списка допустимых для drill
владелец АСУ ТП
объект согласован с производством
T+0:30
Изоляция
отключить тестовый контур от прода по регламенту
сеть + АСУ ТП
нет перекрестного влияния
T+1:00
Восстановление
поднять образ/проект из бэкапа на стенде
инженер ПЛК/SCADA
загрузка без ошибок
T+2:00
Функциональная проверка
smoke-тест: связь, ключевые теги, тревоги, historian
инженер + дежурный
чек-лист пройден
T+2:30
Отказоустойчивость
проверить сценарий переключения/репликации, если применимо
инженер + ИТ
поведение соответствует runbook
T+3:00
Документация
зафиксировать фактические RTO/RPO, отклонения
координатор
отчет в базе уроков
T+3:30
Разбор
короткий post-mortem: что улучшить в бэкапе
владелец стандарта
список CAPA
T+4:00
Закрытие
вернуть стенд в эталон, снять изоляцию
АСУ ТП
контур в норме
Если за четыре часа drill не укладывается, дробите на два этапа в разные дни, но не отменяйте проверку восстановления.
Типовые ошибки, из-за которых «бэкап не бэкап»
Самая частая - бэкап делается, но никто не пробовал восстановить на чистой среде. Вторая - в архиве нет точной версии прошивки или пакета, совместимого с оборудованием. Третья - бэкап хранится только на том же узле, который и падает. Четвертая - нет учета лицензий и ключей. Пятая - отсутствует актуальный runbook, и команда тратит время на вспоминание шагов.
Где уместен СТАБУР
Проверяемое резервирование проще выдерживать, когда конфигурации и проекты стандартизированы и повторяемы между линиями. В платформенном подходе, включая проекты на базе решений СТАБУР, проще вести единые шаблоны DR, одинаковые требования к полноте бэкапа и регулярные учения без хаоса.
Заключение
Бэкап без теста восстановления - это надежда, а не инженерия. Когда полнота, целостность и DR-drill стали частью эксплуатации, площадка переживает сбои предсказуемо и с понятной ценой по времени.
FAQ
Как часто нужно тестировать восстановление?
Минимум квартально для критичных контуров и после каждого значимого изменения архитектуры.
Нужен ли отдельный стенд?
Желательно. Если стенда нет, используйте изолированный участок и жесткий регламент изоляции от прода.
Что делать с секретами и паролями?
Хранить в корпоративном vault, в бэкапе - только ссылки и процедуры ротации, без открытых секретов.
Как измерять зрелость DR?
По фактическим RTO/RPO на drill, числу найденных дефектов в бэкапе и скорости закрытия CAPA.
Можно ли автоматизировать проверку целостности?
Да, через контрольные суммы, мониторинг доступности хранилища и регулярное чтение выборочных архивов.