Data Domain. Понимание сжатия Data Domain

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

В этой статье рассматриваются некоторые термины, компромиссы и меры, позволяющие лучше объяснить используемый тип сжатия, а также другие аспекты сжатия в среде Data Domain.

ЗАТРОНУТЫЕ РЕШЕНИЯ: Все модели Data Domain

Введение.

Последнее обновление: Январь 2024

• Сжатие — это технология сокращения объема данных, целью которой является хранение набора данных, использующего меньше физического пространства.
• В системах Data Domain (DDOS) дедупликация и локальное сжатие используются для сжатия пользовательских данных. Дедупликация используется для выявления избыточных сегментов данных и хранения только уникальных сегментов данных.
• Локальное сжатие дополнительно сжимает уникальные сегменты данных с помощью определенных алгоритмов сжатия, таких как: lz, gzfast, gzи так далее.
• Общее сжатие пользовательских данных в DDOS — это совместная работа дедупликации и локального сжатия. DDOS использует «коэффициент сжатия» для измерения эффективности сжатия данных.
• Как правило, это отношение общего размера пользовательских данных к общему объему сжатых данных или объему используемого физического пространства.
• Файловая система Data Domain представляет собой файловую систему дедупликации со структурой журналов.
• Файловая система, структурированная по журналу, только добавляет данные в систему, и просто удаление не может освободить физическое пространство.
• Такие файловые системы полагаются на чистку памяти для высвобождения неиспользуемого пространства.
• Характеристики файловой системы со структурированным журналом и технология дедупликации, объединенные вместе, затрудняют четкое понимание всех аспектов сжатия в DDOS.

Для сжатия существует множество аспектов, которые можно измерить.

В этой статье рассматриваются пошаговые инструкции, которые помогут понять сжатие DDOS.

• Сначала объясняется общий эффект сжатия системы, который говорит нам о реалистичном сжатии, достигаемом в системе Data Domain, объеме пользовательских данных, объеме потребляемого физического пространства и их соотношении.
• В данной статье этот коэффициент называется «эффективным коэффициентом сжатия системы».
• DDOS выполняет дедупликацию на лету и отслеживает статистику исходных сегментов пользовательских данных, уникальных сегментов данных после дедупликации и влияние локального сжатия на уникальные сегменты данных.
• Эти статистические данные о сжатии на лету используются для измерения эффекта сжатия на лету. Для каждой записи можно измерять статистику сжатия на лету. Также DDOS отслеживает статистику на разных уровнях: Файлы MTreesи всей системы.

Мы не гарантируем, что все содержимое будет точным для будущих выпусков.

В выпусках до версии 5.0 во всей системе имеется только один mtree и термин mtree явно не вызывается.

Сжатие. Общий эффект от системы:

Общий эффект сжатия в масштабах системы измеряется эффективным коэффициентом сжатия, который представляет собой отношение объема пользовательских данных к размеру используемого физического пространства. Об этом сообщает «filesys show compression" (FSC) CLI (соответствующая информация также доступна в пользовательском интерфейсе). Пример выходных данных FSC показан ниже:

# filesys show compression

From: 2023-12-31 03:00 To: 2024-01-07 03:00

Active Tier:
                   Pre-Comp   Post-Comp   Global-Comp   Local-Comp      Total-Comp
                      (GiB)       (GiB)        Factor       Factor          Factor
                                                                     (Reduction %)
----------------   --------   ---------   -----------   ----------   -------------
Currently Used:*     6439.6       113.4             -            -    56.8x (98.2)
Written:
  Last 7 days      135421.3      1782.0         35.1x         2.2x    76.0x (98.7)
  Last 24 hrs         532.5         1.5        334.3x         1.1x   356.5x (99.7)
----------------   --------   ---------   -----------   ----------   -------------
 * Does not include the effects of pre-comp file deletes/truncates
   since the last cleaning on 2024/01/05 11:34:13.

• •  
  • Эффективный коэффициент сжатия системы указывается в строке 1 раздела результатов выходных данных интерфейса командной строки. Строка выделена выше.
  • Общий размер пользовательских данных помечен как «Pre-Comp».
  • Общее потребленное физическое пространство (как по данным, так и по метаданным) помечается как Post-Comp.
  • Номер «Pre-Comp» и номер «Post-Comp» считываются во время выполнения. FSC неявно синхронизирует всю систему, а затем запрашивает два числа.
    • Эти два числа измеряются так же, как и "filesys show space" команда.
    • Эффективный коэффициент сжатия системы = до компоновки/после компрессии

Существует ряд операций, которые могут повлиять на эффективный коэффициент сжатия системы:

• Быстрое копирование
  • Когда fastcopy выполняется из файла в активном пространстве имен (не в снимке), это идеальная дедупликация, так как для целевого файла не требуется дополнительное физическое пространство. Эффект fastcopy заключается в том, что размер пользовательских данных увеличивается без использования дополнительного физического пространства. Это увеличивает эффективную степень сжатия системы. Когда многие fastcopies эффективная степень сжатия системы может стать искусственно завышенной.
• Виртуальная синтетика
  • Виртуальные синтетические резервные копии, как правило, показывают высокий эффективный коэффициент сжатия системы. Это связано с тем, что виртуальные синтетические устройства создают логические полные резервные копии, но передают в системы Data Domain только измененные или новые данные. Влияние виртуальной синтетики на эффективный коэффициент сжатия системы чем-то похоже на эффект fastcopy.
• Перезаписывает
  • Перезаписи занимают больше физического пространства, но не увеличивают логический размер набора данных, поэтому перезаписи снижают эффективный коэффициент сжатия системы
• Хранение разреженных файлов
  • Разреженные файлы содержат большие «пробелы», которые учитываются в логическом размере, но не занимают физическое пространство из-за сжатия. В результате эффективное сжатие системы может казаться более высоким.
• Хранение небольших файлов
  • DDOS добавляет дополнительные затраты около 1 Кбайт на каждый файл для определенных внутренних метаданных. Если в системе хранится значительное количество небольших файлов (размером менее 1 Кбайт или однозначными килобайтами), издержки метаданных снижают эффективный коэффициент сжатия.
• Хранение предварительно сжатых или зашифрованных файлов
  • Сжатие и шифрование могут повысить вероятность изменения данных и уменьшить вероятность дедупликации. Такие файлы, как правило, плохо дедуплицируются и снижают эффективный коэффициент сжатия системы.
• Удаляет
  • Удаления уменьшают логический размер системы, но система не получает соответствующее неиспользуемое пространство до запуска чистки памяти. При удалении многих файлов коэффициент сжатия снижается до тех пор, пока не будет запущена чистка мусора (GC).
• Сборка мусора (GC) или очистка
  • GC освобождает пространство, занимаемое сегментами данных, которые больше не видны ни одному файлу. Если большое количество файлов было удалено недавно, GC может увеличить коэффициент сжатия системы за счет сокращения занимаемого пространства.
• Активное создание моментальных снимков
  • Когда создается моментальный снимок Mtree логический размер набора данных не изменяется. Однако все сегменты данных, на которые ссылается моментальный снимок, должны быть заблокированы, даже если все файлы, захваченные моментальным снимком, удаляются после создания моментального снимка. GC не может освободить пространство, которое по-прежнему требуется для снимков, так как при большом количестве снимков эффективный коэффициент сжатия системы может оказаться низким. Однако моментальные снимки полезны для восстановления после сбоев. Не стесняйтесь делать снимки или настраивать надлежащие расписания создания снимков, когда это необходимо.

Сжатие. Встроенная статистика:

DDOS выполняет дедупликацию на лету по мере записи данных в систему. Он отслеживает влияние дедупликации на лету и локального сжатия для каждой операции записи и накапливает статистику на уровне файла. Статистика сжатия на лету для каждого файла дополнительно агрегируется на mtree и на системном уровне. Сжатие измеряется на основе трех чисел во встроенной статистике:

• Длина каждой записи: raw_bytes 
• The length of all unique segments: pre_lc_size
• Длина локально сжатых уникальных сегментов: post_lc_size

• • Глобальное сжатие (g_comp)
    • Равно (raw_bytes/pre_lc_size) и отражает коэффициент дедупликации
  • Локальное сжатие (l_comp)
    • Равно (pre_lc_size/post_lc_size) и отражает эффект от локального алгоритма сжатия

Накопленная статистика сжатия на лету является частью метаданных файла в DDOS и хранится в файле inode. DDOS предоставляет инструменты для проверки сжатия на всех трех уровнях; Файл MTreeи в масштабах всей системы. Они подробно описаны в следующих разделах.

Сжатие файлов

• • Сжатие файла можно проверить с помощью кнопки "filesys show compression <path>" CLI, которая сообщает накопленную статистику сжатия, хранящуюся в файле inode.
  • Если указан каталог, то статистика сжатия всех файлов в этом каталоге суммируется и выводится в отчет.
  • В выходных данных интерфейса командной строки raw_bytes помечено как "Original Bytes", pre_lc_size помечено как «Глобальное сжатие», post_lc_bytes помечен как «Локальное сжатие». Остальные накладные расходы указываются как «метаданные». Два примера взяты из производственного DD:

Пример 1 Встроенная статистика сжатия файла

filesys show compression /data/col1/main/dir1/file_1

Total files: 1;  bytes/storage_used: 7.1
        Logical Bytes:       53,687,091,200
       Original Bytes:       11,463,643,380
  Globally Compressed:        4,373,117,751
   Locally Compressed:        1,604,726,416
            Meta-data:           18,118,232

Пример 2 Статистика сжатия всех файлов в каталоге, включая все подкаталоги.

filesys show compression /data/col1/main/dir1 

Total files: 13;  bytes/storage_used: 7.1
        Logical Bytes:       53,693,219,809
       Original Bytes:       11,501,978,884
  Globally Compressed:        4,387,212,404
   Locally Compressed:        1,608,444,046
            Meta-data:           18,241,880

• • • Система сообщает общий коэффициент сжатия на лету в приведенном выше выводе интерфейса командной строки как «bytes/storage_used».
    • Тем не менее, следует проявлять осторожность при интерпретации вышеуказанной информации, поскольку она может ввести в заблуждение по различным причинам.
    • Одна из причин заключается в том, что pre_lc_size и post_lc_size записываются во время обработки операций с данными.
    • При удалении файла, в который изначально были добавлены эти сегменты, количество уникальных сегментов данных в оставшемся файле должно быть увеличено.

В качестве примера предположим, что файл образца файла резервируется в Data Domain, и при первом резервном копировании информация о сжатии файла будет следующей pre_lc_size= 10 ГиБ, post_lc_size= 5 Гиб.

• • • Затем предположим, что данные этого файла уникальны и не передаются другим файлам.
    • При втором резервном копировании файла предположим, что файл получает идеальную дедупликацию, такую, что оба pre_lc_size и post_lc_size должно быть равно нулю, так как все сегменты файла уже существовали в системе.
    • При удалении первой резервной копии вторая резервная копия файла становится единственным файлом, который ссылается на сегменты данных размером 5 ГиБ.
    • В этом случае, в идеале, pre_lc_size и post_lc_size файла во второй резервной копии должен быть обновлен с нуля до 10 ГиБ и 5 ГиБ соответственно.
    • Однако невозможно определить, для каких файлов это должно быть сделано, поэтому встроенная статистика сжатия существующих файлов остается неизменной.

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

Сжатие MTree:

• • Сжатие конкретного mtree можно проверить с помощью "mtree show compression" (MSC) CLI-команда.
  • Абсолютные значения встроенной статистики сжатия накапливаются за все время существования MTree.
  • Учитывая, что время жизни MTree могут длиться много лет, эти значения со временем становятся все менее и менее информативными.
  • Для решения этой проблемы используется величина изменения (разницы) встроенной статистики сжатия, при этом сжатие сообщается только за определенные интервалы времени.
  • Основной подход заключается в том, что MTree Встроенная статистика сжатия периодически записывается в журнал.
  • Когда клиент запрашивает сжатие MTree с помощью команды MSC log, журнал используется для вычисления разницы чисел для отчетов о сжатии.
  • По умолчанию MSC Выводит сжатие за последние 7 дней и последние 24 часа, хотя можно указать любой интересующий вас период времени.

Чтобы продемонстрировать это, предположим, что следующий журнал для MTree О.

3:00AM, raw_bytes=11000GB, pre_lc_size=100GB, post_lc_size=50GB 4:00AM, raw_bytes=12000GB, pre_lc_size=200GB, post_lc_size=100GB

Тогда сжатие MTree A для этого часа:

g_comp = (12000-11000)/(200-100) = 10x
l_comp = (200-100)/(100-50) = 2x
overall compression ratio = (12000-11000)/(100-50) = 20x

Приведенный выше расчет коэффициента сжатия ничего не делает с размером набора данных. Например, приведенное выше mtree может содержать только 500 Гбайт логических данных.

• • MSC поддерживает параметры "daily" и "daily-detailed", а также "filesys show compression" команда.
  • Если указано значение "daily", команда сообщает о ежедневном сжатии в календарном режиме.
  • Он использует дневные дельты raw_bytes и post_lc_size , чтобы вычислить суточную степень сжатия.
  • Если указан параметр "daily-detailed", команда отображает все три разницы (из raw_bytes, pre_lc_sizeи post_lc_size, соответственно) за каждый день. Он также вычисляет g_comp и l_comp вместе с общим коэффициентом сжатия.

Пример выходных данных этих систем приведен в Приложении ниже.

Сжатие системы:

• • После того, как сжатие сообщается на MTrees понятно, что эту концепцию легко распространить на всю систему.
  • Сбор статистики и создание отчетов по сжатию в масштабе системы точно такие же, как и в MTrees.
  • Единственное различие заключается в области применения, так как человек находится в конкретном MTree, в то время как один находится над всей системой.
  • Результаты можно проверить с помощью кнопки "filesys show compression" команда.
  • Пример можно найти в разделе 2.
  • Сжатие системы за последние 7 дней и за последние 24 часа отображается в последних двух строках раздела результатов на странице FSC .

Уровень облака.

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

Дедупликации:

Последняя тема, которую следует осветить, — это некоторые характеристики дедупликации, которая во многих статьях Data Domain называется «глобальным сжатием».

Несмотря на то, что он содержит слово «сжатие», оно полностью отличается от традиционной концепции сжатия, которая также предоставляется в DDOS под названием «локальное сжатие».

• Локальное сжатие уменьшает размер фрагмента данных с помощью определенного алгоритма (некоторые типы данных не поддаются сжатию, и применение алгоритмов сжатия к ним может немного увеличить размер данных).
• Обычно, после того, как алгоритм определен, данные являются единственным фактором коэффициента сжатия.
• Однако дедупликация отличается – это не локальное понятие, а «глобальное».
• Входящий сегмент данных дедуплицируется относительно всех существующих сегментов данных в дедуплицированном домене, который включает все данные в необлачных системах Data Domain.
• Сам сегмент данных в процедуре дедупликации значения не имеет.
• На практике высокий коэффициент дедупликации редко наблюдается при первоначальном резервном копировании набора данных. При первоначальном резервном копировании часто значительное сокращение объема данных происходит за счет локального сжатия.
• Когда последующие резервные копии попадают в Data Domain, дедупликация демонстрирует свои преимущества и становится доминирующим фактором для сжатия.
• Эффективность дедупликации зависит от того факта, что скорость изменения набора данных от резервной копии к резервной копии невелика. По этой причине наборы данных с высокой частотой изменений не могут быть хорошо дедуплицированы.
• Когда приложение резервного копирования с высокой частотой вставляет в образы резервных копий собственные блоки метаданных (называемые в Data Domain маркерами), коэффициент дедупликации также может быть недостаточным. Наши методы работы с маркерами могут помочь иногда, но не всегда.

Учитывая эти наблюдения, чего ожидать:

• При начальном резервном копировании может достигаться только небольшой эффективный коэффициент сжатия системы, часто 2x или 3x. Дедупликация обычно имеет мало возможностей проявить себя при первоначальном резервном копировании.
• Коэффициент глобального сжатия инкрементного резервного копирования ниже, чем коэффициент сжатия соответствующего полного резервного копирования. Это связано с тем, что инкрементное резервное копирование содержит только измененные или новые файлы по сравнению с только что выполненным прошлым резервным копированием. Коэффициент глобального сжатия зависит от процента новых данных в инкрементном резервном копировании.
• Коэффициент дедупликации полной резервной копии (неначальный) также может быть низким в некоторых сценариях. Некоторые часто наблюдаемые сценарии включают:
  • Высокая частота изменений в данных, для которых выполняется резервное копирование.
  • В наборе данных преобладают файлы небольшого размера (менее 5 МиБ)
  • Приложения резервного копирования, добавляющие множество близко расположенных маркеров
  • Инкрементное резервное копирование баз данных или резервное копирование с использованием небольшого размера блока
  • Если при полном резервном копировании с низкой частотой изменения данных наблюдается низкий коэффициент сжатия, проверьте, применим ли один из вышеперечисленных сценариев или необходим дальнейший анализ.
• Сжатие более позднего образа резервной копии не всегда лучше, чем исходного. Последовательные образы резервных копий могут показывать высокий коэффициент дедупликации, поскольку исходное и более ранние образы резервного копирования уже добавили большую часть данных в систему. Когда все более ранние образы резервных копий удаляются, коэффициент глобального и локального сжатия самого раннего существующего образа резервной копии может оставаться высоким, но это означает только то, что он получил хорошую дедупликацию при добавлении в систему, и ничего больше. При удалении файла с высоким коэффициентом глобального и локального сжатия, который является последним резервным образом резервной копии определенного набора данных, может освободиться больше места, чем получено на основе коэффициента сжатия.
• Нельзя сравнивать коэффициенты сжатия одного и того же набора данных в разных системах, независимо от того, каким образом набор данных был добавлен в эти системы. Это связано с тем, что каждая система является независимым доменом дедупликации. Нет никаких ожиданий, что два разных DD получат одинаковые или даже обязательно одинаковые коэффициенты сжатия, даже если их наборы данных одинаковы.

Сводка.

• Измерить сжатие сложно в дедуплицированных файловых системах, но еще сложнее в дедуплицированных файловых системах со структурированными журналами.
• Необходимо понимать, как работает дедупликация и как отслеживается статистика сжатия.
• Коэффициенты сжатия — это полезная информация для понимания поведения конкретной системы.
• Эффективная степень сжатия системы является наиболее важным, надежным и информативным показателем.
• Статистика сжатия на лету также может быть полезна, но в некоторых случаях она может быть не более чем эвристикой.

Приложение:

Пример выходных данных "mtree show compression" .

• Предположим, что имеется MTree содержит 254 792,4 ГиБ данных. Он получил 4379,3 ГиБ новых данных за последние 7 дней и 78,4 ГиБ за последние 24 часа (можно указать другие временные интервалы).
• Параметр «daily» сообщает статистику сжатия на лету за последние 33 дня.
• Если указан параметр «daily-detailed», общие коэффициенты сжатия детализируются путем разделения их на глобальные и локальные коэффициенты сжатия.

Переменная mtree Вывод списка:

mtree list /data/col1/main 

Name              Pre-Comp (GiB)   Status
---------------   --------------   ------
/data/col1/main         254792.4   RW
---------------   --------------   ------
 D    : Deleted
 Q    : Quota Defined
 RO   : Read Only
 RW   : Read Write
 RD   : Replication Destination
 IRH  : Retention-Lock Indefinite Retention Hold Enabled
 ARL  : Automatic-Retention-Lock Enabled
 RLGE : Retention-Lock Governance Enabled
 RLGD : Retention-Lock Governance Disabled
 RLCE : Retention-Lock Compliance Enabled
 M    : Mobile
 m    : Migratable

MSC (без вариантов):

mtree show compression /data/col1/main

From: 2023-09-07 12:00 To: 2023-09-14 12:00

                Pre-Comp   Post-Comp   Global-Comp   Local-Comp      Total-Comp
                   (GiB)       (GiB)        Factor       Factor          Factor
                                                                  (Reduction %)
-------------   --------   ---------   -----------   ----------   -------------
Written:
  Last 7 days     4379.3       883.2          3.4x         1.5x     5.0x (79.8)
  Last 24 hrs      784.6       162.1          3.3x         1.4x     4.8x (79.3)
-------------   --------   ---------   -----------   ----------   -------------

С опцией "ежедневно":

mtree show compression /data/col1/main daily

From: 2023-08-12 12:00 To: 2023-09-14 12:00

  Sun     Mon     Tue     Wed     Thu     Fri     Sat   Weekly
-----   -----   -----   -----   -----   -----   -----   ------   -----------------
 -13-    -14-    -15-    -16-    -17-    -18-    -19-            Date
432.0   405.9   284.1   438.8   347.0   272.7   331.4   2511.8   Pre-Comp
 85.5    66.2    45.3    81.9    61.4    57.4    66.3    464.1   Post-Comp
 5.0x    6.1x    6.3x    5.4x    5.7x    4.7x    5.0x     5.4x   Total-Comp Factor

 -20-    -21-    -22-    -23-    -24-    -25-    -26-
478.0   387.8   450.2   533.1   386.0   258.4   393.6   2887.1
100.6    81.5   100.8   119.0    84.0    40.6    75.3    601.8
 4.8x    4.8x    4.5x    4.5x    4.6x    6.4x    5.2x     4.8x

 -27-    -28-    -29-    -30-    -31-     -1-     -2-
 27.6     1.0     0.4   470.7   467.3   517.7   641.9   2126.7
  4.9     0.2     0.1    83.9    92.3    89.8   140.1    411.2
 5.6x    5.6x    4.3x    5.6x    5.1x    5.8x    4.6x     5.2x

  -3-     -4-     -5-     -6-     -7-     -8-     -9-
539.6   495.0   652.8   658.7   537.1   398.7   305.5   3587.3 
110.8   108.0   139.4   137.0   111.5    78.3    48.3    733.3 
 4.9x    4.6x    4.7x    4.8x    4.8x    5.1x    6.3x     4.9x 

 -10-    -11-    -12-    -13-    -14-   
660.2   738.3   787.2   672.9   796.9                   3655.5
143.9   152.5   167.6   126.9   163.3                    754.2 
 4.6x    4.8x    4.7x    5.3x    4.9x                     4.8x 
-----   -----   -----   -----   -----   -----   -----   ------   -----------------
                 Pre-Comp   Post-Comp   Global-Comp   Local-Comp      Total-Comp
                    (GiB)       (GiB)        Factor       Factor          Factor
                                                                   (Reduction %)
--------------   --------   ---------   -----------   ----------   -------------
Written:
  Last 33 days    14768.3      2964.5          3.4x         1.5x     5.0x (79.9)
  Last 24 hrs       784.6       162.1          3.3x         1.4x     4.8x (79.3)
--------------   --------   ---------   -----------   ----------   -------------

Key:
       Pre-Comp = Data written before compression
       Post-Comp = Storage used after compression
       Global-Comp Factor = Pre-Comp / (Size after de-dupe)
       Local-Comp Factor = (Size after de-dupe) / Post-Comp
       Total-Comp Factor = Pre-Comp / Post-Comp
       Reduction % = ((Pre-Comp - Post-Comp) / Pre-Comp) * 100

С опцией "ежедневная детализация":

mtree show compression /data/col1/main daily-detailed 

From: 2023-08-12 12:00 To: 2023-09-14 12:00

  Sun     Mon     Tue     Wed     Thu    Fri     Sat    Weekly
-----   -----   -----   -----   -----   -----   -----   ------   -----------------
 -13-    -14-    -15-    -16-    -17-    -18-    -19-            Date
432.0   405.9   284.1   438.8   347.0   272.7   331.4   2511.8   Pre-Comp
 85.5    66.2    45.3    81.9    61.4    57.4    66.3    464.1   Post-Comp
 3.5x    4.1x    4.3x    3.6x    3.8x    3.3x    3.4x     3.7x   Global-Comp Factor
 1.4x    1.5x    1.5x    1.5x    1.5x    1.4x    1.5x     1.5x   Local-Comp Factor
 5.0x    6.1x    6.3x    5.4x    5.7x    4.7x    5.0x     5.4x   Total-Comp Factor
 80.2    83.7    84.1    81.3    82.3    78.9    80.0     81.5   Reduction %

 -20-    -21-    -22-    -23-    -24-    -25-    -26-
478.0   387.8   450.2   533.1   386.0   258.4   393.6   2887.1
100.6    81.5   100.8   119.0    84.0    40.6    75.3    601.8
 3.3x    3.3x    3.0x    3.0x    3.3x    4.1x    3.6x     3.3x 
 1.4x    1.5x    1.5x    1.5x    1.4x    1.5x    1.4x     1.5x 
 4.8x    4.8x    4.5x    4.5x    4.6x    6.4x    5.2x     4.8x
 79.0    79.0    77.6    77.7    78.2    84.3    80.9     79.2

 -27-    -28-    -29-    -30-    -31-    -1-     -2-
 27.6     1.0     0.4   470.7   467.3   517.7   641.9   2126.7
  4.9     0.2     0.1    83.9    92.3    89.8   140.1    411.2
 4.4x    3.7x    2.6x    3.8x    3.5x    3.9x    3.2x     3.5x 
 1.3x    1.5x    1.6x    1.5x    1.4x    1.5x    1.5x     1.5x
 5.6x    5.6x    4.3x    5.6x    5.1x    5.8x    4.6x     5.2x
 82.1    82.2    76.8    82.2    80.3    82.7    78.2     80.7

  -3-     -4-     -5-     -6-     -7-    -8-     -9-
539.6   495.0   652.8   658.7   537.1   398.7   305.5   3587.3 
110.8   108.0   139.4   137.0   111.5    78.3    48.3    733.3 
 3.4x    3.1x    3.2x    3.4x    3.3x    3.4x    4.1x     3.3x 
 1.4x    1.5x    1.5x    1.4x    1.4x    1.5x    1.6x     1.5x
 4.9x    4.6x    4.7x    4.8x    4.8x    5.1x    6.3x     4.9x 
 79.5    78.2    78.6    79.2    79.2    80.4    84.2     79.6

 -10-    -11-    -12-    -13-    -14-   
660.2   738.3   787.2   672.9   796.9                   3655.5
143.9   152.5   167.6   126.9   163.3                    754.2
 3.1x    3.4x    3.2x    3.7x    3.4x                      .3x 
 1.5x    1.4x    1.5x    1.4x    1.5x                     1.5x
 4.6x    4.8x    4.7x    5.3x    4.9x                     4.8x
 78.2    79.3    78.7    81.1    79.5                     79.4
-----   -----   -----   -----   -----   -----   -----   ------   -----------------
                 Pre-Comp   Post-Comp   Global-Comp   Local-Comp      Total-Comp
                    (GiB)       (GiB)        Factor       Factor          Factor
                                                                   (Reduction %)
--------------   --------   ---------   -----------   ----------   -------------
Written:
  Last 33 days    14768.3      2964.5          3.4x         1.5x     5.0x (79.9)
  Last 24 hrs       784.6       162.1          3.3x         1.4x     4.8x (79.3)
--------------   --------   ---------   -----------   ----------   -------------

Key:
       Pre-Comp = Data written before compression
       Post-Comp = Storage used after compression
       Global-Comp Factor = Pre-Comp / (Size after de-dupe)
       Local-Comp Factor = (Size after de-dupe) / Post-Comp
       Total-Comp Factor = Pre-Comp / Post-Comp
       Reduction % = ((Pre-Comp - Post-Comp) / Pre-Comp) * 100