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

Первые заметки с 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 лет назад, ну и сегодня "на всякий случай" :)

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

Обновленный Кибер Бэкап Облачный

30.01.2025 расскажем о новых возможностях сервиса резервного копирования

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

Среди новинок в Кибер Бэкапе Облачном:

• Резервное копирование и восстановление данных российских СУБД на базе PostgreSQL – Tantor, Jatoba, Arenadata DB и Pangolin

• Защита корпоративных решений Почта VK WorkSpace и Диск VK WorkSpace

• Поддержка операционных систем Linux с версией ядра до 6.8

• Передача событий ИБ в журнал аудита

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

Прямой эфир начнется 30 января в 11:00 по московскому времени.

Регистрация на мероприятие - по ссылке.

Подключайтесь к вебинару «Как эффективно и просто делать бэкапы в облаке».

📅 Когда: 22 октября в 11:00 мск

📍 Где: онлайн

Бэкапы помогают минимизировать последствия нештатных ситуаций и снизить вероятность потери данных из-за сбоев, вирусов и кибератак. Как с помощью бэкапов приблизить уровень защиты данных к 100% и в разы уменьшить тревогу IT-специалистов и руководителей за сохранность информации?

На вебинаре эксперты Cloud.ru и оператор IT-решений «ОБИТ» расскажут, как делать резервное копирование быстро и эффективно. А еще покажут демо сервиса, который поможет настроить автоматические бэкапы за несколько кликов.

Вы узнаете:

• почему бизнесу важно делать резервное копирование и как делать его в облаке Cloud.ru;

• реальный опыт создания бэкапов под разные бизнес-задачи от оператора IT-решений «ОБИТ»;

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

• как работает сервис для создания бэкапов и репликации.

В конце вебинара можно будет задать вопросы экспертам Cloud.ru и «ОБИТ».

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

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

Оставляйте вопросы по теме в комментариях под этим постом 👇 — спикеры ответят на них в процессе встречи. 

ZPAQ - консольный append-only архиватор, способный эффективно снапшотить целые директории с тысячами файлов и/или BLOBы в десятки ГБ (хоть с целыми ФС внутри) в один единственный файл. В процессе архивирования используется дедупликация на уровне фрагментов данных, сохраняющая только уникальные последовательности, а сжатие осуществляется адаптивным алгоритмом, который подстраивается под характер самих данных. Поддержка шифрования тоже имеется.

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

Пример (не мой):

~7GB of Thunderbird mbox become ~6MB (!) in ~4 minutes.

Подход append-only архивирования zpaq, в сочетании с rsync --append дает возможность вывести инкрементальное резервное копирование на новый уровень (даже для такого простого в использовании инструмента) и приблизиться к теоретическому пределу эффективности сжатия на реальных задачах, по сравнению с классическими архивами.

Разработка не новая, оригинальный проект zpaq более не развивается, но присутствует в некоторых дистрибутивах. А также существует вполне живой форк, совместимость формата архива с оригинальным zpaq сохранена: https://github.com/fcorbelli/zpaqfranz

Tg: lomalkin_log

На днях вышел из строя ИБП. Переключился на стабилизатор. Было уже. До техники APC стоял ИБП Ippon Smart Winner 750. Мониторил напряжение. Сохранял в базе данных SQL сервера IBM DB2 Express-C 10.5 данные за каждую секунду и хранил в течение года. Это помогло выставить уставки на реле напряжения и нормально пережить несколько отгораний нуля без потерь для техники. Скрипты соответствующие опубликовал сегодня на GitHub у себя. При работе от стабилизатора приходилось потом чинить неоднократно SQL базу данных, благо у меня было настроено журналирование в "Архивном" режиме, а сама база данных периодически тестировалась на наличие повреждений. Сложнее с остальной частью данных на компьютере: в NTFS принято частичное журналирование и внезапное отключение ведёт к необходимости решать, восстанавливать ли из бэкапа или соглашаться с тем, что возможно какие-то повреждения будут не сразу обнаружены и могут вызвать проблемы с дальнейшим ремонтом. Чуть раньше такой же пост на Дзене у себя опубликовал.

Всем DevOps! Однажды один из наших клиентов обнаружил, что резервные копии ClickHouse, которые он хранит в S3 провайдера CROC, не очень-то и шифруются. Была поставлена задача: настроить шифрование бэкапов.

В своей новой статье Николай, наш DevOps-инженер, показал, как мы это сделали. Он разобрал основные методы шифрования данных на стороне сервера в Amazon S3 — SSE-C, SSE-KMS и SSE-S3, расписал плюсы и минусы работы с clickhouse-backup и продемонстрировал, как легко восстановить данные из шифрованных бэкапов.

💻 Если ещё не читали, то нажмите сюда, чтобы начать.

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

О том, что может привести к катастрофе и как от неё защититься, рассказывает технический директор OXYGEN Михаил Нестеров. В видео — подробный разбор угроз, логика организации Disaster recovery, обсуждение технических нюансов и ответы на каверзные вопросы. Приятного и полезного просмотра!

Этот ролик — запись доклада Михаила на митапе OXYGEN в Санкт‑Петербурге. Подробно про мероприятие можно почитать вот здесь.

А у вас есть опыт организации Disaster recovery? Как вы вообще делаете бэкапы? И какие самые необычные причины аварий встречались в вашей практике? Расскажите об этом в комментариях!

И обязательно подписывайтесь на наш канал в Telegram, там мы не только постим новости про IT, но и рассказываем про облака, дата‑центры и кибербез.