{"id":14287,"url":"\/distributions\/14287\/click?bit=1&hash=1d1b6427c21936742162fc18778388fc58ebf8e17517414e1bfb1d3edd9b94c0","title":"\u0412\u044b\u0440\u0430\u0441\u0442\u0438 \u0438\u0437 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u0430 \u0434\u043e \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044f \u0437\u0430 \u0433\u043e\u0434","buttonText":"","imageUuid":""}

RuTube подвергся «сильнейшей за всю историю» сервиса кибератаке, он недоступен более суток Статьи редакции

The Village со ссылкой на источники писало, что «полностью удален код сайта», и теперь видеосервис «не подлежит восстановлению». Компания же утверждает, что код цел и сейчас восстанавливает сегменты файловой системы удаленных сред и баз видеохостинга.

Добавлено 11 мая. Rutube вновь заработал. Видеохостинг был недоступен больше двух дней из-за кибератаки.
  • Утром 9 мая хакеры атаковали видеохостинг, из-за чего сервис был недоступен. Издание The Village, ссылаясь на свой источник, писало, что атака началась около пяти утра, и из-за кибератаки «полностью удален код сайта», сервис «не подлежит восстановлению».
  • Обычно на такой случай предусмотрены бэкапы, но в конкретной ситуации проблема, видимо, в том, что в сервисе до сих пор не понимают, имеет ли по-прежнему хакер доступ к системе или уже нет, писало The Village.
  • Видеохостинг на утро 10 мая недоступен. Сама компания утверждает, что восстановление потребует больше времени, чем изначально предполагали инженеры.

Информация относительно утери исходного кода сайта не соответствует действительности. Мы и правда столкнулись с самой сильной кибератакой за всю историю существования RUTUBE.

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

RuTube
  • В результате атаки было поражено более 75% баз и инфраструктуры основной версии и 90% резервных копий и кластеров для восстановления баз данных, сообщила пресс-служба видеохостинга. Основная сложность — в восстановлении инфраструктуры, представляющая собой сотни серверов, каждый из которых приходится восстанавливать в ручном режиме, постепенно устраняя последствия вмешательства.

  • Когда восстановится доступ к сервису, компания не сообщает.
0
571 комментарий
Написать комментарий...
Дмитрий Карелин

Я не понимаю как в текущее время не делать бекапов? Что значит код не подлежит восстановлению? Звучит как какой-то сюр🤷‍♂️

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Николай Замотаев

От сервиса - возможно, а инструкции для deploy-я? а где гарантии что этот код "чистый"? И т.д.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Николай Замотаев

Если git - то нет. Локальный разработческий репозиторий может отличаться, локальный репозиторий можно править. Если централизованный сервер помер (или получил push -f и ветки не были защищены) - то гарантий нет ни у кого.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Николай Замотаев

В курсе.
Распределённая система контроля версий. В том что "распределённая" - и плюс и минус. У разработчика в общем случае полная копия всего репозитория.
Но используют его обычно всё же как централизованный (есть центральный сервер, там точно рабочая копия и тд, что там у разработчиков на машинах - их проблемы).
Но - локальную копию репозитория можно править, и там может быть по сути что угодно и в истории коммитов и в их содержимом.
git commit --amend, reposurgeon и возможности cherry-pick-ов никто не отменял.
Так вот - при потере центрального репозитория - нужно будет как минимум выяснить - что у разработчиков в версиях и собрать из них валидную копию.

PS. Я понимаю, что в общем случае разработчики аккуратно обращаются с git-ом, но я лично видел неоднократные случаи того, как в локальном гите творили дичь такого уровня, что проще было вычистить всё и заново наложить последние изменения.
PPS. В зависимости от workflow - свежей ветки master у разработчиков могло и не быть. "CI собирает и делает deploy, а нам эта ветка не нужна".

Ответить
Развернуть ветку
568 комментариев
Раскрывать всегда