Commvault часть 5. Дедупликация и компрессия

Сегодня отложим подальше наши мышки, возьмём карандаш или ручку и будем поглощать много теории. Даже картинок не будет 🙂 Эффективность хранения резервных копий зависит от двух механизмов: дедупликации и компрессии, сегодня мы и будем разбираться как они устроены и работают в Commvault. От того, насколько правильно они настроены, напрямую зависит, сколько реального места на диске займут бэкапы, сколько трафика уйдёт по сети при репликации между площадками, и как быстро система переживёт сбой DDB без потери данных. Неправильный сайзинг DDB или случайный sealing способны за одну ночь удвоить занятое место на хранилище — тема теоретическая, но прямо влияющая на бюджет инфраструктуры.

В этой статье вы узнаете:

• как физически работает дедупликация на уровне блоков и почему у разных типов данных разный порядок операций и разный коэффициент дедупликации;
• в чём разница между source-side и target-side дедупликацией и какой режим выбрать;
• как правильно спланировать диск под DDB, чтобы не упереться в производительность при росте объёма данных;
• что такое DASH Full и DASH Copy и почему они кардинально ускоряют синтетические полные копии и репликацию;
• как обслуживать DDB — sealing, reconstruction, verification — и почему истечение retention не означает мгновенное освобождение места на диске.

Терминологическая оговорка: везде в этом модуле «дедуплицированное хранилище» означает Disk Library или Storage Pool, для которых включена программная дедупликация самого Commvault (со своей DDB). Это не имеет отношения к специализированным дедуплицирующим СХД, о которых мы говорили недавно в статье S3 Object Lock, Immutable и все-все-все: как это реализовано.

Если данные пишутся на подобную СХД, со стороны СРК для такого хранилища обычно отключают дедупликацию и компрессию или переключают в наиболее «лёгкий» режим, т.к. двойные операции не дадут эффективности, но скажутся на производительности резервного копирования.

1. Как работает дедупликация на уровне блоков

1.1 Общий процесс

Дедупликация в Commvault работает не на уровне файлов, а на уровне блоков данных фиксированного размера. Общий алгоритм для каждого блока:

1. Агент на клиенте (или MediaAgent, в зависимости от конфигурации) читает данные и разбивает их на блоки
2. Для каждого блока вычисляется хэш, уникально представляющий содержимое блока
3. Хэш сравнивается с записями в DDB
4. Если такого хэша в DDB ещё нет — блок считается уникальным и записывается в хранилище, а его хэш добавляется в DDB
5. Если хэш уже существует в DDB — блок считается дубликатом, физическая запись не происходит, вместо этого создаётся ссылка на уже существующий блок, а в индекс объекта добавляется соответствующая запись

Сравнение сигнатур происходит на уровне MediaAgent: он обращается к DDB и принимает решение «писать или не писать». Восстановление данных DDB не использует: для чтения нужен только индекс, который указывает, из каких блоков собран объект и где эти блоки физически лежат.
Размер блока, для которого генерируется хэш, задаётся в свойствах Storage Policy и определяет гранулярность дедупликации.

• Диапазон: 32–512 KB
• Значение по умолчанию: 128 KB
• Для крупных баз данных Commvault рекомендует блоки большего размера

Почему 128 KB? Уменьшение размера блока увеличивает шанс найти совпадение (более гранулярная дедупликация), но одновременно линейно увеличивает число хэшей, которые нужно хранить и сравнивать — а значит, растёт сама DDB и нагрузка на неё.

Важное ограничение: если изменить размер блока на хранилище, где уже есть данные, произойдёт полный re-baseline. Новые хэши, посчитанные для нового размера блока, не совпадут со старыми, и все последующие бэкапы начнут писаться заново как уникальные данные. Менять размер блока можно только запечатав (sealed) текущую DDB и создав новую — на лету, без остановки заданий, это не делается.

1.2 Роли MediaAgent при дедупликации

При работе с дедуплицированным хранилищем MediaAgent может выполнять одну из двух ролей (или обе одновременно на небольших стендах):

• Data Mover — имеет доступ на запись к дискам хранилища, физически пишет блоки данных
• Deduplication Database (DDB) MediaAgent — хранит и обслуживает саму DDB, отвечает за сравнение хэшей

В крупных средах эти роли разносят на разные серверы: Data Mover обслуживает интенсивный поток записи в Disk Library, а выделенный DDB MediaAgent — интенсивную случайную нагрузку сравнения сигнатур. Совмещение ролей нормально для тестовых и небольших продуктивных сред, но при росте объёма данных узким местом становится DDB MediaAgent — сравнение хэшей упирается в IOPS диска, на котором лежит DDB.

1.3 Отдельная DDB для каждого типа данных

Важный архитектурный момент, который часто упускают: Commvault не использует одну общую DDB для всех типов защищаемых данных. При создании Storage Pool с дедупликацией система создаёт DDB, но при первом бэкапе конкретного типа данных она переименовывается с учётом типа: StoragePoolName_Files_DDBStoreID для File System, StoragePoolName_VMs_DDBStoreID для виртуальных машин, StoragePoolName_Databases_DDBStoreID для баз данных.

Если в этот же Storage Pool потом начинают писать данные другого типа — для них создаётся отдельная новая DDB, даже если физически это один и тот же диск и один и тот же пул.

Почему это важно: дедупликация ищет совпадения блоков только внутри одной DDB. Файловая шара и VMDK виртуальной машины пишутся в разные DDB одного Storage Pool — а значит, между ними дедупликации не будет, даже если внутри VM лежат точно такие же файлы, что и на файловой шаре. Дедупликация «за пределы одного типа данных» в рамках одного пула не работает.

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

Виртуальные машины. VSA не работает с отдельными файлами внутри VM — он читает VMDK как последовательность блоков на уровне диска, не зная о границах файлов внутри гостевой файловой системы. Общий принцип дедупликации тот же — компрессия, затем хэш, сравнение с DDB, — но применяется он не к файлам, а к сырым блокам виртуального диска.

Практическое следствие: если на двух разных VM лежат тысячи одинаковых файлов, дедупликация между ними всё равно возможна, но коэффициент будет ниже, чем при бэкапе тех же файлов через File System Agent. Причина — физическое расположение идентичных файлов на разных VMDK почти никогда не совпадает. Гостевая ОС, файловая система, фрагментация сдвигают границы.

Базы данных. Здесь работает уже описанный в разделе 3.1 обратный порядок операций — хэш считается до компрессии, что даёт заметно лучшую дедупликацию для крупных БД по сравнению с обратным порядком.

На практике из-за раздельных DDB стоит закладывать это при планировании Storage Pool: если требования к retention сильно различаются для файловых данных, VM и баз данных, разумно с самого начала развести их по разным Plans и Storage Pool, а не полагаться на то, что общий пул как-то сам распределит данные оптимально — реальной эффективности дедупликации между типами данных всё равно не будет.

1.4 Требования к диску под DDB и сайзинг

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

Официальные требования и рекомендации:

• DDB должна лежать на SSD, локальном для MediaAgent. SATA SSD для DDB не рекомендуются — недостаточная производительность случайного чтения/записи по сравнению с NVMe или SAS SSD
• DDB нельзя размещать в папке установки самого Commvault, а только на отдельном томе или разделе
• Файловая система для диска под DDB: на Windows MediaAgent рекомендуется отформатировать том с размером кластера 32 KB — это снижает фрагментацию NTFS со временем. На Linux — 4 KB

Ёмкость под метаданные DDB: Commvault рекомендует закладывать 1% от общего объёма защищаемых данных под метаданные — этого достаточно для большинства сред. Для нагрузок с высоким коэффициентом дедупликации или огромным количеством мелких файлов метаданных на единицу полезного объёма будет больше, и диск под DDB стоит брать с запасом.

Партиционирование DDB — способ горизонтально масштабировать пропускную способность и надёжность. Партиции можно распределить по нескольким MediaAgent, при этом каждую партицию рекомендуется размещать на отдельном физическом диске — если несколько партиций делят один диск, преимущества параллелизма теряются.

При выборе числа партиций учитываются:

• Front-End TB — объём защищаемых данных на источнике
• Окно резервного копирования — время, отведённое на выполнение бэкапа
• Daily Change Rate — процент ежедневных изменений в данных
• Retention — как долго данные хранятся, прежде чем состариться

Чем больше любой из этих параметров, тем больше партиций стоит закладывать, чтобы уложиться в окно бэкапа при заданном объёме и скорости изменений.

Главное: дедупликация работает на уровне блоков фиксированного размера, а не файлов, и требует отдельной DDB под каждый тип защищаемых данных. DDB — самая требовательная к диску часть всей архитектуры: под неё нужен быстрый локальный SSD, а число партиций стоит планировать заранее, исходя из объёма данных, окна бэкапа и скорости их изменения.

2. Client-side и MediaAgent-side дедупликация

Ключевое архитектурное решение — где вычисляется хэш блока: на клиенте или на MediaAgent. Это определяет объём трафика, идущего по сети.

2.1 Source-side (client-side) дедупликация — рекомендуемый режим

Хэш вычисляется прямо на клиенте, до отправки данных по сети:

1. Агент на клиенте разбивает данные на блоки и генерирует сигнатуру для каждого
2. На MediaAgent передаётся только хэш — не сам блок
3. MediaAgent сравнивает сигнатуру с DDB
4. Если блок уникален — MediaAgent запрашивает у клиента передачу самого блока, клиент отправляет его, MediaAgent записывает на диск
5. Если блок уже существует — MediaAgent сообщает клиенту отбросить блок

Это принципиально снижает объём трафика между клиентом и MediaAgent — особенно ценно для сред с медленным или дорогим каналом (WAN, удалённые офисы, ноутбуки). Commvault прямо рекомендует source-side дедупликацию как основной режим для сценариев с ограниченной пропускной способностью, включая резервное копирование мобильных рабочих станций.

Дополнительно можно включить Source-Side Disk Cache — локальный кэш хэшей на самом клиенте. Тогда сравнение «есть ли такой блок» происходит частично локально, ещё до обращения к MediaAgent, что дополнительно снижает трафик на слабых каналах.

2.2 Target-side (MediaAgent-side) дедупликация

Альтернативный режим — Network Optimized: клиент отправляет данные, а фактическое сравнение с DDB и решение о записи принимается на стороне MediaAgent с использованием локального кэша. При этом трафик по сети выше, чем при чистой source-side схеме, но конфигурация проще и не требует ресурсов CPU клиента на генерацию сигнатур.

Главное: source-side дедупликация — рекомендуемый режим почти для всех сценариев с ограниченной сетью, потому что по каналу передаются только хэши, а не сами блоки. Target-side проще настроить, но нагружает сеть сильнее — выбор определяется тем, что является узким местом: пропускная способность канала или CPU клиента.

3. Компрессия

3.1 Порядок операций: компрессия, хэш, шифрование

Порядок, в котором Commvault выполняет компрессию, вычисления хэша для дедупликации и шифрование, не произволен и различается по типу данных:

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

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

3.2 LZO и GZIP — схемы программной компрессии

Commvault поддерживает две схемы софтовой компрессии с разными компромиссами между скоростью и степенью сжатия:

• LZO — быстрее по throughput, но может давать чуть больший объём записанных данных
• GZIP — лучше коэффициент компрессии, но заметно выше потребление CPU

Начиная с версии 11.20 новые клиенты и MediaAgent по умолчанию используют LZO. Существующие клиенты (кроме VSA-прокси), обновлённые с более ранних версий, продолжают использовать GZIP, если схему не менять явно. VSA-прокси используют LZO для Storage Policy, созданных начиная с 11 SP4. Схему компрессии можно переопределить на конкретном клиенте, если нужен другой баланс скорость/степень сжатия.

3.3 Где выполняется компрессия: клиент или MediaAgent

Software-компрессия может выполняться в одной из двух точек:

• На клиенте — данные сжимаются на клиенте до передачи по сети. Снижает объём сетевого трафика, но нагружает CPU клиента. Имеет смысл, если клиент и MediaAgent разнесены по сети
• На MediaAgent — данные передаются по сети в исходном виде и сжимаются уже на MediaAgent. Полезно, если MediaAgent заметно мощнее клиентов, либо клиентские серверы и так загружены прикладной нагрузкой и лишний расход CPU на компрессию нежелателен

Выбор — вопрос распределения нагрузки CPU между клиентом и MediaAgent, а не универсальное правило. Для сред с большим числом слабых клиентов и мощным MediaAgent разумно компрессировать на стороне MediaAgent; для сред с ограниченной пропускной способностью сети — на клиенте, чтобы уменьшить объём передаваемых данных.

3.4 Аппаратная компрессия — только для ленточных библиотек

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

Механика: несжатые данные передаются на привод, и сама лента сжимает их своей выделенной схемой перед физической записью — быстрее программной компрессии, поскольку выполняется отдельным контроллером, а не CPU сервера. Особенно эффективна в конфигурации direct-connect, где клиент и MediaAgent — один и тот же физический сервер и нет сетевого узкого места, ограничивающего скорость подачи данных на привод.

Hardware compression имеет приоритет над софт компрессией: если она включена, все данные компрессируются на уровне привода, а программная компрессия отключается автоматически.

Несколько важных нюансов:

• Если данные уже дедуплицированы и сжаты программно на primary copy, аппаратная компрессия при Auxiliary Copy на ленту не даст дополнительной экономии — сжимать уже сжатые данные бессмысленно
• Программное шифрование отменяет эффект аппаратной компрессии — зашифрованные данные не имеют предсказуемых паттернов и почти не сжимаются на лету приводом
• При аппаратной компрессии Commvault не может показать реальный сжатый размер данных — компрессия происходит уже после того, как система передала данные приводу, и что записалось физически, видно только в интерфейсе самой ленточной библиотеки

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

4. DASH Full — ускоренная синтетическая полная копия

4.1 Механика DASH Full

DASH Full — вариант Synthetic Full резервного копирования, оптимизированный для дедуплицированного хранилища. Обычный Synthetic Full собирает полную копию из предыдущего Full и последующих Incremental, физически читая и перезаписывая блоки в новый набор данных на стороне хранилища. DASH Full идёт дальше: раз данные уже дедуплицированы и физически лежат на диске, читать и перекладывать их незачем — достаточно обновить метаданные.

DASH Full обновляет записи в DDB и индексных файлах, отмечая, что полная резервная копия сформирована — без чтения единого блока данных с диска и без пересчёта сигнатур. Поэтому DASH Full выполняется значительно быстрее обычного Synthetic Full: нагрузка на дисковую подсистему хранилища минимальна, а операция сводится к обновлению метаданных, а не к перемещению данных.

4.2 Когда DASH Full запускается автоматически

При включённой дедупликации Commvault по умолчанию использует DASH Full вместо обычного Synthetic Full для большинства типов агентов — и Commvault прямо рекомендует этот режим. Дополнительно настраивать ничего не нужно, если хранилище дедуплицировано, Synthetic Full автоматически выполняется в оптимизированном режиме.

5. DASH Copy — репликация с дедупликацией

5.1 Разница между Auxiliary Copy и DASH Copy

Auxiliary Copy — базовый механизм копирования резервных копий из одного хранилища в другое. Это операция на уровне чанков резервной копии — данные копируются целыми чанками без анализа их содержимого.

DASH Copy — это Auxiliary Copy для дедуплицированной storage policy copy, при которой на приёмник передаются только уникальные блоки данных. Источник и назначение оба используют дедупликацию, и перед копированием каждого блока проверяется — есть ли он уже в DDB назначения. Если есть — блок не передаётся физически, копируется только ссылка.

5.2 Зачем это нужно

Для репликации между площадками DASH Copy кардинально экономит полосу пропускания WAN-канала: по сети идут только действительно новые блоки, а не весь объём данных заново. В документации Commvault это прямо описывается как эффективный и безопасный способ репликации с встроенной верификацией данных, аудитом и тестированием целостности — в отличие от переноса данных сторонними инструментами.

6. Обслуживание DDB

6.1 DDB Sealing — запечатывание базы

Sealing — операция, при которой Commvault прекращает использовать текущую DDB для поиска дубликатов и начинает вести новую, пустую базу сигнатур. Все данные, поступающие после sealing, воспринимаются системой как полностью новые и уникальные — происходит полный re-baseline, аналогично изменению размера блока резервного копирования.

Когда используется sealing:

• Изменение размера блока на хранилище, где уже есть данные
• Достижение порогового значения (threshold) — по количеству дней, месяцев или размеру самой DDB. Если задано несколько порогов одновременно, sealing срабатывает по первому достигнутому
• Необходимость создать чистую точку консолидации для специфичных сценариев
• Восстановление после повреждения DDB, когда реконструкция невозможна или нецелесообразна

Важное следствие sealing: старые данные, привязанные к запечатанной DDB, не начинают физически удаляться немедленно — они продолжают храниться до истечения собственного retention периода, как и было запланировано изначально. Реальное освобождение места происходит только после того, как последнее задание, связанное со старой DDB, устареет по retention.

6.2 DDB Reconstruction

Если DDB повреждена или физически недоступна, Commvault может пересобрать её из данных, уже находящихся в хранилище — этот процесс называется reconstruction.

Как это работает: DDB периодически бэкапится сама. Reconstruction использует последнюю резервную копию DDB как отправную точку, а затем выполняет replay записи об изменениях, которые произошли после этой резервной копии, читая метаданные из чанков в хранилище. Полная реконструкция может занимать значительное время, потому что требует чтения всего диска хранилища для восстановления полной картины сигнатур.

Реконструкция запускается автоматически при обнаружении Commvault повреждённой или недоступной DDB — либо администратор может инициировать вручную. Пока DDB не восстановлена, новые бэкапы в связанное хранилище выполняться не могут, хотя восстановление уже существующих данных остаётся доступным.

6.3 DDB Verification

Отдельный механизм проверки целостности — сверяет, что данные, на которые ссылаются записи DDB, физически присутствуют и не повреждены на диске.

Если verification систематически находит повреждённые блоки — это индикатор проблем на уровне самих дисков хранилища, а не программной ошибки Commvault. В такой ситуации логичным шагом становится проверка и, возможно, замена физического носителя, а не повторные попытки verification.

6.4 DDB partitions и масштабирование

Для повышения производительности и отказоустойчивости одну DDB можно разбить на несколько партиций (partitions), распределённых по разным MediaAgent. Это позволяет:

• Увеличить пропускную способность сравнения сигнатур за счёт параллельной обработки на нескольких серверах
• Продолжать работу, если одна из партиций временно недоступна — остальные партиции продолжают обслуживать запросы
• Масштабировать объём защищаемых данных за пределы возможностей одного DDB MediaAgent

Для восстановления единственной вышедшей из строя партиции применяется точечная процедура: партиция помечается для восстановления, затем запускается её индивидуальная реконструкция — без необходимости пересобирать всю DDB целиком.

6.5 Micro Pruning и Macro Pruning — как физически освобождается место

Data Aging — это логическая операция: она лишь помечает, какие задания устарели по retention и подлежат удалению, но сама ничего физически не стирает. Реальное освобождение места на диске выполняют отдельные механизмы pruning.

Micro Pruning — штатный режим для дедуплицированного хранилища. Отдельные блоки удаляются по мере того, как ни одно оставшееся (не устаревшее) задание больше на них не ссылается. Поскольку один и тот же уникальный блок может использоваться десятками заданий одновременно, удалить его можно только когда последняя ссылка на него исчезла. Именно поэтому истечение retention у одного задания не обязательно сразу освобождает место — блок остаётся, пока на него ссылается хоть одно ещё не устаревшее задание.

Macro Pruning — редкий, аварийный режим: удаление целого чанка целиком, без разбора на отдельные блоки. Происходит только тогда, когда абсолютно все задания, связанные с DDB, устарели логически: сама DDB уже запечатана, и все связанные с ней задания истекли по retention. При нормальной работе дедупликации macro pruning почти не встречается — это сценарий для случаев, когда DDB повреждена и обычный учёт ссылок на блоки недоступен, поэтому система вынуждена ждать полного истечения retention у всех данных, привязанных к этой DDB, и затем стереть всё разом.

Отдельный механизм — Space Reclamation (дефрагментация DDB). Со временем из-за постоянного micro pruning на диске образуются «дыры» — блоки удалены, но физическое пространство фрагментировано и не используется эффективно. Операция Space Reclamation дефрагментирует занятые данные, уплотняя их и высвобождая свободное пространство. Уровень агрессивности дефрагментации настраивается ползунком — от щадящего (меньше нагрузка на диск, дольше выполнение) до агрессивного. Для облачных хранилищ Space Reclamation требует включённого Micro Pruning на mount path — без этого условия операция недоступна.

Главное: DDB требует планового обслуживания — sealing при смене размера блока или достижении порога, reconstruction после сбоя, verification для проверки целостности. Физическое освобождение места идёт медленнее логического устаревания данных: истечение retention у задания не означает, что диск сразу очистится.

Типичные ошибки

• DDB и Disk Library — не одно и то же. DDB хранит только хэши и метаданные; сами блоки данных лежат в Disk Library. Путаница между ними мешает правильно спланировать дисковую подсистему — DDB нужен быстрый диск под случайную нагрузку (IOPS), Disk Library — ёмкость под последовательную запись.
• Один Storage Pool не означает одну DDB. Файлы, VM, базы данных и т.д. пишутся в раздельные DDB даже внутри одного пула, дедупликация между разными типами данных не работает, рассчитывать на неё при планировании не стоит.
• Изменение размера блока на хранилище с данными без sealing невозможно — это приведёт к полному re-baseline, а старые хэши не будут совпадать с новыми.
• Совместное использование стороннего аппаратного или программного дедупликатора вместе с дедупликацией Commvault не рекомендуется — двойная дедупликация не даёт выигрыша и усложняет диагностику.
• Sealing DDB — не «мягкая» операция обслуживания, а полная потеря накопленной дедупликации для новых данных. Настраивать автоматический sealing по threshold без явной необходимости не стоит.
• DDB не участвует в процессе восстановления данных. Если DDB повреждена, но данные бэкапов физически целы — восстановление доступно, а вот новые бэкапы в это хранилище выполняться не будут до завершения реконструкции базы.
• Истечение retention у задания не означает мгновенное освобождение места. Пока блок используется хоть одним ещё не устаревшим заданием, micro pruning его не тронет — реальное высвобождение диска может отставать от логического старения данных.
• Ручное удаление файлов DDB с файловой системы — то, чего делать нельзя никогда. Это обходит логику учёта ссылок на блоки и оставляет Commvault без возможности понять, какие данные ещё нужны.

Что нужно запомнить

• Дедупликация Commvault работает на уровне блоков (по умолчанию 128 KB), а не файлов — хэш вычисляется хэш-функцией и сравнивается с DDB на стороне MediaAgent.
• Source-side (client-side) дедупликация — рекомендуемый режим: по сети передаются только сигнатуры уникальных блоков, что критично экономит трафик в WAN-сценариях и для удалённых офисов.
• Порядок компрессии, вычисление хэшей и шифрование различается для файловых данных и баз данных — для баз сначала считается хэш, затем идёт компрессия, что даёт лучший коэффициент дедупликации.
• DASH Full — оптимизированная синтетическая полная копия, которая обновляет только метаданные DDB и индекса, не читая данные с диска. Используется автоматически при дедупликации.
• DASH Copy передаёт между хранилищами только уникальные блоки — существенно снижает нагрузку на WAN-канал при репликации между площадками.
• DDB требует регулярного обслуживания.
• DDB можно разбить на несколько партиций для масштабирования пропускной способности и отказоустойчивости.
• Схема программной компрессии выбирается по параметрам скорость/степень сжатия: LZO быстрее, GZIP даёт лучший коэффициент. Аппаратная компрессия существует только для ленточных библиотек и не применима к дискам и облаку.
• Физическое освобождение места идёт через micro pruning или macro pruning.