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

На пределе железа: протестировали резервное копирование 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, но и рассказываем про облака, дата‑центры и кибербез.