С днём системного администратора!
Стабильного коннекта, низкого пинга, работающего резервного копирования!
Пост призван показать, насколько инструменты тестирования и автоматизации на самом деле привязаны к конкретной реализации браузера. Если вы пришли за технической информацией, то TL;DR: если хотите автоматизировать скачивание файлов через браузер - используйте Chromium-based
Есть у меня тулза для бэкапа фоточек с гугла - сделал ее когда бэкапилка QNAP приказала долго жить(TL;DR Google изменил API так, что идея автоматического бэкапа стала бессмысленной)
Первая версия утилиты работала очень топорно и работала на playwright+chromium(это важно)
Когда Google в очередной раз добавили какой-то всратый шаг в свой визард авторизации, я понял, что надо переводить скрипт на стейт-машину. Так можно гораздо быстрее управлять переходами по экранам. И раз уж рефакторинг назрел, то хотелось избавиться от ручных антибот-настроек, перейдя на одно из промышленных решений.
Самое популярное такое решение работает на Firefox. Ну заменить один браузер на другой - что может пойти не так (спойлер: почти всё)
Сначала всё шло хорошо - кастомный FF удалось запустить на playwright с возможностью удаленного исполнения скипта автоматизации как раньше. Сценарий уверенно запустился и дошел до скачивания файлов. Скрипт нажимал ссылку, браузер начинал и успешно завершал загрузку, но скрипт так и висел, ожидая файла
Оказывается, FF в playwright не поддерживает события загрузки файлов, которых ждет. Совсем. Тут и случилось самое страшное. Что за вендорлок, почему я должен использовать именно chromium??? - подумал я..
Решение как заставить FF делать то, что нужно - нашлось быстро. Нужно просто использовать Selenium Grid
Событий загрузки там нет, но зато есть API доступа к скачанным файлам, на котором можно построить цикл ожидания загрузки. Кроме того, в него же удачно вписывалось шифрование кредов, которое раньше реализовывалось через отдельный сервис+контейнер
Первое же тестирование показало новую проблему. Playwright позволяет сохранить все cookies, вообще все и загрузить их в контекст СЕССИИ до загрузки какой-либо страницы. Selenium так не работает: он загружает/проставляет cookies только в контексте СТРАНИЦЫ. Это делает перенос данных авторизации гораздо мучительнее, ведь Google активно сопротивляется сбору cookies авторизации, редиректит с accounts.google.com на myaccount.google.com и т.д.
Чтобы добыть вообще все cookies нужен BiDi, но вроде как в Grid его еще не завезли по умолчанию. Поэтому надо в плагине писать прокси, которое позволяет по стандартной ручке достать все cookies..
После решения проблем с cookies файлы в скрипте наконец-то стали загружаться.. но только маленькие🤠
Как только загружался 2ГБ архив - скрипт наглухо OOM-ился. Стандартный API загрузки файла передает его целиком, заэнкоженым в base64. Естественно, целиком загнать в base64 2ГБ - жестоко, и столько памяти скрипту бэкапа никто выделять не собирается.
Снова пишем плагин, который рядом с grid выставляет нормальные стриминговые ручки, которые позволяют читать файл кусочками
И вот на этом месте - ура, все работает как надо!
Но не проще ли было месяц назад ПРОСТО ВЗЯТЬ Chromium..🤔
Backup 2.0 в «Хайстекс Акура»: дедупликация на уровне хранения и новый уровень эффективности
Когда объемы данных растут, увеличиваются и требования к корпоративным системам резервного копирования. Компаниям необходимо хранить больше резервных копий, соблюдать установленные сроки хранения и при этом контролировать затраты на инфраструктуру. Чтобы решить эту проблему, мы переработали слой хранения в платформе «Хайстекс Акура» и выпустили обновление Backup 2.0.
Что изменилось:
Дедупликация данных на уровне хранилища для снижения объема хранения и оптимизации использования дисковых ресурсов.
Сжатие резервных копий для дополнительной экономии дискового пространства с возможностью выбора оптимальных алгоритмов компрессии.
Шифрование данных при хранении, обеспечивающее базовую защиту резервных копий в состоянии покоя.
Выделенное хранение метаданных резервных копий, гарантирующее целостность, управляемость.
Наибольший эффект новая архитектура может дать в средах с большим количеством однотипных виртуальных машин и регулярно создаваемых точек восстановления.
В ближайших версиях:
Гибкие сценарии резервного копирования.
Отчуждаемые резервные копии.
Долгосрочное архивное хранение.
Если хотите примерить Backup 2.0 на свою инфраструктуру, оставьте заявку — инженеры «Хайстекс» помогут рассчитать параметры хранилища для вашей инфраструктуры.
Новый вебинар из серии «Быстрый старт»
Получите практические навыки по обнаружению и устранению неисправностей в системе резервного копирования.
09.07.2026 в 11:00 МСК проведем онлайн вебинар, на котором обсудим:
Структуру и основные компоненты Кибер Бэкапа
Функционирование компонентов системы
Средства внутреннего мониторинга
Назначение панелей мониторинга «Оповещения» и «Действия»
Расположение журналов основных компонентов продукта
Подходы к анализу и устранению проблем
Также покажем, как пользоваться этими инструментами на примерах типовых ошибок.
Ведущий: Егор Киселев, Инженер по сопровождению, Киберпротект
Сделал синхронизатор Телеграм канала в статический сайт.
https://github.com/vitaly-zdanevich/telegram_channel_to_static_website
Сайт генерируется через Zola.
Визуальный дизайн пока прост, минималистичен - без JavaScript. Чёрная и белая темы. Пагинация, теги, страницы. Свой CSS можно вставить через env.
Проект на Rust. Сделал через Codex gpt 5.5 xhigh.
Работает через GitHub Actions - раз в сутки перегенерирует весь сайт. Если пост изменился - он изменяется и на сайте - но в гите остаётся история.
Можно использовать и через cli - для бекапа.
Пока без использования ботов и API - через парсинг t.me - таким образом сохраняются даже короткие видео, но не аудио.
Линки на Ютуб превращаются в embed.
Комментарии пока не достаются, реакции тоже - потому что их нету на t.me
На Гитхабе и Гитлабе бесплатного места для статического сайта - гигабайт.
У меня около 1800 постов - отрабатывает за несколько минут
Определённые посты в канале - можно сделать страницами сайта. Как и заданные теги.
Пишите ваши фидбеки.
Как перестать надеяться на бэкап и автоматизировать Disaster Recovery
В одном из материалов я уже проводил границу между бэкапом и DR, которые решают принципиально разные задачи. Если бэкап — это архивный «огнетушитель», то DR — это система пожаротушения и план эвакуации. По реакции сообщества стало понятно: разницу осознают многие, но главный вопрос остается открытым — как обеспечить предсказуемый подъем сервисов, когда инфраструктура отказала?
Наличие резервных копий гарантирует, что данные не пропадут бесследно. Но бэкап не обеспечивает непрерывность бизнеса. При масштабном сбое восстановление из архивов вручную превращается в многочасовой (а иногда и многодневный) квест, который в условиях стресса часто ведет к человеческим ошибкам и увеличению простоя.
Чтобы перевести обсуждение из теории в плоскость работающих сценариев, мы с командой решили провести технический вебинар. 27 мая в 13:00 МСК в прямом эфире представим практические кейсы по восстановлению инфраструктуры после сбоя.
В программе:
Разберем почему бэкап не всегда спасает, и в какой момент нужен полноценный DR. Поговорим о том, как реалистично оценивать RTO и RPO.
Покажем сценарии восстановления инфраструктуры и посмотрим, какой подход работает лучше в каждой ситуации.
Покажем на практике:
восстановление данных через подключение дисков;
как это используется в реальных сценариях;
на что обратить внимание при восстановлении.
Вебинар будет полезен архитекторам, системным администраторам и всем, кто отвечает за доступность критичных систем. Приходите с вопросами по вашей инфраструктуре — разберем их в конце эфира во время сессии вопросов и ответов.
В финале встречи каждый участник получит актуализированный чек-лист для аудита плана аварийного восстановления.
👉 Зарегистрироваться на вебинар
Приходите на вебинар — покажем, как выстроить резервное копирование, которому можно доверять
Бэкап есть почти у всех. Но одно дело — хранить копии, другое — быть уверенным, что при сбое инфраструктура поднимется в нужные сроки и без потерь. Как перейти от «копии существуют» к «восстановление работает»?
Разберем это на совместном вебинаре с экспертами Cloud.ru и оператором ИТ-решений ОБИТ. Будет полезно ИТ-директорам, директорам по ИБ, системным архитекторам, инженерам и администраторам — всем, кто отвечает за сохранность данных в облаке.
Что расскажем и покажем:
какие практики резервного копирования актуальны сейчас и в чем их различия;
почему классическая стратегия 3-2-1 на практике может не выполнять свою функцию;
почему сторонний бэкап становится стандартом, а не опцией;
как опыт интегратора влияет на результат — и что меняется, когда интегратор и вендор работают в связке;
реальные кейсы: что именно это дает бизнесу.
В практической части пройдемся по интерфейсу SaaS-решения Cloud.ru. В прямом эфире покажем процесс восстановления машины из резервной копии через агента и разберем, как встроить решение в существующую инфраструктуру без глобальных переделок.
📅 Когда? 26 мая в 11:00 мск.
📍 Где? Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам в прямом эфире.
Добрый день, уважаемые коллеги!
Прошу прощения за задержку тары сообщения, но новость о прекращении разработки и сопровождения pgbackrest более неактуальна: https://github.com/pgbackrest/pgbackrest#maintenance-update
Спасибо @Harliff: https://habr.com/ru/articles/820349/#comment_29976278
Я давний пользователь Geeknote - это cli для Evernote. Несколько лет назад проект застрял на втором Питоне - и никто не хотел его портировать на третий. Я ждал что кто-то займётся этим - но пришлось самому - так что я форкнул, починил, и даже связался с Виталием Роденко - одним из создателей Geeknote и администратора на PyPI, чтобы получить право туда пушить. За десяток лет я видел как Geeknote переходил из одни руки в другие - и как он забрасывался, и через несколько лет находился новый мантейнер. Было забавно осознать, что теперь и я стал мантейнером программного продукта, который всегда установлен на все мои машины.
Как и большинство из нас, я стал пробовать LLM - как замену поиску, для анализа кодов, советов, и вот наконец - несколько проектов - даже не читая кода - только давая команды и тестируя результат. Известная шутка - переписать на Rust. Почему бы у нет - Geeknote не велик - около пяти тысяч строк на Питоне, что я и попробовал - через Codex gpt-5.5. Несколько десятков итераций, "добавь это", "добавь то", "пропали теги", "пропала анимация" - и за несколько часов я получил рабочий Geeknote на Rust, назвал его reeknote.
Результат: быстрее работает, раза в два. Теперь буду им пользоваться.
P.S.: CLI хороши для перфоманса, SSH, быстрее разработка без GUI, а ещё похоже и для LLM - можно попросить сохранить ответ в Evernote. Как и прочие интеграции, в том числе в скриптах.
Добрый вечер, уважаемые коллеги.
Тут в ленту прилетела новость, которая касается всех постгресменов, кто пользуется pgbackrest-ом для создания резервных копий. Либо собирается им пользоваться. А именно, создатель и разработчик проекта закончил работу над ним: https://github.com/pgbackrest/pgbackrest#notice-of-obsolescence. Грусть, печаль, тоска, тлен и безысходность. :( И статью править, и исходный материал в ЖЖ.
Автоматизация рутины в ispmanager: скрипты, CRON и плагины
Настройка серверов, бэкапы, обновления, управление пользователями — всё это можно делать вручную. Или один раз настроить и забыть.
В новой статье разобрали, как автоматизировать типовые задачи в ispmanager: настроить планировщик CRON прямо из панели, написать скрипт резервного копирования, создать собственный плагин и подключить внешние инструменты вроде Zabbix или Git. Подробности — в блоге Рег.облака.
Неудобные вопросы про бэкап PostgreSQL: открытый разбор на вебинаре
Вокруг бэкапа PostgreSQL легко создать иллюзию, что все уже решено. Достаточно добавить в текст WAL, PITR, пару слов про консистентность и назвать агент «умным». Проблема в том, что в проде такие формулировки мало что гарантируют.
Можно ли вообще считать решение PostgreSQL-aware, если оно не живет внутри логики самой СУБД? Где проходит граница между нативными механизмами PostgreSQL и внешней платформой? Что происходит, если не доехал WAL-сегмент, не завершился post-script или восстанавливать нужно не весь инстанс, а один объект?
Из таких вопросов и вырос отдельный вебинар про PostgreSQL в Акуре, в формате открытого инженерного разбора: что здесь должна делать сама СУБД, что имеет смысл выносить во внешний слой, где начинаются реальные эксплуатационные проблемы и какие ограничения в таком подходе нельзя замалчивать.
План такой:
отдельно пройтись по WAL, PITR и консистентности;
обсудить, где файловый агент уместен, а где уже нет;
разобрать сценарии с ошибками pre/post-скриптов;
поговорить про восстановление в безопасную локацию и ручной recovery;
отдельно затронуть вопрос масштаба: почему на двух базах хватает shell-скриптов, а на пятидесяти уже начинается совсем другая жизнь.
26 марта 2026, 11:00 (МСК) Регистрация по ссылке. Приносите в комментарии вопросы, которые особенно хочется поднять в эфире.
Поставлю на автопубликацию, на начало вечера пятницы, ибо.
Давайте подумаем, можно ли на основе электрета создать SSD для архивного хранения? Допустим, при записи бита затвор сильно нагревается и электрет плавится, а заодно поляризуется. Можно, скажем, после этого урезать осетра и дать транзистору остыть, не теряя заряд. Или, если у нас какой‑нибудь преднамеренно заложенный тиристорный эффект — превратить все транзисторы в печки, сохраняющие свой заряд одновременно, а охладить превозмоганием — в кипящий фреон окунуть и всё, прошили (только‑только от него в дихлофосах избавились, и тут я, лол). Или для плавления нужен суровый внешний подогрев от отдельного питания +12, который потом отключается или вовсе сменяется охлаждением (это уже какой‑то прямо твердотельный CD‑RW). Или зарядить общей пластиной сверху, расплавив и дав на неё пару киловольт (а транзисторы при этом защищены от пробоя при помощи временного закидывания всех «органов» на ноль), а потом разряжать выборочно, загоняя транзисторы «в режим печки». Нашёл только какой‑то патент 2002 года, номер Ru2297051c2, но там как‑то уныло всё. В кучу кони, люди, «скруглённые углы»…
Ну или с другой стороны — мой любимый кварцевый диск. Допустим, какой‑нибудь шибко дипольный оксид не разлагается до 1500, но хорошо плавится уже при 900. Размешиваем в расплавленном кварце эмульсию нанокапель этого оксида, остужаем до 1000, поляризуем и остужаем дальше. Теперь, если лазером расплавить, поляризация уйдёт. Вопросов только два — как прочитать и что мешает использовать обычный редкоземельный чугуний, который точно так же можно туда вплавить и потом намагнитить остывший диск могучим полем примерно как у ЯМР‑томографа (он же — МРТ), а размагнитить — выборочно, нагревая лазером. Там хотя бы примерно понятно, как читать потом — мы же получили магнитооптический диск, только очень большой, толстый, многослойный и стирается исключительно на заводе.
Ближайшие события
Задача про копирование базы данных
Проверьте, как быстро вы справитесь с несложным заданием на логику и математику.
Условие
Компания «Тирекс&Co» очень боялась потерять базу данных с клиентами и закупила для своих задач партию жестких дисков. Теперь раз в день администратор создает копию от каждой актуальной версии БД на любой диск, на котором еще не было бэкапа. То есть каждый день количество копий базы данных увеличивается в два раза. Через неделю они полностью заполнят все жесткие диски.
Задача
За сколько дней заполнятся все свободные жесткие диски, если вместо одной базы данных будет две на разных накопителях?
Делитесь ходом рассуждений и решениями в комментариях. Кстати, подсмотреть их всегда можно в Академии Selectel.
Расскажем, как подготовить IT-системы к наплыву покупателей 🛍️💻
Черная пятница, а после — предновогодняя суета с поиском подарков или продуктов…
На вебинаре расскажем, как обернуть ситуацию в свою пользу: подготовить IT-инфраструктуру, чтобы сервисы не упали, покупатели остались довольны, а компания не потеряла прибыль.
Зовем всех, кто отвечает за отказоустойчивость IT-систем в ритейле и e-com: CIO, CTO, руководителей и менеджеров по цифровой трансформации и IT, руководителей инфраструктурных операций и не только.
Обсудим, как:
добиться SLA 99,95%, обеспечить минимальные RTO и RPO, чтобы быстро восстанавливаться после сбоев;
перенести и настроить в облаке 1С;
переложить обслуживание инфраструктуры на облачного провайдера;
выстроить бэкапы и аварийное восстановление.
📅 Когда? 11 ноября в 11:00 мск.
📍Где? Встречаемся онлайн. Регистрируйтесь на странице вебинара — и до скорой встречи.
Первые заметки с GITEX GLOBAL 2025
GITEX в Дубае из года в год подтверждает, что это не просто выставка, а политико-технологическая витрина региона. Государственные ИИ, «суверенные» облака, умный транспорт, автоматизированные госуслуги — всё это разворачивается на фоне гонки за цифровую независимость. В этом году площадка разделена на крупные тематические треки — ИИ, безопасность, инфраструктура, индустриальные решения, системный и промышленный софт и т.д.
Первое и, пожалуй, главное наблюдение – это особое внимание к теме ИТ-безопасности, которая явно стала необходимостью. Главными запросами рынка стали отказоустойчивость и непрерывность бизнес-процессов, что заметно не только в России, но и по всему миру. Это подтверждает и масштаб секции по безопасности, и широта географии. Теперь задачи производителей решений класса СРК типа Veeam или Acronics не ограничиваются только копированием данных. Они обеспечивают шифрование, консистентность, безопасность передачи данных и обнаруживают аномалии в процессе копирования. Резервное копирование больше не воспринимается как рутинная строка в статье расходов на инфраструктуру компании, а становится частью безопасности и устойчивости бизнеса.
Отдельная тема дискуссий — этика и приватность. Каждая ИИ-новинка сопровождается обсуждением того, что можно доверять ИИ и как предотвращать злоупотребления.
Что касается ИИ, то конкурировать теперь приходится не с его наличием, а с качеством интеграции. Поэтому ИИ теперь ощущается как рутинный слой стека, который ставят «по умолчанию» — поиск, суммаризация, рекомендации, автоматизация. Маркетинга, конечно, тоже хватает: «AI-ready», «AI-powered» встречается на каждом втором стенде. Но, судя по интересу посетителей, бизнес отлично понимает, что смысл в применимости, а не в вывеске.
Из показательных примеров — AI-автомобили, которые патрулируя по городу, в реальном времени могут выявлять нарушения визового режима, рядом — демонстрация «умных полицейских станций», автоматизированных пунктов обслуживания граждан (вспомним времена, когда Робокоп казался далеким будущим). Такие примеры хорошо иллюстрируют сдвиг к прикладным государственным сервисам.
Обойти всё за один день объективно нереально. Масштаб и география участников впечатляют. Поэтому планирую ещё одно посещение, чтобы собрать больше информации про облачные решения и последние тренды на рынке СРК. А заодно добраться до российских стендов: судя по программе и экспозиции, там тоже есть что показать.
Главный вывод на сегодня: GITEX-2025 — уже не про «космические корабли», а про реальную применимость: отказоустойчивость, безопасность, стоимость владения. AI никуда не делся, он просто растворился в продукте.
Сделал браузерное расширение для загрузки на Wikimedia Commons, бесплатное FOSS, пожалуйста пользуйтесь - загружайте туда картинки, фотки, что со свободной лицензией. Расширение без зависимостей и библиотек, простое. Спасайте данные от потери - мы живём в горящей библиотеке. Commons это ещё и бесплатный хостинг изображений, public only.
Ранее я писал про свой скрипт для gThumb.
Могу помочь вам реализовать загрузку в Комонс из вашего софта, в виде плагина/скрипта. Ты только загружай, хоть иногда.
Как построить эффективную стратегию бэкапа
Любая стратегия бэкапа проверяется не в теории, а в проде. В блоге «Хайстекс» вышла первая статья, где QA-инженер Юлия Воробьёва показывает как построить систему резервного копирования с Хайстекс Акура и S3-хранилищем Selectel. Реальный кейс и пошаговый разбор: от выбора хранилища до восстановления инфраструктуры. Всё глазами автора, который сам настраивал и тестировал.
Что внутри:
Рабочая архитектура. Одно целевое облако с двумя подключениями: к площадке восстановления (поднимаем ВМ при необходимости) и к объектному хранилищу — S3 Selectel, где лежат точки восстановления.
Агенты. Внешние для VMware и внутренние в ОС конкретной ВМ. Репликация односторонняя, по защищенному каналу и без просадок продакшена.
Расписания и RPO. Расписание от непрерывных запусков до Unix Crontab. Контроль исполнения на стороне Акуры, человеческий фактор «забыл сделать бэкап» исключен.
Retention. Политика на уровне ВМ, группы или всего клиента, под любые контуры и SLA.
Хранение в S3. Данные режутся на настраиваемые чанки с метаданными; нулевые блоки не сохраняются, таким образом экономим место и деньги.
Восстановление. Предсказуемые сценарии: полный подъем ВМ через Cloud Site и файловое восстановление «на месте» из S3. При необходимости возможны RAW-экспорт и failback.
Бэкап — это не галочка в чек-листе, а процесс, которым нужно управлять, от выбора хранилища до проверенного сценария восстановления. Мы показали рабочую схему без магии и ручной возни. Под катом детали, скриншоты и пошаговые действия. В комментариях можно обсудить ваши кейсы, грабли и метрики: как настраиваете retention, чем меряете RTO/RPO и что помогло сократить простои.
А что б не вспомнить такой носитель данных, как перфолента?
Вот смотрите: допустим, 5 мкм лавсан, потом 1 мкм алюминий и снова 5 мкм лавсан. УФ-лазер с механическим приводом перфорирует поперёк ленты дорожки с шагом, скажем, тот же 1 мкм (УФ может и лучше, но пока не будем пальцы гнуть). Поскольку механика позиционирует луч с точностью до «куда-то туда» — применяем старые добрые старт- и стоп-биты.
На ленте шириной в 5 мм мы легко пробьём 4096 бит, старты, стопы и ещё останется запас с краёв. А чтобы прочитать её значительно быстрее, чем мы это макраме вымучивали — берём линейную ПЗС-матрицу от сканера (разрешение 1×16384 или примерно того порядка), сканируем всю ширину ленты разом, ну и (ваш Кэп) просто её протягиваем. Перекосы головки чтения относительно головки записи решаются кольцевым буфером — там хранится несколько последних строчек и нет никаких проблем найти там реальное положение дорожек, я такие синхронизации за пучок пятачок делал, задача детская.
В результате наши 4 килобита на микрон дают 512 терабайт в габаритах кассеты C-90, минус Рид-Соломон. Если я, конечно, по причине крайней усталости в нулях не запутался. Вот такая вот перфоленточка…
В Облаке Рег.ру запустили услугу резервного копирования
Добавили в облачной платформе возможность автоматизированного создания, хранения и восстановления резервных копий. Этот релиз — первый шаг по запуску полноценного Backup as a Service в Облаке Рег.ру.
Что внутри нового сервиса:
настройка расписания бэкапов и снапшотов;
удаленное хранение бэкапа;
восстановление сервера до нужного состояния, если возникнет такая необходимость;
создание снапшотов.
Теперь пользователи могут сами настраивать политику хранения бэкапа — от ежемесячной до ежедневной. На случай локальных сбоев предусмотрели защиту от потери данных — консистентные резервные копии хранятся в удаленном объектном хранилище S3. Отсюда и повышенная катастрофоустойчивость инфраструктуры пользователей в целом. Тарификация происходит по модели pay-as-you-go за фактический объем хранения.
Следите за нашими новыми обновлениями!