Python-сообщество

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

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

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

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

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

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

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

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

ИХМО какая то странная у тебя карьера.

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

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

rownong
Перечисляются аварии (сбои электроснабжения, оборудования, ПО, ошибки персонала и т.д.)

Сделай каждую аварию из списка и сделай так, чтобы всё работало во время этой аварии, что должно работать во время аварии, и чтобы всё восстанавливалось после устранения этой аварии, что должно восстанавливаться. Так ты сразу поймёшь, что тебе нужно и чего у тебя нет. Потому что придумывать можно много чего и фантазировать, как всё прекрасно будет, но вот когда оно случится, ты сразу увидишь, где у тебя были просто мысли и розовые очки.

rownong
Его планируют в ЦОД распложённом физически в другом месте (или облако резервного хостинга)? Ведь если будут проблемы с электрическом или пожар, то смысла нет в окружении на виртуальных серверах в том же ЦОД.

Ну вот кто-то пришёл и поджог его специально. Всё сгорело. Ты вот после этого что можешь восстановить? Ничего? Ну, значит, плохо ты его зарезервировал. Это не поджигатель виноват.

Когда вот рэнсомы шифруют всё, сидят потом эти админы и руководство их, ничего сделать не могут и сокрушаются “какие плохие вымогатели, зашифровали нас, ах они козлы!”. А виноват-то кто в этом, что восстановить ничего нельзя?

Отредактировано py.user.next (Фев. 21, 2025 21:54:13)

Rodegast
ИХМО какая то странная у тебя карьера.

По моему логичная карьера - рост от маленьких проектов к большим.

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

Ок спасибо

py.user.next
Когда вот рэнсомы шифруют всё

Не совсем понял, кто и что шифрует?)

rownong
Не совсем понял, кто и что шифрует?)

В общем, понятно. Набери в поисковой системе “зашифровали сдэк”. Это одна из угроз сейчас. Но также есть ещё одна напасть сегодня, ранее неявная и малоизвестная: разработчики могут портить свой софт, который выпускают, и в обновлениях передавать стирающие фрагменты. Ну например, разделяемая библиотека функций, которой пользуется твоя система, может однажды прийти с обновлениями в новом виде и стереть тебе половину диска, вместо своего обычного функционирования, с надписью на экране “а вот теперь я считаю, что ты козёл, и я буду теперь против тебя!”. Тоже был прецедент уже.

Так вот, когда зашифровали СДЭК, он быстро восстановился, буквально неделя прошла, он уже работал снова. А вот то, что было с судами в начале осени 2024-го, это уже было не смешно, потому что суды не работали два месяца по всей стране. Так до сих пор там ещё встречаются дела, в которых судят там зайцев, пятачков, винни пухов всяких и так далее. То есть хрень вся работает, а какие карточки дел настоящие - хрен определишь.

И происходит это как раз по вот этой причине. Либо админы дураки, либо они, наоборот, не дураки, просто кто-то умный посчитал, что они сами бесплатно будут работать, какие-то бэкапы там делать и так далее, типа это им надо.

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

Отредактировано py.user.next (Фев. 22, 2025 16:20:39)

> разработчики могут портить свой софт, который выпускают … стереть тебе половину диска, вместо своего обычного функционирования, с надписью на экране “а вот теперь я считаю, что ты козёл, и я буду теперь против тебя!”

Это наверное ты такое делаешь, а серьёзные люди заниматься подобными глупостями точно не будут

Отредактировано Rodegast (Фев. 22, 2025 15:22:28)

Rodegast
а серьёзные люди заниматься подобными глупостями точно не будут

Вот тут описание первого случая
https://www.linux.org.ru/forum/security/16819987

А тут пачка случаев
https://habr.com/ru/news/656205/

Если о просто взломах говорить, то этих вещей ещё больше и история у них длиннее.

> Вот тут описание первого случая … А тут пачка случаев

Это просто хохлы бесились. В принципе эти угрозы можно к обычным вирусам приравнять. Я подумал что ты про коммерческое ПО говоришь.

Отредактировано Rodegast (Фев. 22, 2025 16:22:42)