Каким образом можно осуществить требования к сохранности информации в случае аварий, указанные в техническом задании?

Здравствуйте. 

Я имею некоторый опыт в разработке небольших скриптов и сейчас изучаю создание информационных систем. В технических заданиях часто встречается пункт "Требования сохранности информации при авариях" (в том числе в ТЗ, написанных по ГОСТу). Указываются различные аварийные ситуации (например, сбои электроснабжения, оборудования, программного обеспечения, ошибки персонала и т.д.) и требования к автоматическому резервному копированию информации с возможностью восстановления из резервных копий.

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

1. Правильно ли я понимаю, что речь идет о комплексе мер, включающем:
   1.1. Процесс создания и восстановления копий для:
   - Базы данных
   - Файлов (приложений бэкенда и фронтенда)
   - Брокера очередей
   1.2. Как балансировщик должен изменять маршрутизацию пользователей с основного окружения на резервное?
   1.3. И другие аспекты?

2. Как проектируется резервное окружение? Планируется ли его размещение в ЦОД, который физически находится в другом месте, или рассматривается облачное резервное хранилище? Поскольку в случае аварий (например, электрических неисправностей или пожара) нет смысла в использовании виртуальных серверов в том же ЦОД.

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

3. Насколько я понимаю, уровень резервного окружения и восстановления действительно проектируется в соответствии с требованиями и ресурсами заказчика (если ресурсы ограничены, то уровень резервирования будет ограниченным)?
  • 21 февраля 2025 г. 8:44
Ответы на вопрос 2
Здравствуйте! Вы правильно настраиваете свои мысли на важные аспекты, касающиеся требований к сохранности информации при авариях. Давайте детализируем каждый из ваших вопросов.

### 1. Правильно ли я понимаю, что речь идет о комплексе мер?
Да, вы совершенно правы. Под требованиями сохранности информации в случае аварий действительно подразумевается комплекс мер, который включает в себя:

1.1. **Процесс создания и восстановления копий**:
- **Базы данных**: Создание регулярных резервных копий (например, с использованием инструмента бэкапа, встроенного в СУБД или специализированных решений). Важно учитывать возможность инкрементального, дифференциального и полных бэкапов.
- **Файлы и приложения**: Нужно обеспечить резервное копирование всех критически важных файлов, включая файлы конфигурации и программного обеспечения.
- **Брокер очередей (например, RabbitMQ)**: Настройка репликации очередей и сообщений для обеспечения их сохранности. Важно использовать механизмы, которые позволяют делать бэкапы состояния очередей.

1.2. **Маршрутизация пользователей**: Пере-routing трафика с основного окружения на резервное может быть реализован с использованием балансировщиков нагрузки. Если основное окружение выходит из строя, балансировщик может направить трафик на резервные сервера. Это также может включать использование DNS с низким временем TTL для быстрой смены адресов.

1.3. **Другие аспекты**: 
- Уведомление персонала о сбоях и автоматизация процессов восстановления.
- Мониторинг состояния систем и разработка подробных планов восстановления после аварий (DRP - Disaster Recovery Plan).
- Документирование всех процессов и обучение персонала, работающего с информационными системами.

### 2. Как проектируется резервное окружение?
Проектирование резервного окружения зависит от таких факторов, как:
- Уровень критичности данных и их доступности.
- Бюджет и ресурсы заказчика.

Резервное окружение может быть:
- **ЦОД**: Физическое расположение в другом Центре Обработки Данных. Это надежный, но дорогостоящий вариант.
- **Облачное хранилище**: Использование облачных решений (например, AWS, Azure, Google Cloud), которые могут предложить гибкие возможности масштабирования и высокую степень доступности.

Важно также обеспечить защиту на уровне сети (например, VPN или выделенные каналы связи) при работе с облачными решениями.

### 3. Уровень резервного окружения
Вы абсолютно правы. Уровень резервирования и восстановления действительно должен проектироваться в соответствии с требованиями и возможностями заказчика. Это включает в себя:

- Оценку надежности и доступности материалов (SLA - Service Level Agreement).
- Понимание торговых и операционных потребностей бизнеса (нужна ли высокая доступность или допустимо некоторое время простоя).
- Разработка наиболее подходящей (и финансово оправданной) стратегии восстановления.

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

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

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

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

Если есть возможность, закладывать онлайн резервирования и восстановление в само приложение (те самые прогоны логов действий пользователей), как ещё один способ а не единственный.

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

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