5.4 Резервное копирование и восстановление после катастроф

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

Определения: Целевая точка восстановления (RPO) и целевое время восстановления (RTO)

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

RPO (Целевая точка восстановления): «Какой объем данных бизнес может позволить себе потерять?»
- Пример: Если RPO = 15 минут и сервер выходит из строя в 10:00, то восстановление данных на состояние 09:45 считается успешным. Восстановление только до состояния 08:00 является неудачей.
RTO (Целевое время восстановления): «Как долго система может оставаться неработоспособной до критического воздействия на операции?»
- Пример: Если RTO = 4 часа, то система, вышедшая из строя в 10:00, должна быть полностью восстановлена для операторов к 14:00.

Матричный подход к восстановлению

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

Уровень	Область системы	Цель RPO (Потеря данных)	Цель RTO (Время простоя)	Стратегия
Уровень 0	Основная БД MES, БД ERP	< 15 минут	< 2 часа	Транзакционное реплицирование или группы доступности AlwaysOn SQL Server.
Уровень 1	Печать этикеток, Сервер лицензий	< 1 час	< 4 часа	Почасовые инкрементальные снимки состояния.
Уровень 2	Отчетность, исторические данные, аналитика	< 24 часа	< 24 часа	Ежедневное полное резервное копирование.
Уровень 3	Программы ПЛК, конфигурации edge-устройств	По последнему изменению	< 8 часов	Экспорт в Git или на файловый сервер по триггеру изменения.

Стратегия резервного копирования: Правило «3-2-1»

Универсальный стандарт обеспечения сохранности данных должен соблюдаться неукоснительно.

3 копии данных: Поддерживайте одну активную (рабочую) копию, одну локальную резервную копию и одну удаленную резервную копию.
2 разных типа носителей: Используйте различные технологии хранения (например, SSD для активного производства, HDD в NAS для резервных копий).
1 копия вне площадки: Как минимум одна копия должна храниться физически отдельно от основной площадки (например, в облачном хранилище, на ленточных носителях или в выделенном центре восстановления). Это гарантирует сохранность данных при серьезном инциденте на основном предприятии.

Защита от программ-вымогателей: «воздушный зазор»

Резервные копии, постоянно подключенные к основному домену, уязвимы для атак программ-вымогателей (ransomware) и другого вредоносного ПО.

Требование: Внеплощадочное хранилище резервных копий должно быть настроено как неизменяемое (WORM — Write Once, Read Many) или физически отключено (например, хранение на съемных лентах).
Правило: Если сервер резервного копирования использует те же административные учетные данные, что и производственный домен, это является нарушением безопасности. Идентичность и управление сервисом резервного копирования должны быть полностью изолированы.

Учебная тренировка по восстановлению: «Кот Шредингера» резервного копирования

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

Квартальная тренировка

Частота: Проводите тренировку каждые 3 месяца (ежеквартально).
Цель: Выберите случайный день из предыдущего месяца.
Действие: Восстановите базу данных MES и сервер приложений в изолированную среду UAT (приемочного тестирования).
Валидация:
1. Запускается ли сервис приложения без ошибок?
2. Могут ли пользователи успешно аутентифицироваться?
3. Соответствует ли «последний рабочий заказ» в восстановленной системе ожидаемой метке времени резервной копии?
Неудача: Если фактическое время восстановления превышает целевой показатель RTO, команда должна пересмотреть архитектуру резервного копирования (например, перейти с ленточных носителей на моментальные снимки на flash-накопителях).

План обеспечения непрерывности бизнеса (Business Continuity Plan)

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

Протокол «бумажного резервирования»

Триггер: Активация плана при прогнозируемом простое системы свыше 4 часов.
Действия:
1. Распечатать «аварийные бланки» (заранее утвержденные шаблоны).
2. Фиксировать критичные данные процесса (например, значения крутящего момента, серийные номера) в бумажных журналах.
3. Приостановить печать этикеток: Остановить упаковочные операции. Продолжать можно только сборку незавершенной продукции (WIP).
Восстановление: После возврата системы в эксплуатацию назначить персонал для переноса данных из бумажных журналов в MES для полного восстановления прослеживаемости.

Резюме: Матрица восстановления MES

Параметр	Требование	Значение	Документ / Стратегия
RPO (потеря данных)	Для основной БД MES	< 15 минут	Матрица восстановления (Уровень 0)
RTO (время простоя)	Для основной БД MES	< 2 часа	Матрица восстановления (Уровень 0)
Правило хранения копий	Стратегия «3-2-1»	3 копии, 2 типа носителей, 1 вне площадки	Стандарт резервного копирования
Защита от ransomware	Внеплощадочное хранилище	Неизменяемое (WORM) или физически отключено	Политика безопасности резервных копий
Тестирование восстановления	Квартальная тренировка	Восстановление в изолированную среду UAT	План учебных тренировок