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

Я давний пользователь 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 за фактический объем хранения.

Следите за нашими новыми обновлениями!

Настройка бекапа вашей 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"

Теперь у вас есть надежная система бэкапов, которая защитит вас от большинства катастроф. В случае сбоя вы сможете быстро восстановить всю систему целиком, минимизируя простои и стресс.

Как добиться надежности, гибкости и экономии в условиях растущих объемов данных? Расскажем на вебинаре.

📆 Когда: 29 мая в 11:00 мск

📍 Где: онлайн

В условиях стремительного роста объема информации возникают требования к использованию новых подходов к управлению и защите данных. Но облачные технологии меняют правила игры. На вебинаре вы узнаете, как перенести операционные расходы по управлению данными на облачных провайдеров, оптимизируя процессы резервного копирования и аварийного восстановления. 

В программе:

• что такое резервное копирование и аварийное восстановление: отличия и необходимость в разных сценариях;

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

• причины использовать облако для обеспечения непрерывности данных;

• дополнительные концепты для защиты информации;

• демо: как настроить резервное копирование и аварийное восстановление в облаке.

Вебинар будет полезен всем, кого волнует обеспечение непрерывности и отказоустойчивости бизнеса: IT-директорам, системным администраторам, инженерам и архитекторам инфраструктуры.

Зарегистрироваться 👈

Миграция сервера GitLab: инструкция от практика

Нужно перенести GitLab на новый сервер, но боитесь потерять данные? Я покажу проверенный способ миграции, сохраняющий все проекты, настройки и историю.

Подготовка

Убедитесь, что:

• у вас есть root-доступ к обоим серверам;

• на старом сервере ≥50% свободного места;

• Вы знаете точную версию GitLab (критически важно!)

Шаг 1: Подготовка нового сервера

Установите идентичную версию GitLab на новую машину:

sudo apt-get update && sudo apt-get install -y curl openssh-server ca-certificates perl 
# Установка конкретной версии (пример для 17.5.5) 
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash sudo apt-get install gitlab-ee=17.5.5-ee.0

Шаг 2: Создание бэкапа на старом сервере

# Проверка свободного места 
df -h  
# Создаем резервную копию
sudo gitlab-backup create

Процесс создания бэкапа может занять от минут до часов.

Шаг 3: Копирование файлов на новый сервер

Важно! Используем nohup для обеспечения непрерывности процесса и SSH-ключ для безопасного соединения:

# Копирование файла секретов 
nohup /bin/bash -c 'rsync -avh --delete --rsync-path="sudo rsync" -e "ssh -o StrictHostKeyChecking=no -i k" /etc/gitlab/gitlab-secrets.json root@new-server:/etc/gitlab/gitlab-secrets.json'
# Копирование бэкапа 
nohup /bin/bash -c 'rsync -avh --delete --rsync-path="sudo rsync" -e "ssh -o StrictHostKeyChecking=no -i k" /var/opt/gitlab/backups/1742165326_2025_03_16_17.5.5_gitlab_backup.tar root@new-server:/var/backups/gitlab/1742165326_2025_03_16_17.5.5_gitlab_backup.tar'

Примечание: В примере k — это файл приватного ключа. Файл конфигурации (gitlab.rb) намеренно не копируем, но при необходимости полной копии скопируйте и его.

Шаг 4: Восстановление на новом сервере

Сначала остановите необходимые сервисы:

sudo gitlab-ctl stop puma 
sudo gitlab-ctl stop sidekiq

Затем запустите восстановление (с nohup для надежности):

nohup /bin/bash -c "gitlab-backup restore BACKUP=1742165326_2025_03_16_17.5.5 force=yes"

Важно: Идентификатор бэкапа — это часть имени файла до gitlabbackup.tar. Параметр force=yes избавляет от подтверждений.

Шаг 5: Перезапуск и проверка

sudo gitlab-ctl restart 
sudo gitlab-ctl reconfigure  
# Проверки целостности данных 
sudo gitlab-rake gitlab:check SANITIZE=true 
sudo gitlab-rake gitlab:doctor:secrets 
sudo gitlab-rake gitlab:artifacts:check 
sudo gitlab-rake gitlab:lfs:check 
sudo gitlab-rake gitlab:uploads:check

Финальная проверка

Убедитесь, что:

• вход работает;

• репозитории открываются;

• CI/CD пайплайны запускаются;

• все проекты на месте.

Типичные проблемы и их решение

Ошибка 502 при доступе к некоторым репозиториям:

sudo gitlab-ctl restart 
sudo gitlab-ctl reconfigure

Рекомендации от практика

1. Тестовая миграция: Сначала попробуйте на тестовом сервере.

2. Окно обслуживания: Предупредите команду заранее.

3. Резервный план: Не выключайте старый сервер до полной проверки нового.

4. Мониторинг: Следите за логами первые дни после миграции.

5. DNS: Обновите DNS-записи после успешной миграции.

Заключение

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

Подробнее: docs.gitlab.com/ee/administration/backup_restore/restore_gitlab.html

Бонус: инструмент для построения последовательности обновления гитлаба

На пределе железа: протестировали резервное копирование 32 виртуальных машин с дедупликацией «на лету»

Один из сценариев тестирования СХД TATLIN.BACKUP и СРК Кибер Бэкап, в котором резервное копирование производилось с inline-дедупликацией внутри каждой ВМ.

В каждую из 32 виртуальных машин установлены агенты Кибер Бэкапа, а также агенты Tboost, протокола дедупликации в TATLIN.BACKUP. Каждый агент сохраняет резервную копию в локальную папку, подключенную к целевому хранилищу через протокол T‑BOOST (точка монтирования /mnt/esxboost)​. В качестве хранилища резервных копий в Кибер Бэкапе указано 32 хранилища — по числу ВМ.

График показывает, что мы достигли ограничений оборудования: пропускной способности четырех портов Ethernet по 25 Гбит/с, через которые подключен диск TATLIN.UNIFIED к хостам виртуализации. 

Совокупный объем данных, переданных Кибер Бэкапом для полного резервного копирования всех ВМ, составил ~ 4 192 ГБ (32 × 131 ГБ). Параллельно выполнялись 32 операции резервного копирования. Время выполнения операций — от 8 до 11 минут.

Про совместное использование TATLIN.BACKUP и Кибер Бэкапа читайте в статье с результатами тестирования трех сценариев резервного копирования 32 виртуальных машин.

10 апреля в 13:00 по московскому времени расскажем как оптимизировать расходы на хранение резервных копий

О мероприятии

Это второе совместное мероприятие Киберпротекта и YADRO в рамках технологического партнерства двух компаний. На первом вебинаре мы рассказали о преимуществах использования СХД TATLIN.BACKUP для хранения резервных копий, создаваемых Кибер Бэкапом. В этот раз рассмотрим технологию YADRO T-BOOST, которая позволяет выполнять дедупликацию данных на источнике (защищаемом хосте или узле хранения Кибер Бэкапа) и передавать в хранилище только уникальные данные, что обеспечивает минимизацию объема передаваемых данных и ускорение резервного копирования.

На вебинаре вас ждут:

• Краткий обзор возможностей СРК Кибер Бэкап и СХД TATLIN.BACKUP

• Разбор сценариев совместного использования продуктов

• Демонстрация резервного копирования средствами Кибер Бэкапа на TATLIN.BACKUP с использованием технологии T-BOOST

Подключайтесь к трансляции 10 апреля в 13:00 по московскому времени и готовьте вопросы для наших экспертов!

Мероприятие будет полезно руководителям и ИТ-специалистам компаний, которым важно обеспечить сохранность данных.

Регистрация

Спикеры

Тимур Гусейнов

Менеджер продуктового маркетинга, Киберпротект

Павел Филин

Ведущий менеджер продукта TATLIN.BACKUP, YADRO

Как оптимизировать расходы на резервное копирование

10 апреля в 13:00 подключайтесь к вебинару, где специалисты YADRO и Киберпротект расскажут об эффективном использовании системы резервного копирования (СРК) в связке с системой хранения данных (СХД). СРК занимается резервным копированием и восстановлением данных, а СХД — их надежным хранением, компрессией и дедупликацией. 

В прямом эфире вы сможете:

• узнать о возможностях СРК Кибер Бэкап и СХД TATLIN.BACKUP,

• выбрать подходящий сценарий их совместного использования,

• посмотреть в реальном времени, как происходит резервное копирование средствами Кибер Бэкапа на TATLIN.BACKUP с помощью T-BOOST,

• задать вопросы экспертам.

Одной из тем вебинара станет технология T-BOOST. Она позволяет выполнять дедупликацию данных на источнике: защищенном хосте или узле хранения Кибер Бэкапа. После дедупликации в хранилище передаются только уникальные данные. Это позволяет минимизировать объем передаваемых данных (снизить нагрузку на сеть) и ускорить резервное копирование.

Принять участие в вебинаре →

Какие проблемы решает алгоритм FastCDC при дедупликации данных

FastCDC — это алгоритм разбиения данных на блоки переменной длины (Content Defined Chunking, CDC). В отличие от нарезки с фиксированной длиной блока, FastCDC решает проблему смещения границ (boundary-shift problem), которая возникает при вставке новых данных в файл. Например, если в начало файла добавить байт, то при использовании разбиения с фиксированной длиной все последующие блоки изменятся.

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

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

Основная идея FastCDC заключается в следующем: среди всех возможных последовательностей байтов (множество A) выделяется подмножество B. Когда в файле обнаруживается последовательность из множества B, алгоритм устанавливает границу блока (anchor) сразу после этой последовательности.

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

После нахождения опорного байта (anchor) алгоритм проверяет, удовлетворяет ли он дополнительным условиям. Например, FastCDC не создаст новый блок, если точка находится слишком близко к границе предыдущего блока и минимальный размер блока еще не достигнут. Если опорные байты не найдены, система отрежет блок по его максимально допустимому размеру. 

Добавление всего одного нового байта 0 сдвигает все предыдущие байты вправо, что приводит к изменению содержимого каждого блока:

Эксперт по разработке ПО отдела систем обработки данных в YADRO Ростислав Ефремов в статье подробно объяснил, что такое дедупликация данных, какую роль она играет в системах резервного копирования и как работает в СХД TATLIN.BACKUP

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

@start "split into BD-RE slices" %comspec% /k py .\bd_split.py %~nx1

#! python3.13

import sys


BUF_SIZE = 1024 * 1024
FS_SIZE = 2048 * 512 # кратно BUF_SIZE, значит можно использовать сравнение count == BD_DISK_SIZE
BD_DISK_SIZE = 25025314816 - FS_SIZE

file_name = sys.argv[1]
source = r"K:\backup\2311\{0}".format(file_name)
dest_head = r"D:\kvk\YandexDisk\Acronis\{0}".format(file_name)

with open(source, "rb") as input:
    part = 1
    while True:
        count = 0
        with open(dest_head + ".{0:02d}".format(part), "wb") as output:
            bytestring = input.read(BUF_SIZE)
            while bytestring:
                count += output.write(bytestring)
                if count == BD_DISK_SIZE:
                    part += 1
                    break
                elif count > BD_DISK_SIZE:
                    raise Exception("Превышен максимальный размер диска для части {0}...".format(part))
                bytestring = input.read(BUF_SIZE)
            else:
                break

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

Сегодня в процессе проверки подключил внешний жёсткий диск с бэкапами, для самой маленькой резервной копии из недавних посчитал SHA256, восстановил её же из облака вместе с подписями, проверил их, собрал эту инкрементную резервную копию из кусочков, проверил SHA256. Совпали. Последний раз проверял по такой схеме наверно более 10 лет назад, ну и сегодня "на всякий случай" :)

А вообще у меня бэкапы проверяются периодически (какие автоматически после каждого резервного копирования, какие вручную еженедельно), а восстановление из копии при изменениях в "железе" и обновлении софта обычно.