Резервное копирование *

Импортозамещение по частям: бэкап один, а Linux у всех разный

Увидел новость о том, что «Киберпротект» выпустил «Кибер Бэкап Старт» – бэкап Windows и Windows Server для физлиц и малого бизнеса.

Бэкап уже российский, а операционная система всё ещё Microsoft

Ничего необычного. В небольшой компании инфраструктура вполне может состоять из нескольких рабочих станций на Windows и одного Windows-сервера. Службы каталога нет. Задача простая: сломался компьютер – вернуть данные и систему.

А что происходит, когда инфраструктура становится больше и в ней появляется Linux?

Windows перестаёт быть единственной платформой

Российский Linux сегодня – скорее лоскутное одеяло, чем одна платформа.

В рейтинге российских ОС CNews 2026 перечислены Astra Linux, Альт, РЕД ОС, РОСА Хром, ОСнова, UBLinux, АльтерОС, Platform V SberLinux OS Server, ОС «Атлант» и EcoRouterOS.

Поэтому совместимость СРК приходится проверять точнее, чем «Linux – да/нет». «Кибер Бэкап» 18.6, к примеру, поддерживает не все российские ОС. Заявлены Astra Linux, Альт, РЕД ОС, РОСА «КОБАЛЬТ» и «ХРОМ», AlterOS и ОСнова, а также ряд зарубежных дистрибутивов. При этом UBLinux, SberLinux, ОС «Атлант» и EcoRouterOS в этой матрице не указаны.

Это не значит «не работает». Наличие слова Linux в описании продукта ничего не гарантирует для конкретного контура. Матрицу совместимости проверяют руками под свою ОС, версию и сценарий.

А что со службой каталога?

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

Проблема не обязательно в падении сервера. Каталог может оставаться доступным, пользователи продолжают входить в систему, но у нескольких сотен человек изменились атрибуты, членство в группах или права из-за неправильно отработавшего скрипта.

Классическая СРК восстанавливает машину, сервер, виртуальную среду или каталог после аварии. Но если из 10 000 пользователей неправильные данные получили 500, полный откат каталога – слишком грубо.

Поддержка каталога ≠ умение вернуть одного пользователя, группу или атрибут. Здесь нужны уже специализированные средства гранулярного восстановления, которые работают по другой логике: сравнить каталог с бэкапом и вернуть только нужные объекты и атрибуты.

С ростом инфраструктуры меняется задача защиты

Для одного компьютера достаточно вернуть Windows и файлы.
Для корпоративного Linux нужно проверить совместимость СРК с конкретным дистрибутивом, и техническими ограничениями. А для службы каталога – заранее понимать, что именно восстановится, если каталог жив, а данные уже сломаны.

Классическая СРК и гранулярное восстановление – не конкуренты, а два уровня защиты одной инфраструктуры. Они решают задачи разного масштаба и могут быть двумя уровнями защиты одной инфраструктуры.

Источники

1. CNews, 30.09.2026 – запуск «Кибер Бэкап Старт», назначение продукта и поддержка Windows. «Киберпротект» запускает «Кибер Бэкап Старт»

2. Документация «Кибер Бэкап» 18.6 – поддерживаемые ОС для агента Linux, версии ядра и glibc. Кибер Бэкап 18.6: поддерживаемые агенты и ОС

3. CNews – рейтинг российских операционных систем 2026. Российские операционные системы 2026

zVirt Backup: что нам известно о новом решении для резервного копирования ВМ

Если вы работаете с zVirt, то наверняка уже видели новости о zVirt Backup. Это совместное решение Orion soft и «Береста РК» для резервного копирования виртуальных машин в среде zVirt. Нам еще только предстоит протестировать решение, поэтому мы пока еще не делаем выводов о его работе. Но уже посмотрели, что заявляют разработчики.


Что внутри

Архитектура zVirt Backup строится вокруг нескольких компонентов.

Мастер-сервер отвечает за управление системой. Хранит актуальную конфигурацию, политики и задания, координирует остальные компоненты и предоставляет веб-консоль и REST API.

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

Есть и агенты, которые используются для работы с данными внутри гостевой ОС. Понадобятся, если одного бэкапа виртуальной машины недостаточно и нужно работать на уровне файловой системы, приложения или СУБД.

При этом zVirt и zVirt Backup останутся отдельными административными контурами. Управление виртуализацией и резервным копированием не объединяется в одну консоль.

Что умеет

Основной сценарий — резервное копирование ВМ в zVirt. Среди заявленных возможностей:

·        интеграция через Backup API — решение использует программный интерфейс zVirt для взаимодействия с платформой виртуализации;

·        поддержка работающих и остановленных ВМ;

·        работа с дисками в режиме RAW — прямой доступ к данным виртуальных дисков позволяет использовать их для резервного копирования и последующей работы с копиями;

·        Change Block Tracking (CBT) — при инкрементальном резервировании после создания полной копии система работает с изменившимися блоками, не передавая каждый раз весь объем данных;

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

·        масштабирование за счет нескольких силовых серверов;

·        кластеризация компонентов системы.

Для инфраструктуры с большим количеством ВМ сочетание инкрементального резервирования и параллельной обработки выглядит особенно интересно: потенциально оно позволяет сократить объем передаваемых данных и время выполнения заданий.

Планы на развитие продукта

Orion soft уже обозначил несколько направлений: расширенный мониторинг резервного копирования, сохранение структуры папок виртуальных машин и резервирование параметров SDN.

Последний пункт особенно интересен с точки зрения восстановления. Сам по себе бэкап дисков ВМ еще не означает, что после сбоя инфраструктуру получится быстро вернуть в рабочее состояние. Чем больше параметров окружения сохраняется вместе с данными, тем меньше ручной работы может потребоваться при восстановлении.

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

Мы пока воспринимаем zVirt Backup именно как решение, которое предстоит проверить руками. Для СРК это, пожалуй, самый честный тест: не то, сколько функций указано в списке, а то, получится ли восстановить данные тогда, когда они действительно понадобятся.

Подписывайтесь на наши каналы в Telegram и МAX и следите за новостями, чтобы следить за обзорами вендорских новинок.

Релизный вебинар - выход Кибер Бэкапа 19

Представим обновление нашего флагманского продукта — системы резервного копирования Кибер Бэкап 19.

В этой версии мы расширили возможности защиты PostgreSQL и СУБД на ее основе, обеспечили интеграции с новыми отечественными системами виртуализации и корпоративных коммуникаций. Также повышена масштабируемость и расширены возможности защиты уже поддерживавшихся отечественных почтовых сервисов. Реализованы интеграции с распространенной системой централизованного ИТ-мониторинга и решениями, обеспечивающими неизменяемость резервных копий. Разработана новая система уведомлений, включающая возможность их отправки в популярный отечественный мессенджер. Кроме того, мы переработали систему лицензирования и внедрили ряд других изменений.

25.10.2026 в 13:00 МСК проведем онлайн вебинар, на котором обсудим следующие темы:

• Расширенная интеграция с PostgreSQL и СУБД на ее основе: развитие многопоточности и новые механизмы защиты

• Интеграция с VMmanager и снижение нагрузки на сеть при защите ВМ под управлением VMware

• Интеграция с RuPost

• Развитие возможностей защиты Mailion и Exchange

• Повышенная масштабируемость защиты Почты VK WorkSpace

• Интеграция с Zabbix, MAX и новая система уведомлений

• Интеграция с решением для неизменяемого хранения резервных копий

• Новая система лицензирования

• Начало закрытого тестирования Кибер Медиасервера

Регистрация

Новый вебинар из серии «Быстрый старт»

Переход на PostgreSQL и отечественные СУБД требует пересмотра привычных подходов к бэкапам. ИТ-специалистам приходится выбирать между нативными утилитами и централизованной системой резервного копирования. На вебинаре разберем, как найти оптимальный баланс, и на примере Postgres Pro покажем сценарии защиты и быстрого восстановления данных с Кибер Бэкапом.

15.10.2026 в 11:00 МСК проведем онлайн вебинар, на котором обсудим следующие темы:

• Вызовы миграции

  • Почему при переходе на российские СУБД не обойтись старыми методами защиты

• Эволюция поддержки бэкапа PostgreSQL в Кибер Бэкапе

  • Как мы развивали поддержку от версии к версии

• Инкрементный бэкап и восстановление

  • Современные сценарии для баз данных

• Кластерные конфигурации

  • Нюансы защиты распределенных сред

• Демонстрация

  • Установка и настройка агента для PostgreSQL, инкрементный бэкап и восстановление данных, подходы к решению типовых проблем.

Регистрация

Миграция ВМ, бэкапы и DR в едином сервисном слое

Привет, Хабр! Еще недавно миграция ИТ-инфраструктуры казалась чем-то вроде капитального ремонта: один раз стиснул зубы, пережил хаос и дальше живешь спокойно. Но сейчас всё иначе, нагрузки постоянно перемещаются между 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

Есть у меня тулза для бэкапа фоточек с гугла - сделал ее когда бэкапилка 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, поляризуем и остужаем дальше. Теперь, если лазером расплавить, поляризация уйдёт. Вопросов только два — как прочитать и что мешает использовать обычный редкоземельный чугуний, который точно так же можно туда вплавить и потом намагнитить остывший диск могучим полем примерно как у ЯМР‑томографа (он же — МРТ), а размагнитить — выборочно, нагревая лазером. Там хотя бы примерно понятно, как читать потом — мы же получили магнитооптический диск, только очень большой, толстый, многослойный и стирается исключительно на заводе.