#бэкап

Доброе утро! А вот у южнокорейских государственных айтишников — не очень доброе, потому что они не делали бэкапы до сих пор восстанавливают инфраструктуру после пожара в серверной.

У большинства систем были бэкапы, но удаленное хранилище файлов, которым пользовались 17% всех госслужащих страны — не имело бэкапов. Безвозвратно потеряны терабайты документов. Делайте бэкапы!

Кстати, у этой истории есть ещё и шпионское измерение: в июне 2025го двое хакеров взломали северокорейского (китайского?) хакера, который взломал LG и кучу южнокорейских государственных систем. Дали об этом знать южнокорейским правоохранителям, которые в августе перестали выходить на связь. А дальше уже совсем мистика: кто-то пишет им с одноразового номера в сигнале «Proton небезопасен», после чего Proton блокирует почтовый ящик, с которого они вели коммуникацию только с южнокорейскими властями, но разблокирует после публикации.

24 сентября южнокорейский парламент начинает расследование взлома, 25го анонсирует физический аудит дата-центра, 26го — пожар. Подробности и ссылки на дампы с компьютера хакера — в легендарном журнале phrack.

Мы с Федей запускаем первый собственный стартап.

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

Обычно за бэкапы отвечают маленькие программы, скрипты, которые делают копию данных на отдельный диск или сервер. Но как проверить, что эта программа отработала успешно? Написать ещё одну, проверяющую? И кто устережёт самих сторожей?

Правильный способ проверки — «переключатель мертвеца», а точнее аналог «телемеханической системы бодрствования машиниста». Проще говоря, это система, которая ждет, что человек или программа каждый определенный промежуток времени нажимает на кнопку. Если кнопка не нажата — значит что-то пошло не так и нужно включить сирену или даже остановить поезд.

В нашем случае, ваши скрипты бэкапов дергают наш вебхук после успешного завершения работы. Если вдруг сервис заметит, что вебхук не активировали дольше определенного времени — то мы отправим вам сообщение в телеграме и электронное письмо.

В общем, очень простая система, которая не раз нас спасала. Раньше мы на всех своих проектах использовали healthchecks.io, но он перестал работать с компаниями из России, так что получается импортозамещение 🙈

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

Мы запустили много проектов для работодателей и клиентов, но прям свое — впервые. Волнительно.

Начать мониторить бэкапы можно уже сегодня на сайте safe-backup.ru. Пользуйтесь и держите данные в безопасности.

Mattermost прислал сегодня одному из наших клиентов, Вебиуму, письмо. Мол, из-за американских санкций в адрес России, они не имеют права предоставлять Вебиуму доступ к своему софту для корпоративных чатов. И отрубили мгновенно сервис, без всяких предупреждений. Ссылка на скачивание архива сообщений выдает ошибку.

Предлагают прислать свою интерпретацию законов, если мы считаем, что это ошибка.

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

А ещё я сегодня узнал, что в Mattermost есть целый отдел соответствия экспортным ограничениям. Вот, видимо, 3 месяца анализировали законы и пришли к новым выводам.

Имейте в виду, если пользуетесь облачным Mattermost ну и вообще любым облачным софтом. Делайте регулярные автоматические бэкапы и проверяйте восстановление из бэкапов.

Компания Atlassian 4 апреля что-то капитально сломала, так что 400 компаний-клиентов потеряли доступ к системе управления проектами Жира и базе знаний Конфлюенс. На 10 день (!) аварии, доступ восстановлен только для 35% клиентов, для некоторых восстановление доступа может занять ещё 2 недели (!).

Это тектоническая авария, есть компании, у которых из-за этого вполне может встать разработка.

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

Жальче всего людей, у которых не было локальных бэкапов этих систем. Не знаю как остальные техдиры, но я в свой чеклист аудита добавил пункт «бэкапы облачных сервисов».

Говорят, Росавиацию взломали и удалили вообще всё, включая реестры, внутренний документооборот и всю почту.

Цитата: «бэкапов нет, так как деньги Минфином на это не выделялись» — даже не знаю, смеяться или плакать.

Друзья, проверьте, что в вашем IT настроены хорошие бэкапы! Это первая штука, которую я смотрю при любом аудите. Бэкапы должны быть такими, что даже если вам всё-всё взломали — то бэкапы останутся в безопасности. А ещё нужно проводить регулярные учения по восстановлению из бэкапов. Это не так сложно и точно дешевле, чем пользоваться телеграммами и фельдегерской почтой в 2022 году.

«В России второй день не выдают права и не регистрируют автомобили. Серверы ГИБДД залило водой».

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

Во вторых, у подобных систем обязаны быть чётко прописанные процедуры восстановления из бэкапов, то есть запасных копий данных. Что не менее важно, эти процедуры проверяют в ходе регулярных «учений». Если вы подобных учений не проводите — хороший повод начать.

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

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

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

Из-за сломанной сети были недоступны внутренние инструменты, которыми пользуются сисадмины при исправлении проблем. Гугл говорит, что у них есть специальные бункеры с какими-то особыми доступами, но пока админы туда доехали — прошло дополнительное время. Самое главное, что система конфигурации потеряла своё внутреннее состояние и админам пришлось заново настраивать всё руками — это заняло очень много времени.

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

❧

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

Ходят слухи (пикабу, хабр), что Яндекс вчера случайно удалил виртуальные серверы клиентов в своем облаке (человеческий фактор).

Это отличное напоминание настроить бекапы (если вдруг их нет) и проверить, как работают процедуры восстановления.

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

Внушают опасение слухи, что клиентам написали письма о проблеме только через несколько часов и никакой публичной реакции Яндекса на ситуацию до сих пор нет.

Интересно, там было затронуто так мало машин, что они не видят видят причин официально комментировать? Классическое «это затронуло 0.004% клиентов и вот что мы сделали, чтобы такого больше не случилось» — тоже часть работы.

Планируя домашние бэкапы, обнаружил, что стоимость терабайта практически не зависит от объема диcка (раньше, крупные винчестеры стоили дороже).

А ещё убедился, что Numbers эстетически на голову выше Excel и Google Sheets. В нем можно составить цельную историю с множеством таблиц, текстом, картинками. Кайф.