Методология разработки программного обеспечения
Добавили поддержку российских ОС в Open Source-платформе Deckhouse Kubernetes Platform
Хабр, мы кратко. В нашей Open Source-платформе Deckhouse Kubernetes Platform (DKP CE) появилась поддержка отечественных операционных систем. Изменения смержены в версии 1.69.
Теперь в качестве ОС для узлов поддерживаются:
Astra Linux;
ALT Linux;
РЕД ОС;
РОСА Сервер.
Напомним — если у вас есть вопросы и обратная связь по DKP CE, их можно принести в наше Telegram-сообщество для инженеров.
Сегодня 24 июня до 23.59 успейте принять участие в главном DevOps-исследовании года!
Это last call по исследованию состояния DevOps 2025 в России, проводимого компанией «Экспресс 42» при поддержке Axiom JDK. Оно закрывается сегодня ночью в 00.00 по мск.
Помогите отследить тренды и понять, как опыт разработчиков (DX) влияет на эффективность команд и успех компании. Фокус State of DevOps Russia 2025 на developer experience.
Осталось всего несколько часов — пройдите опрос до 23.59.
Мы вместе изучим, что помогает компаниям формировать позитивный опыт для разработчиков и как на него влияют внутренние платформы, ML/AI-инструменты, облачные технологии и практики ИБ.
Опрос анонимный и займёт ~20 минут. Данные нужны, чтобы понять, какие инструменты реально работают в проде, а какие — только в красивых презентациях.
Если вы — DevOps-инженер, разработчик, тестировщик, админ, тимлид, CTO, техдир — внесите свой вклад.
Все участники получат:
Полный доступ к результатам исследования;
Возможность выиграть билеты на Highload++ и DevOpsConf.
Промокоды и мерч от партнёров (AvitoTech, VK Cloud, Positive Technologies, Selectel, ecomtech, Okko, Онтико, Т-Технологии, Axiom JDK, Экспресс 42).
Участвуйте сегодня и голос вашей команды будет услышан. Чем больше ответов — тем лучше получится карта DevOps-практик в России.
Почитать предыдущие отчёты можно тут
PS. А у кого есть интерес заняться девопсом в команде Axiom JKD, загляните сюда.
Есть такие персонажи.
Ты их не звал, но они приходят.
На вторую сверху позицию. С резюме на десять экранов. С лицом человека, которому всегда всё ясно.
Я пришёл из Яндекса
Я строил облака
Я знаю, как делать лидоген
А потом ты открываешь план, который он накатал, и читаешь:
Надо срочно повысить охваты и сделать event-маркетинг в партнёрстве с департаментом госсектора. Занавес.
Это даже не ахинея. Это скриншот из какой-то методички 2010 года.
Кто ты, воин?
Формально - новоявленный руководитель блока продаж и маркетинга.
По факту - всего навсего бывший аккаунт-директор. До этого вообще специалист по ИБ в системных интеграторах.
Он искренне считает, что понимает рынок.
Он не знает, кто покупает облака. Он не знает, зачем их покупают.
Он путает капексы с опексами. У него в голове до сих пор есть'облако' как магическое слово, которое должно продавать себя само. А если не продаёт — значит, виноват кто? Конечно, маркетинг.
Проблема даже не в нём
Люди не обязаны быть идеальными. Бывают разные.
Проблема в механике: его сюда спустили.
Он не вырос, не понял, не прошёл путь. Его просто назначили.
Сходу в кресло, сразу - с правом финального слова.
А ты теперь объясняй, почему твой roadmap не просто слайд. Почему у тебя нет 'горизонтальных альянсов'. Почему ты не пишешь статьи от имени продована по цифровой трансформации.
Идеи от него сыпятся каждый день
Давайте срочно делать холодные звонки
Нам нужно охватить весь SMB. Конечно, инфраструктуру же как пирожки на базаре продают.
Где у нас продажи через Telegram?'
Ты сначала смеёшься. Потом объясняешь. Потом просто перестаёшь говорить. Потому что бесполезно.
Он не слышит - он управляет. Или думает, что управляет.
Чем всё закончится?
Ты либо уйдёшь.
Либо адаптируешься.
Либо станешь таким же.
А он? Он - останется. Потому что его назвали Начальником начальника. Потому что кто-то где-то решил, что у него 'видение'. Потому что резюме с Яндекс.Облаком, казалось бы, всё ещё производит впечатление на тех, кто никогда туда не заглядывал.
Вывод?
Парашюты должны раскрываться до касания земли.
Иначе потом мы просто собираем обломки и делаем вид, что это было управляемое приземление.
Вы знаете этих людей. Вроде умные, вроде опытные. Говорят правильные слова про 'стратегию', 'масштабируемость', 'долгосрочную перспективу'.
Но почему-то через полгода таких разговоров оказывается, что:
баг, который 'уже почти пофиксили' никуда из прода не девался
фича, которую 'вот-вот запустим' — всё ещё в черновиках
команда уже тихо ненавидит слово 'архитектура'
А техлид? Техлид как будто ничего не замечает.
Как это работает (точнее, не работает)
Слова вместо кода
вместо пулл-реквестов - диаграммы.
демо нет - зато вот вам слайды.
вместо решений 'опять' 'давайте обсудим' (читай: 'я не хочу отвечать').
Бесконечный 'анализ'
'Надо подумать над архитектурой' = 'Я не уверен, но боюсь признаться'
'Это нетривиальная задача' = 'Мне лень разбираться'
Ответственность - это не про нас
Любимый приём - щедро размазать вину:
'Это комплексная проблема' (на самом деле: 'виноваты все, а значит — никто').
Реальный кейс (чтобы было не абстрактно)
В одном проекте (Node.js, если важно) техлид 2 месяца 'прорабатывал подход' к рефакторингу.
Провёл 8 митингов, написал 50 страниц документации.
А потом... уволился.
Оставив после себя:
красивые схемы в Confluence
ни одной строчки кода
команду, которая теперь на рефакторинг смотреть не может
Как понять, что ваш техлид центральная часть системы самообмана?
главный результат его работы - не код, а презентации
коронный вопрос - 'А как мы это будем масштабировать?' (но не сам масштабирует)
после разговора с ним хочется или закодить, или закопать
Что прикажете с этим делать?
тупо запретить 'стратегировать' без кода*
нет пулл-реквеста - нет права говорить про архитектуру.
ввести 'день испанского стыда'
раз в месяц техлид показывает руками, что сделал. Не слайды - код.
Задавать всего один вопрос
'Что конкретно изменится после твоего решения?'
Если ответ начинается со слов 'теоретически....' - это тревога.
Вывод
Хороший техлид — не тот, кто красиво говорит о проблемах.
А тот, кто их решает.
Если ваш 'архитектор' только генерирует документы, но не генерирует код - возможно, он уже ИИ.
P.S. Если после этого текста кто-то узнал своего техлида - это не совпадение
Подключайтесь к трансляции митапа для инженеров и сисадминов
Сегодня на SelectOS OpenFix Day обсуждаем лучшие практики работы с Open Source, вспоминаем свои инженерные факапы и разбираемся с нестандартными инфраструктурными задачами. Начало трансляции в 18:30 (мск).
Программа
Rust в ядре — прогресс или костыль в бронзе? Живая дискуссия про разный опыт работы с этим языком программирования.
Как справиться с инфраструктурным хаосом: вредные советы.
Честные истории о том, как падал и поднимался прод.
Ждем всех, кто не просто использует Linux, а вникает в код, фиксирует баги и патчит уязвимости.
Смотреть трансляцию:
📱в VK
Как DevOps-инженеру сэкономить часы работы и избежать ошибок с помощью AI-инструментов
Воркшоп с Виктором Чаплыгиным, Senior Engineer в международном GameDev холдинге.
Что будет на воркшопе:
Теория: кратко о том, как работают LLM в контексте разработки и эксплуатации. Обзор инструментов:
Cursor IDE — AI-интегрированная IDE с поддержкой кода и терминала;
PSP/PSS Baseline — стандарты безопасности Kubernetes.
Практика:
Настройка Cursor IDE — подготовка среды для продуктивной работы с AI;
Создание и отладка IaC (Kubernetes YAML, Terraform) с помощью AI-ассистентов: выявление и исправление ошибок;
Генерация понятной и структурированной документации к проектам с помощью AI;
Разбор реальных кейсов и работа с командной строкой: исправление, пояснение, улучшение команд и манифестов.
А ещё — личный опыт и лучшие практики применения GPT-ассистентов для повседневных DevOps-задач, от написания инфраструктуры до исправления ошибок и генерации документации.
Когда: 5 июля 2025 года
Узнать подробности и занять место на воркшопе — через бота.
Батл мнений: «Ванильный» K8s VS коммерческие решения: когда стоит платить?
Коммерческие платформы, предлагающие расширенную функциональность «из коробки», активно конкурируют с «ванильным» Kubernetes, который поставляется на базе открытого кода и «обогащается» внутренними командами самостоятельно. Но когда же выгоднее собрать продукт внутри, а когда — использовать чужое? И какой путь чаще выбирает крупный бизнес?
В прямом эфире вместе с AM Live собрали представителей топовых компаний: «Авито», Почта Банк, beeline cloud, АЛРОСА ИТ, RWB Media.
Они рассказали, какой подход используют внутри и почему именно его, с какими сложностями сталкиваются и какая команда эксплуатирует и поддерживает контейнерную платформу.
Смотрите запись эфира на удобной для вас платформе:
🚨 У кого в РФ проекты на CloudFlare перестали работать. РКН заблокировал ECH [SNI].
Чтобы исправить:
Зайдите в настройки SSL/TLS на панели Cloudflare.
На платном тарифе:
В разделе "Edge Certificates" найдите "Encrypted ClientHello (ECH)" и выберите "Disabled", если хотите отключить шифрование.
На бесплатном тарифе:
Поставить Minimum TLS Version = 1.2
Отключить TLS 1.3
OpenRedirect в IBM Instana (NotCVE-2025-0002)
Instana - платформа для мониторинга приложений и инфраструктуры. Эту особенность я нашёл пару месяцев назад совершенно случайно. Забавно, что год назад на собеседовании я не смог ответить на вопрос: что такое OpenRedirect (описан в CWE-601) - растерялся. А сейчас вот сам нашёл. Проблема довольно тривиальна: с помощью специально сформированной ссылки можно заставить браузер жертвы выполнить произвольный GET-запрос. Жертва должна быть авторизована в Instana. Пример ссылки:
https://instana.com/auth/signIn?returlUrl=https%3A%2F%2Fsite.com%2Fchangepassword%3Fuser%3Dadmin%26newpassword%3Dtest
На рисунке ниже виден результат перехода по подобной ссылке: сервер отвечает кодом 302 и через location перенаправляет пользователя на нужный ресурс.
Изначально я пытался зарегистрировать CVE. Продукт Instana принадлежит IBM. А IBM является CNA партнёром MITRE (подробнее про CNA). Т.е. для регистрации CVE нужно обращаться не к MITRE, а к IBM напрямую. Что я и сделал. Ответ от IBM был таков:
We need to see more impact beyond phishing. If you are able to chain this issue with further exploitation (ex: token theft, xss bypass, SSRF, etc…) then please let us know. You will see that other vulnerability programs (example: google) take a similar stance on open redirects.
We recommend taking a look at the following external resources for further information on open redirect issues we would be interested in addressing:
We thank you for your efforts in helping keep IBM products secure. Please reference any further communication related to this issue via your original HackeOne ticket so we can better track this finding.
Нежелание признавать уязвимость со стороны разработчиков - не такая уж и редкость. В моей практике бывало, что разработчики даже пытались оспаривать CVE. Я решил вместо дальнейших исследований по повышению импакта обратиться в NotCVE - сервис как раз для подобных случаев (делал об этом сервисе заметку). Тем более уже был опыт взаимодействия с ними. И буквально через пару дней получил ответ, что уязвимости назначен идентификатор NotCVE-2025-0002.
Проблема замечена в версии User interface v1.293.809 + Backend Tag v3.293.425-0. В этой версии проблемы нет: User interface Tag 1.267.675 + Backend Tag 3.267.347-0
Upd: угрозе назначен идентификатор BDU:2025-12555
MongoDB + WARP + Xray = 💥 BSONError
У меня MongoDB начала выдавать ошибки:
BSONError: Invalid UTF-8 string in BSON document BSONError: bad embedded document length in bson
Документы в базе нормальные. Ошибки появлялись только при включённом Xray с WARP (через встроенный WireGuard). Когда VPN отключён — всё читается корректно.
Поначалу думал, что что-то с кодировкой или драйвером, но оказалось, что проблема в том, что Mongo работала через Cloudflare WARP.
Когда запросов было мало — срабатывало нормально.
Когда запускался алгоритм и начинались частые обращения к базе — Mongo валился с ошибками BSON.
Причина — искажение бинарного трафика при передаче через WARP.
Mongo использует бинарный протокол BSON, и даже один сбитый байт ломает парсинг.
Пофиксил так:
добавил в routing.rules Xray правило, чтобы трафик к Mongo шёл мимо WARP:
{ "type": "field", "ip": ["<IP MongoDB>"], "outboundTag": "direct" }
NotCVE-2025-0001
Прошёл месяц с момента моего обращения в MITRE про нежелание разработчиков делать CVE из-за фикса в Docker Engine 28.0.0. От MITRE никаких новостей больше не было. Поэтому я обратился в NotCVE (об этом сервисе я делал заметку). Спустя буквально пару дней меня оповестили о создании идентификатора NotCVE-2025-0001.
Проект NotCVE пока ещё мало известен. По этой причине по запросу "NotCVE-2025-0001" пока далеко не во всех поисковиках что-то можно найти (в Гугл нашёл 1 запись, в Яндексе и DuckDuckGo - ничего). Да и идентификаторов в NotCVE пока всего лишь 6. Очень надеюсь, что проект обретёт популярность и количество идентификаторов увеличится. И в первую очередь - из-за повышения осведомлённости об этом проекте и увеличении обращений (из-за нежелания разработчиков признавать проблему и создавать CVE). В данном случае показательно, что идентификатор NotCVE-2025-0001 завели по моему обращению несмотря на то, что проблему нашёл не я. Я просто не смог пройти мимо, увидев нежелание разработчиков регистрировать CVE.
ping: permission denied (are you root?)
Знакомы ли с этим сообщением об ошибке? И знаете ли, как ее исправить?
Этот запрет на отправку ICMP-пакетов внутри контейнера можно получить при выполнении, например, такой задачи.
Задача: Организовать k8s-кластеры в ручном режиме с помощью kubeadm и kubectl на базе cri-o (1.28+) и использовать Calico как CNI-плагин.
Кластер доступен для взаимодействия через kubectl, команда возвращает корректную информацию о кластере. Есть возможность сделать ping 8.8.8.8 с образом busybox.
Если вы опытный DevOps и знаете, как решается эта «детская проблема» при работе с оркестратором, регистрируйтесь на спринт-оффер для девопсов. Сможете буквально играючи получить новую работу за 3 дня.
Если вы только начали изучать Kubernetes, читайте статью с подробным разбором этой ошибки →
Как обнаружить anycast-адреса сервисов при помощи неравенства треугольника
Технически, по одному и тому же IP-адресу может отвечать всякий интернет-узел, который находится на (двунаправленном) техническом пути следования пакетов. Чтобы такое работало без запинки для многих IP-источников - требуется согласовать пути следования пакетов на уровне IP-сети, то есть, средствами BGP. Штатный способ использования этой особенности называется Anycast. Настроить и поддерживать сложно, но, при грамотном подходе, метод отлично работает и достаточно широко используется в глобальной Сети. При Anycast один и тот же IP-адрес, наблюдаемый из разных точек Интернета, адресует разные физические узлы. Эти физические узлы могут быть географически распределены - ближе к пользователям. Обычно, так и делается, потому что это одно из основных практических преимуществ Anycast, но далеко не единственное преимущество - anycast-адреса могут быть разведены средствами BGP и коммутации сетевых сегментов из соображений устойчивости к DDoS-атакам, распределения прочей нагрузки, повышения надёжности и т.д. Примеры: 1.1.1.1, 8.8.8.8, многие корневые DNS-серверы.
Как подручными средствами проверить, что какой-то интернет-сервис стоит за anycast-адресами? Для этого нужно использовать неравенство треугольника. Тестируемый узел должен отвечать в рамках того или иного протокола, который позволяет измерить сетевое время доставки пакетов.
Методика. Пусть мы обнаружили IP-адрес сервиса (обычно, из DNS) и хотим его проверить. Пусть узел под этим адресом отвечает по ICMP - ping. Возьмём два опорных узла-источника, расположенных в совсем разных местах Интернета: например, узел в Амстердаме (обозначим его А) и узел во Владивостоке (соответственно - В). Тестируемый узел назовём Т. Принцип: если среднее время доставки ping между А, В (А <--> В) существенно превышает сумму ping для А --> Т и В --> Т, то сервис, работающий на узле T, скорее всего, использует Anycast. Поэтому измеряем время силами ping. Это и есть нарушение неравенства треугольника: если сумма расстояний (в смысле ICMP) от каждой из точек тестирования к тестируемому узлу меньше, чем расстояние между этими точками, то тестируемый узел - это, скорее всего, как минимум два узла, использующих один и тот же IP-адрес, то есть, это anycast-адрес.
Конечно, тут всегда есть место для погрешности, однако в подавляющем большинстве случаев Anycast так виден - иначе в нём не было бы смысла. Можно взять несколько опорных точек, а не две, тогда точность возрастёт.
Чек-лист: как настроить мониторинг, который предупредит сбой до его возникновения
Шаг 1. Составьте карту сервисов и зависимостей
Что включить: микросервисы, БД, очереди (Kafka, RabbitMQ), сторонние API (платежки, SMS).
Зачем: чтобы понять, как падение одного компонента влияет на систему.
«Падение Redis "уронит" кэширование и увеличит нагрузку на БД».
Шаг 2. Разделите симптомы проблем: срочные vs важные
Срочные (реагировать немедленно!)
БД: connections > 90%, replica lag > 10 сек.
Платежный шлюз: 5xx errors > 1% за 5 мин, latency p99 > 3 сек.
Kubernetes: pod restarts > 5/час, node CPU > 95%.
Инструменты: Grafana OnCall, PagerDuty.
Важные (требуют анализа)
Рост ошибок 4xx > 5% за сутки.
Увеличение времени ответа API на > 20% за неделю.
Падение успешных сессий (Google Analytics).
Решение: алерты в Slack/Email.
Шаг 3. Автоматизируйте рутину
Сбор логов: стек EFK (Elastic + Fluentd + Kibana).
Kubernetes:
Liveness-пробы → авто-перезапуск пода при сбое.
Readiness-пробы → остановка трафика на проблемный под.
Redis: настройка политик очистки кэша.
Совет для ленивых:
«Используйте Coroot — он автоматически строит карту зависимостей и предлагает алерты»
Шаг 4. Тестируйте устойчивость
Chaos Engineering раз в месяц:
Отключайте случайные ноды в кластере.
Эмулируйте нагрузку в 10 раз выше обычной (Locust).
«Мониторинг должен не только сообщать о проблемах, но и подсказывать, что делать».
Шпаргалка о системном дизайне. Саму статью читаем тут: https://habr.com/ru/articles/915376/
IMPulse - менеджмент инцидентов. Интеграция с Google Calendar, вложенные цепочки эскалации.
Предыдущие публикации:
https://habr.com/ru/articles/865208/
https://habr.com/ru/posts/889768/
Мы продолжаем развивать нашу систему менеджмента инцидентов. И рады представить интеграцию с Google Calendar, благодаря которой вы сможете гибко настраивать график дежурств и цепочки эскалации для этих дежурств.
Помимо интеграции с Google Calendar, мы реализовали вложенные цепочки эскалации. Теперь в chain можно добавить другой chain (nested), благодаря чему размер конфигурационного файла уменьшится.
Мы хотим создать достаточно гибкую, но не перегруженную систему цепочек эскалации, чтобы на проектах разной величины вы могли использовать IMPulse так как вам удобно. Для этого в комментариях расскажите, какой самый сложный кейс уведомлений / эскалации вам необходимо было реализовать. Например: во вторник нужно дёргать Антона, через 5 минут Олега, а по средам - только дёргать Геннадия, в остальное время, если severity == 'critical', звонить Грише.
Будем рады почитать самые сложные варианты и предложить наше универсальное решение для них.
Остаёмся на связи в нашем Telegram канале - там можно общаться / задавать вопросы.
Три дня, чтобы начать поддерживать инфраструктуру для базовых станций GSM/LTE
Это baseband-модуль (BBU) базовой станции, которую разработала команда Телеком в YADRO, и мы ищем DevOps-инженеров, которые к ней присоединятся. Таким специалистам нужно будет поддерживать процессы разработки (на С/С++, Go, Node.JS), развивать CI/CD и улучшать качество внутренних сервисов.
Узнать, как стать DevOps-инженером в YADRO →
DevOps-специалистов разного уровня — от junior до senior — мы ждем по двум направлениям.
Infrastructure
Задача DevOps-инженера здесь — поддерживать бесперебойную работу инфраструктуры для разработки в телекоме. А это более 600 виртуальных машин, 20 информационных систем и десятков внутренних сервисов. Эта работа не просто про администрирование серверов, но и про автоматизацию работы и масштабирование инфраструктуры.
CI/CD
Специалисты по этому направлению организуют разработку и выпуск программно-аппаратных решений в сфере телекоммуникаций — с использованием Gitlab CI. Ежедневно они востребованы у более тысячи разработчиков и тестировщиков телекома. Цель DevOps-команды — сделать удобным процесс доставки изменений от разработчиков до продукта, а также постоянно улучшать и оптимизировать существующие решения, внедрять Observability для текущих продуктов, создавать новые инструменты.
Условия быстрого оффера
Подайте заявку на лендинге до 8 июня. Далее с вами свяжется рекрутер, чтобы обсудить общие вопросы и назначить интервью. После вы пройдете техническое интервью и интервью с менеджером, а в случае успеха получите оффер в компанию. Весь процесс займет 3 дня.
Больше про спринт-оффер и описания требований к специалистам — по ссылке.
Привет, развил тему пропихивания стручков (pod'ов) в кубернетис, добавил в меню выбора типа объектов команду apply. Теперь kui'ем можно приколачивать мYAMLики, создавая любые типы объектов. По умолчанию предлагает создать стручок:
Но с помощью кнопки edit можно изменить мямлик, изменения сохранятся в файл ~/.kyml.
С удивлением обнаружил что хаб Кодобред переименован в Говнокод О_о Чтож, так даже интереснее.
Творите, выдумывайте, пробуйте!)
Настройка бекапа вашей Linux системы с помощью rsync: просто и со вкусом
Шаг 1: Подготовка сервера для бэкапов
Лайфхак: В Hostkey VPS с 4ТБ обойдется примерно в 2600₽/месяц
Настройка SSH-ключа для безопасного доступа:
# Создаем SSH-ключ ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_backup # Копируем на сервер ssh-copy-id -i ~/.ssh/id_rsa_backup.pub user@backup-server # Создаем директории на сервере mkdir -p /root/backup-{1,2,3}
Шаг 2: Настройка автоматических бэкапов
Добавляем три задания в crontab для ротации бэкапов по дням недели:
crontab -e
Вставляем три задания (замените SSH_USER, SSH_HOST и SSH_KEY_PATH):
# Бэкап в директорию backup-1 (воскресенье, среда, суббота) 0 */2 * * 0,3,6 touch /tmp/os-backup.lock && /usr/bin/timeout 7200 /usr/bin/flock --close -n /tmp/os-backup.lock /bin/bash -c "rsync -aAXHv --delete -P --rsync-path=\"sudo rsync\" -e \"ssh -o StrictHostKeyChecking=no -i SSH_KEY_PATH\" --exclude='/dev/*' --exclude='/proc/*' --exclude='/sys/*' --exclude='/tmp/*' --exclude='/run/*' --exclude='/mnt/*' --exclude='/media/*' --exclude='/lost+found/' /* SSH_USER@SSH_HOST:/root/backup-1 &> /var/log/os-backup || sudo -u $(id -nu 1000) DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus notify-send \"OS BACKUP FAILED\"" # Бэкап в директорию backup-2 (понедельник, четверг) 0 */2 * * 1,4 touch /tmp/os-backup.lock && /usr/bin/timeout 7200 /usr/bin/flock --close -n /tmp/os-backup.lock /bin/bash -c "rsync -aAXHv --delete -P --rsync-path=\"sudo rsync\" -e \"ssh -o StrictHostKeyChecking=no -i SSH_KEY_PATH\" --exclude='/dev/*' --exclude='/proc/*' --exclude='/sys/*' --exclude='/tmp/*' --exclude='/run/*' --exclude='/mnt/*' --exclude='/media/*' --exclude='/lost+found/' /* SSH_USER@SSH_HOST:/root/backup-2 &> /var/log/os-backup || sudo -u $(id -nu 1000) DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus notify-send \"OS BACKUP FAILED\"" # Бэкап в директорию backup-3 (вторник, пятница) 0 */2 * * 2,5 touch /tmp/os-backup.lock && /usr/bin/timeout 7200 /usr/bin/flock --close -n /tmp/os-backup.lock /bin/bash -c "rsync -aAXHv --delete -P --rsync-path=\"sudo rsync\" -e \"ssh -o StrictHostKeyChecking=no -i SSH_KEY_PATH\" --exclude='/dev/*' --exclude='/proc/*' --exclude='/sys/*' --exclude='/tmp/*' --exclude='/run/*' --exclude='/mnt/*' --exclude='/media/*' --exclude='/lost+found/' /* SSH_USER@SSH_HOST:/root/backup-3 &> /var/log/os-backup || sudo -u $(id -nu 1000) DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus notify-send \"OS BACKUP FAILED\""
Что делает наш скрипт?
Умное расписание: Каждый день недели система копирует данные в одну из трех директорий
Защита от блокировок: Предотвращает запуск нескольких копий скрипта одновременно
Безопасность: Использует SSH-ключи вместо паролей
Исключения: Пропускает системные директории, которые не нужно бэкапить
Мониторинг: Отправляет уведомление в шторку уведомлений, если что-то пошло не так
ОБЯЗАТЕЛЬНО сохраните SSH-ключ в надежном месте! Без него восстановление данных будет невозможно.
Рекомендации:
Копия на USB-флешке (хранить отдельно от компьютера)
Распечатка на бумаге в сейфе (для параноиков)Зашифрованная копия в менеджере паролей
Проверка работоспособности
Регулярно проверяйте состояние ваших бэкапов:
ssh -i SSH_KEY_PATH SSH_USER@SSH_HOST "ls -la /root/backup-1"
Теперь у вас есть надежная система бэкапов, которая защитит вас от большинства катастроф. В случае сбоя вы сможете быстро восстановить всю систему целиком, минимизируя простои и стресс.
Привет, приспичило создать тестовый стручек (pod), проверить кое-что. Создал и добавил это в kui, в секцию "быстрых" команд:
Тестовый стручек создается вот такой командой:
kube run $quick_pod_name $ns --image=$quick_pod_image --command -- $quick_pod_command 2>&1
Для изменения названия, образа или команды стручка подредактируйте вот эти переменные в начале скрипта:
quick_pod_name=busytest # Pod name for simple test pod quick_pod_image=busybox:1.32 # Pod image for simple test pod quick_pod_command="sleep 3600" # Pod command for simple test pod
Творите, выдумывайте, пробуйте!)