Домен даних: Часто задавані питання про компресію

Summary: Ця стаття відповідає на найпоширеніші питання щодо стиснення. Домени даних незалежні від типу даних. Data Domain використовує алгоритми стиснення, які зберігають лише унікальні дані — дубльовані шаблони або кілька резервних копій зберігаються лише один раз. ...

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.
Check out other resources

Instructions

Зміст

|
 
Типові частоти стиснення — 20:1 протягом багатьох тижнів щоденних і поетапних резервних копій. Тип даних впливає на коефіцієнт стиснення — стиснуті файли зображень, бази даних і стиснуті архіви (наприклад, .zip файли) погано стискаються.
 

Чи використовують інкрементальні та повні резервні копії однаковий простір на диску?

Ідеально, якщо це буде правдою. На практиці повна резервна копія займає трохи більше місця, ніж інкрементальна, з наступних причин. Ці причини також пояснюють, чому повна резервна копія без змін даних все одно займає значну кількість місця.
  • Метадані займають близько 0,5% логічного розміру резервної копії. Припустимо, що:
    • Логічний розмір повного — 100 ГБ
    • Логічний розмір інкрементального — 2 ГБ
    • Інкрементальне стиснення стискається до 1 GB
    • ... тоді повний об'єм займає щонайменше 1,5 ГБ
  • Двигун стиснення DD переписує деякі дубліковані сегменти даних для підвищення продуктивності. Чим гірша локальність даних змін, тим більше дублікатів записується. Дублікати пізніше відновлюються за допомогою збору сміття файлової системи (GC). В деяких випадках близько 2% логічного розміру переписується як дублікат. За такого рівня дублікатів повний файл може зайняти 1 ГБ (стиснений) + 0,5 ГБ (метадані) +2 ГБ (дублікати) = 3,5 ГБ. Кількість записаних дублікатів можна контролювати за допомогою системного параметра, але зазвичай ми не налаштовуємо цей параметр у полі.
  • Сегментація даних може трохи відрізнятися від резервної копії до резервної копії залежно від порядку, у якому клієнт NFS надсилає дані. Цей порядок не є детермінованим. Загалом, алгоритм сегментації допускає зсуви та перестановку. Однак це також створює деякі «примусові» сегменти, які схильні до зміщення та перепорядку. Зазвичай близько 0,2% сегментів є примусовими, тож можна очікувати значно більшого використання простору.
 

Чому...filesys show space' і 'filesys show compressionПоказувати різні номери?

  • 'filesys show space' надає коефіцієнт стиснення на основі логічного розміру збережених даних і простору на диску, використаного на момент виконання команди.
  • 'filesys show compression' надає коефіцієнт стиснення на основі того, як кожен файл був стиснений на момент його створення.
  • 'filesys show compression' використовується переважно для підтримки та налагодження. У присутності файлу видаляється, 'filesys show compression' переоцінює ступінь стиснення.
 
Наприклад, припустимо:
  • Перша повна резервна копія отримує 2x стиснення
  • Наступна повна резервна копія без змін даних отримує 200-кратне стиснення
  • Перша повна резервна копія видаляється
Вихід 'filesys show space' показав би ступінь стиснення 2x, тоді як 'filesys show compression' показав би коефіцієнт стиснення 200x, оскільки єдиний файл, який зараз існує, мав коефіцієнт стиснення 200x при створенні.
 
У наведеному вище прикладі, після другого резервного копія, 'filesys show space' покаже кумулятивне співвідношення приблизно 4x. Кумулятивне співвідношення покращиться асимптотично до 200x, якщо продовжувати робити більше резервних копій без видалення.
 
Є й інші незначні відмінності. The 'filesys show compression' наказ:
  • Не враховує витрати на рівні контейнера, що додатково переоцінює ступінь стиснення
  • Не враховує усунення дублікатів шляхом глобального стиснення, тобто недооцінює ступінь стиснення
  • Може надавати інформацію для кожного файлу або каталогу, тоді як 'filesys show space' обмежується всією системою
  • Забезпечує розподіл між глобальним і локальним стисненням, тоді як 'filesys show space' не має
 

Чому 'filesys show compression last 24 hours' не відповідає очікуванням для VTL?

Для VTL виведення команд, таких як 'filesys show compression last 24 hours' часто не відповідає очікуванням на основі інших джерел, таких як 'system show performance'.
 
Проблема виникає через особливість у 'filesys show compression'. Загалом, він показує кумулятивні характеристики у вибраних файлах. Кваліфікатор «останні 24 години» вибирає файли, які були оновлені протягом останніх 24 годин. Статистика все ще накопичується з моменту створення файлу або останнього скорочення до нуля. Отже, якщо файл було додано протягом останніх 24 годин, 'filesys show compression last 24 hours' показує свої сумарні статистики до останніх 24 годин.
 
Резервні файли в не-VTL середовищах записуються лише один раз, тому розбіжності між оновленими та створеними файлами майже немає. За допомогою VTL резервні копії можуть додаватися до існуючих файлів стрічки. Наприклад, уявіть стрічку на 100 ГБ, заповнену до 50 ГБ. Якщо до цієї стрічки за останні 24 години додали 10 ГБ даних, 'filesys show compression last 24 hours' показував «Оригінальні байти» файлу, записані на 60 ГБ.
 

Як розраховується кумулятивний коефіцієнт стиснення?

Окремі коефіцієнти стиснення не складаються лінійно.
 
Припустимо, що стиснення на першій повній резервній копії — 2x, а на другій — 20x. Кумулятивне стиснення — це не (2 + 20) / 2 = 11x, але 2 / (1/2 + 1/20) = 3.64x.
 
Загалом, нижчі ступені стиснення мають більший вплив, ніж вищі, на кумулятивний ступінь стиснення.
 
Припустимо, що ith Резервне копіювання має логічний розмір si та ступінь стиснення ci. Далі — кумулятивний коефіцієнт стиснення для k Резервні копії можна обчислити наступним чином: 
C = (total logical size)/(total space used)
total logical size = s1 + s2 + .. + sk
total space used = s1/c1 + s2/c2 + ... + sk/ck
 
Часто логічні розміри приблизно однакові. У такому випадку наведене вище обчислення спрощується до наступного вигляду:
C = k / (1/c1 + 1/c2 + ... + 1/ck)
 
Наприклад, якщо:
  • Перша повна резервна копія отримує 3x стиснення
  • Кожен наступний повний отримує 30-кратне стиснення
  • Термін утримання — 30 днів

користувач бачить кумулятивне стиснення 30 / (1/3 + 29/30), або 23x.

 

Як працює стиснення домену даних?

На це питання детально розглянуто в окремій статті: Розуміння стиснення домену даних
 

Чи підтримує Data Domain мультиплексування?

Мультиплексовані дані з додатку резервного копіювання призводять до дуже поганої глобальної дедуплікації. Для отримання додаткової інформації дивіться цю статтю: Домен даних: Мультиплексування в програмному забезпеченні резервного копіювання
 

Чому з реплікацією каталогів 1-до-1 краще глобальне стиснення?

Зазвичай це пов'язано з варіаціями рівня дублікатів сегментів, записаних у системі:
  • Дані, що зберігаються на джерелі, були дедупліковані один раз — порівняно з попередніми даними, збереженими на джерелі.
  • Дані, передані по дроту, були дедупліковані один раз — порівняно з даними, збереженими в реплікі.
  • Дані, збережені в реплікі, були дедупліковані двічі: один раз при передачі даних по дроту, і вдруге, коли отримані дані записані на репліку.
Оскільки процес дедуплікації залишає деякі дублікати, дані, які були дедупліковані кілька разів, мають менше дублікатів. Дані, що зберігаються на джерелі і передаються по дроту, дедуплікуються один раз, тобто вони приблизно однакові, якщо дані, збережені на джерелі, і репліка схожі. Дані, що зберігаються на реплікі, дедуплікуються двічі, тому їх краще стискати.
 
Очищення файлової системи видаляє більшість дублікатів. Отже, після очищення джерела та репліки обсяг збережених даних має бути приблизно однаковим.
 

Яка зміна стиснення при використанні lz, gzfast, та gz Налаштування локального стиснення?

Використовуйте наступну команду, щоб змінити локальний алгоритм стиснення, який використовується в домені даних:
filesys option set compression {none | lz | gzfast | gz}
 
Примітка. Файлову систему потрібно вимкнути перед зміною локального типу стиснення. Після встановлення опції стиснення можна одразу перезапустити.
 
Загалом, порядок стиснення такий:
lz < gzfast < gz
 
Тип Очікувана компенсація. Навантаження на процесор
жодних 1x 0x
lz 2x 1x
gzfast 2,5x 2x
gz 3x 5 разів
 
Основна різниця така:
  • lz to gzfast дає ~15% кращу компресію і споживає 2x процесор
  • lz to gz дає ~30% кращу компресію і споживає 5x процесор
  • gzfast to gz дає ~10-15% кращу компресію
Зверніть увагу, що зміна локального стиснення спочатку впливає на нові дані, записані в домен даних після внесення зміни. Старі дані зберігають свій попередній формат стиснення до наступного циклу очищення. Наступний цикл очищення копіює всі старі дані у новий формат стиснення. Через це очищення триває набагато довше і займає більше процесора.
 
Якщо система вже має низький обсяг процесора, особливо якщо резервне копіювання і реплікація виконуються одночасно, це може уповільнити роботу резервних копій. Клієнт може спеціально запланувати час для цієї конверсії.

Additional Information

Джерела знань:

Affected Products

Data Domain

Products

Data Domain
Article Properties
Article Number: 000022100
Article Type: How To
Last Modified: 24 Apr 2026
Version:  12
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.