Как реализовывать пункт ТЗ «Требования сохранности информации при авариях»?

Question

[rownong]

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

Раньше был опыт разработки небольших скриптов. Изучаю создание информационных систем.

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

Хочу понять, каким образом это реализовывается.
Подскажите:

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

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

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

Comments

[hint000]

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

Ещё в вопросе немного каши. Сначала про "Требования сохранности информации при авариях". Потом внезапно всплывает не относящееся к сохранности информации, а относящееся к непрерывности бизнеса.

Каким образом балансировщик должен менять маршрутизацию пользователей с основной окружения на резервное

По такой логике дальше должен быть ещё и вопрос по юридической защите информации и бизнеса. :) Давайте задавать вопросы по одному и не валить всё в кучу. Хотя по непрерывности тоже решение зависит от конкретных требований заказчика. Одно дело восстановить работоспособность сервисов за час и платить за это три копейки, другое дело восстановить за минуту и платить за это миллион, третье дело - прямо на ЦОД падает ядерная бомба, но клиенты этого даже не замечают, продолжая использовать 99 других ЦОДов.

Ведь если будут проблемы с электричеством

У приличного ЦОДа питание будет заведено с двух независимых подстанций. А на более серьёзный случай - бензиновые или дизельные генераторы и запас топлива. А вот про пожар - это интереснее вопрос. Многие ещё помнят, как сгорел немецкий ЦОД вместе со своим же резервом, потому что резерв был в здании, стоящем вплотную к основному ЦОДу. :) Так что да, в идеале иметь бы резерв в другом городе. Но очень хлопотно. Выбор делает заказчик.

Answer 1

[rPman]

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

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

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

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

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

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

Comments

[rownong]

Спасибо за развернутый ответ!
А по поводу снапшотов файловой системы, может проще git версии исходников хранить?

[rPman]

я сказал универсально, далеко не все можно хранить версионно в git, так как оно рассчитано только на тексты (да есть всякие lfs расширения, но когда простая синхронизация 100-гб проекта требует 100гб ram это расстраивает)

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