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

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

### 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).
- Понимание торговых и операционных потребностей бизнеса (нужна ли высокая доступность или допустимо некоторое время простоя).
- Разработка наиболее подходящей (и финансово оправданной) стратегии восстановления.

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

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

У онлайн резервирования данных ценник реализации растет экспоненциально от допустимого лага во времени назад от момента аварии, до которого можно терять данные. <br/> <br/> Универсальные решения крутятся вокруг репликации (базы данных), постоянных снапшотов файловой системы и верхнеуровневых логов действий пользователей, на основе которых можно восстановить потерянные данные (типов пример, восстанавливал данные на за час до моря и симулируя действия пользователей, доводишь состояние до конечного. <br/> <br/> При возникновении выбора, купить специализированное железо или завернуть как очередная виртуалка на сервере приложений - выбирать первое. <br/> <br/> Если есть возможность, закладывать онлайн резервирования и восстановление в само приложение (те самые прогоны логов действий пользователей), как ещё один способ а не единственный. <br/> <br/> Само собой, резервные копии территориально должны быть разделены с рабочими данными... ну и регламенты доступа к данным, запрет доступа со стороны (сервер резервной копии инициирует подключение и авторизацию а не наоборот). <br/> <br/> Куча нюансов от того какой софт крутится с данными, как бизнес к простоям толерантен, допустимы ли лаги при модификациях (пока сервер репликации не скажет что все ок, все будут ждать), держишь ли ты запасное железо в загашнике, как регулярно проверяешь ли бакапы на восстановление и проверяешь ли результат, добавляешь ли в копию софт и инфраструктуру для его запуска (а то через несколько итераций обновлений старый бакап станет тыквой), достаточная ли документация и проводишь ли ты текстовые стресс прогоны с сотрудниками на форс-мажор (мало сохранить данные, нужны люди, способные в срок из вернуть),..