Переход на PostgreSQL и отечественные СУБД требует пересмотра привычных подходов к бэкапам. ИТ-специалистам приходится выбирать между нативными утилитами и централизованной системой резервного копирования. На вебинаре разберем, как найти оптимальный баланс, и на примере Postgres Pro покажем сценарии защиты и быстрого восстановления данных с Кибер Бэкапом.
15.10.2026в 11:00 МСК проведем онлайн вебинар, на котором обсудим следующие темы:
Вызовы миграции
Почему при переходе на российские СУБД не обойтись старыми методами защиты
Эволюция поддержки бэкапа PostgreSQL в Кибер Бэкапе
Как мы развивали поддержку от версии к версии
Инкрементный бэкап и восстановление
Современные сценарии для баз данных
Кластерные конфигурации
Нюансы защиты распределенных сред
Демонстрация
Установка и настройка агента для PostgreSQL, инкрементный бэкап и восстановление данных, подходы к решению типовых проблем.
Привет, Хабр! Еще недавно миграция ИТ-инфраструктуры казалась чем-то вроде капитального ремонта: один раз стиснул зубы, пережил хаос и дальше живешь спокойно. Но сейчас всё иначе, нагрузки постоянно перемещаются между on-premise, облаками и легаси-контуром.
В таких условиях старые подходы дают сбой. Когда жонглируешь тремя разными инструментами для миграции, бэкапов и DR, в критичный момент обязательно случается рассинхрон.
Поэтому мы в «Хайстекс» решили завести миграцию, бэкапы и аварийное восстановление в единый контур, так всё работает в прочной связке. Этот принцип лег в основу свежего релиза «Хайстекс Акура».
В ближайшую среду 30 сентября в 11:00 (МСК) проведем технический стрим и расскажем:
• Как на практике работает концепция управляемой мобильности рабочих нагрузок;
• Что нового появилось в решении: Backup 2.0, Object Lock, поддержка PostgreSQL, работа с OpenStack без привязки к СХД и DR через Direct2Target;
• Как сегодня сравнивать enterprise-решения по бэкапу и миграции;
• Покажем дорожную карту «Хайстекс Акура» до конца 2026 года.
Приносите схему своего контура, пишите в комментариях, с чем возникает больше всего сложностей. В эфире разберем вашу архитектуру и обсудим рабочий сценарий защиты и восстановления.
Хороший бэкап умеет не только сохранять, но и возвращать нужное
В большой инфраструктуре десятки тысяч машин, БД, контейнеров, платформ. И сценарии восстановления у всех свои: где-то нужно поднять всё с нуля, а где-то – вернуть один объект или несколько атрибутов. Российские вендоры последовательно движутся в сторону точности.
Свежий пример: в «Кибер Бэкапе Облачном» теперь можно выбирать отдельные объекты внутри Kubernetes. Резервируешь и восстанавливаешь только то, что действительно нужно, – не тащишь весь кластер ради одной ошибки.
Не просто «есть копия», а умение достать из неё именно то, что сломалось, и не трогать остальное.
Тот же принцип особенно важен для каталогов. В гетерогенных средах и особенно при миграции с AD на Linux инфраструктура становится сложнее: параллельные среды, скрипты, промежуточные состояния. И тут ошибка часто не убивает каталог целиком. Можно неверно изменить атрибуты пользователей, удалить группу, разорвать связи — система продолжит работать, но доступы поедут.
Восстанавливать весь каталог из полной копии — как из пушки по воробьям.
Нужно найти, что именно сломалось, и вернуть только это — один объект, один атрибут. Это и есть гранулярное восстановление. Оно не отменяет полное восстановление — это разные сценарии. Пожар в дата-центре и кривой скрипт, поменявший одну группу, лечатся по-разному.
Простая логика для каталога: перед миграцией сделал копию, потом сравнил состояния и точечно исправил последствия.
И здесь Kubernetes и каталог оказываются ближе, чем кажется: бэкап ценен не только фактом наличия, но и тем, насколько точно ты можешь им воспользоваться, когда что-то пошло не так.
Как выстроить аварийное восстановление в гибриде и мультиоблаке. Вебинар Хайстекс
Привет, Хабр! Гибридная инфраструктура дает гибкость в штатном режиме, но превращается в хаос при серьезном сбое. Когда в едином контуре связаны локальные серверы, облака и унаследованный сегмент, обычный бэкап перестает гарантировать понятные сроки восстановления.
26 августа в 11:00 (МСК) команда Хайстекс проведет вебинар. Эксперты разберут, почему в гибридной инфраструктуре недостаточно просто настроить бэкап, и покажут на практике, как в Хайстекс Акура выстраивать сценарии восстановления для разрозненных платформ и площадок.
Что обсудим:
где чаще всего ломаются бэкап и репликация – сеть, окна копирования, ручные операции, ограничения площадок;
когда достаточно резервной копии, а когда уже нужен полноценный DR-сценарий;
почему заявленные RTO/RPO без тестовых восстановлений мало что значат;
как организовать восстановление между разными площадками и платформами.
После основной части спикеры проведут Q&A-сессию: можно принести архитектуру своего контура в чат и получить разбор от инженеров Хайстекс.
Пост призван показать, насколько инструменты тестирования и автоматизации на самом деле привязаны к конкретной реализации браузера. Если вы пришли за технической информацией, то TL;DR: если хотите автоматизировать скачивание файлов через браузер - используйте Chromium-based
Первая версия утилиты работала очень топорно и работала на 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 на свою инфраструктуру, оставьте заявку — инженеры «Хайстекс» помогут рассчитать параметры хранилища для вашей инфраструктуры.
Как перестать надеяться на бэкап и автоматизировать Disaster Recovery
В одном из материалов я уже проводил границу между бэкапом и DR, которые решают принципиально разные задачи. Если бэкап — это архивный «огнетушитель», то DR — это система пожаротушения и план эвакуации. По реакции сообщества стало понятно: разницу осознают многие, но главный вопрос остается открытым — как обеспечить предсказуемый подъем сервисов, когда инфраструктура отказала?
Наличие резервных копий гарантирует, что данные не пропадут бесследно. Но бэкап не обеспечивает непрерывность бизнеса. При масштабном сбое восстановление из архивов вручную превращается в многочасовой (а иногда и многодневный) квест, который в условиях стресса часто ведет к человеческим ошибкам и увеличению простоя.
Чтобы перевести обсуждение из теории в плоскость работающих сценариев, мы с командой решили провести технический вебинар. 27 мая в 13:00 МСК в прямом эфире представим практические кейсы по восстановлению инфраструктуры после сбоя.
В программе:
Разберем почему бэкап не всегда спасает, и в какой момент нужен полноценный DR. Поговорим о том, как реалистично оценивать RTO и RPO.
Покажем сценарии восстановления инфраструктуры и посмотрим, какой подход работает лучше в каждой ситуации.
Покажем на практике:
восстановление данных через подключение дисков;
как это используется в реальных сценариях;
на что обратить внимание при восстановлении.
Вебинар будет полезен архитекторам, системным администраторам и всем, кто отвечает за доступность критичных систем. Приходите с вопросами по вашей инфраструктуре — разберем их в конце эфира во время сессии вопросов и ответов.
В финале встречи каждый участник получит актуализированный чек-лист для аудита плана аварийного восстановления.
Приходите на вебинар — покажем, как выстроить резервное копирование, которому можно доверять
Бэкап есть почти у всех. Но одно дело — хранить копии, другое — быть уверенным, что при сбое инфраструктура поднимется в нужные сроки и без потерь. Как перейти от «копии существуют» к «восстановление работает»?
Разберем это на совместном вебинаре с экспертами Cloud.ru и оператором ИТ-решений ОБИТ. Будет полезно ИТ-директорам, директорам по ИБ, системным архитекторам, инженерам и администраторам — всем, кто отвечает за сохранность данных в облаке.
Что расскажем и покажем:
какие практики резервного копирования актуальны сейчас и в чем их различия;
почему классическая стратегия 3-2-1 на практике может не выполнять свою функцию;
почему сторонний бэкап становится стандартом, а не опцией;
как опыт интегратора влияет на результат — и что меняется, когда интегратор и вендор работают в связке;
реальные кейсы: что именно это дает бизнесу.
В практической части пройдемся по интерфейсу SaaS-решения Cloud.ru. В прямом эфире покажем процесс восстановления машины из резервной копии через агента и разберем, как встроить решение в существующую инфраструктуру без глобальных переделок.
📅 Когда? 26 мая в 11:00 мск.
📍 Где? Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам в прямом эфире.
Я давний пользователь 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 в Дубае из года в год подтверждает, что это не просто выставка, а политико-технологическая витрина региона. Государственные ИИ, «суверенные» облака, умный транспорт, автоматизированные госуслуги — всё это разворачивается на фоне гонки за цифровую независимость. В этом году площадка разделена на крупные тематические треки — ИИ, безопасность, инфраструктура, индустриальные решения, системный и промышленный софт и т.д.
Стенд Google Cloud на GITEX 2025
Первое и, пожалуй, главное наблюдение – это особое внимание к теме ИТ-безопасности, которая явно стала необходимостью. Главными запросами рынка стали отказоустойчивость и непрерывность бизнес-процессов, что заметно не только в России, но и по всему миру. Это подтверждает и масштаб секции по безопасности, и широта географии. Теперь задачи производителей решений класса СРК типа Veeam или Acronics не ограничиваются только копированием данных. Они обеспечивают шифрование, консистентность, безопасность передачи данных и обнаруживают аномалии в процессе копирования. Резервное копирование больше не воспринимается как рутинная строка в статье расходов на инфраструктуру компании, а становится частью безопасности и устойчивости бизнеса.
Отдельная тема дискуссий — этика и приватность. Каждая ИИ-новинка сопровождается обсуждением того, что можно доверять ИИ и как предотвращать злоупотребления.
Что касается ИИ, то конкурировать теперь приходится не с его наличием, а с качеством интеграции. Поэтому ИИ теперь ощущается как рутинный слой стека, который ставят «по умолчанию» — поиск, суммаризация, рекомендации, автоматизация. Маркетинга, конечно, тоже хватает: «AI-ready», «AI-powered» встречается на каждом втором стенде. Но, судя по интересу посетителей, бизнес отлично понимает, что смысл в применимости, а не в вывеске.
Из показательных примеров — AI-автомобили, которые патрулируя по городу, в реальном времени могут выявлять нарушения визового режима, рядом — демонстрация «умных полицейских станций», автоматизированных пунктов обслуживания граждан (вспомним времена, когда Робокоп казался далеким будущим). Такие примеры хорошо иллюстрируют сдвиг к прикладным государственным сервисам.
Обойти всё за один день объективно нереально. Масштаб и география участников впечатляют. Поэтому планирую ещё одно посещение, чтобы собрать больше информации про облачные решения и последние тренды на рынке СРК. А заодно добраться до российских стендов: судя по программе и экспозиции, там тоже есть что показать.
Главный вывод на сегодня: GITEX-2025 — уже не про «космические корабли», а про реальную применимость: отказоустойчивость, безопасность, стоимость владения. AI никуда не делся, он просто растворился в продукте.
