Что такое дедупликация данных

Обзор дедупликации данных

область применения: Windows server 2022, Windows server 2019, Windows Server 2016, Azure Stack хЦи, версия 20H2

Что такое дедупликация данных

Дедупликация данных, часто называемая дедупликацией, — это функция, которая помогает снизить влияние избыточных данных на затраты на хранение. Если дедупликация данных включена, она оптимизирует свободное место в томе за счет проверки данных тома на наличие дублирующихся частей. Дублирующиеся части набора данных тома сохраняются один раз и (при необходимости) сжимаются для дополнительной экономии. Дедупликация оптимизирует избыточные данные, не нарушая достоверность или целостность данных. Дополнительные сведения о работе дедупликации данных см. в разделе Как работает дедупликация данных? на странице Understanding Data Deduplication (Понимание процесса дедупликации данных).

KB4025334 содержит сведение исправлений для дедупликации данных, включая важные исправления надежности, и настоятельно рекомендуется устанавливать его при использовании дедупликации данных с Windows Server 2016 и Windows Server 2019.

Преимущества дедупликации данных

Дедупликация данных помогает администраторам хранилища снизить затраты, связанные с дублирующимися данными. Большие наборы данных часто имеют массу дублирования, что увеличивает затраты на хранение данных. Пример.

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

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

Источник

Дедупликация данных

Дата публикации: 3 апреля 2018 г.

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

ДЕДУПЛИКАЦИЯ ДАННЫХ ЭТО

СПОСОБЫ ДЕДУПЛИКАЦИИ

Дедупликация на уровне блоков является самым распространенным способом дедупликации, который анализирует фрагмент данных (файл) и сохраняет только уникальные повторения каждого блока. Блок это логическая единица, поэтому он может иметь разный размер (длину). Все фрагменты данных обрабатываются с использованием хеш-алгоритма, такого как MD5 или SHA-1. Этот алгоритм создает и хранит в базе дедупликации идентификатор (сигнатуру) для каждого уникального блока.

Таким образом, если в течении жизненного цикла, файл изменился, в хранилище попадают только его изменённые блоки, а не весь файл, даже если изменилось только несколько байт.

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

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

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

ДЕДУПЛИКАЦИЯ и РЕЗЕРВНОЕ КОПИРОВАНИЕ

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

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

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

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

МИНУСЫ ДЕДУПЛИКАЦИИ

Основной проблемой дедупликации является конфликт данных, который может возникнуть, если два различных блока генерируют один и тот же хэш-ключ. В этом случае возникает повреждение базы данных, что влечет сбой при восстановлении резервной копии. Чем больше база данных и выше частота изменений, тем вероятней возникновение конфликтных ситуаций. Решением данной проблемы может быть увеличение хэш пространства, так как, чем больше хэш ключей, тем меньше вероятность конфликта. На данный момент используют 160-битный ключ, генерируемый алгоритмом SHA-1. Это 2 160 =1.5 х 10 48 уникальных хэш-ключей.

ПЛЮСЫ ДЕДУПЛИКАЦИИ

На первом месте стоит эффективное использование места для хранения данных. По информации от компании EMC дедупликация данных в среднем снижает потребности в емкости хранения от 10 до 30 раз. Очевидно, это имеет большую экономическую выгоду. Так же дедупликацию выгодно использовать при низкой пропускной способности сети, так как передаются только уникальные данные. Касаемо резервного копирования дедупликация дает возможность чаще создавать резервные копии и хранить их более длительное время.

BACKUP EXEC DEDUPLICATION

Скачать

Рассмотрим более подробно настройку дедупликации на сервере Backup Exec для локального диска или диска презентованного дисковым массивом (без дедупликации на уровне массива). Для этого нам необходимо создать Storage c функцией дедупликации.

На этом настройку можно считать выполненной, остается только создать задания для бэкапа. Важно помнить, что на сервере Backup Exec может быть только один deduplication disk storage, это необходимо помнить при планировании резервного копирования.

В случае, когда используется устройство OpenStorage (с поддержкой дедупликации на стороне клиента) система позволяет выполнить дедупликацию на стороне клиента в обход сервера Backup Exec. Для этого необходимо открыть бэкап-задание нужного устройства и в свойствах на вкладке Storage указать «Enable the remote computer to directly access the storage device and to perform client-side deduplication, if it is supported».

Система Veritas Backup Exec предоставляет разные возможности для дупликации данных. Поэтому ещё на стадии проектирования системы резервного копирования важно тщательно подходить к планированию, а так же иметь полное представление о вашей инфраструктуре, понимать все узкие места. Всё это необходимо учитывать для оптимального и эффективного использования ресурсов, так как это может дать существенную экономию бюджета и выигрыш по скорости и глубине резервного копирования.

Источник

8 мифов о дедупликации

Пришло время рассмотреть все мифы и узнать где правда в вопросах дедупликации для массивов данных.

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

Не важно, являетесь ли вы администратором системы хранения уровня tier-1, архивного хранилища или all-flash гибридных систем хранения, вам будет интересно пройтись по мифам и легендам дедупликации, чтобы избежать досадных ошибок при проектировании или работе с вашими системами хранения.

Коэффициент сокращения данных: чудес не бывает

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

Дедупликация — это автоматический процесс, существующий на многих массивах известных производителей, но потенциальный коэффициент, который вы можете получить, отличается у массивов разного типа. В результате, например, если вам будет нужен массив на 100ТБ, а вы будете считать коэффициент 10:1, то и приобретете хранилище под 10ТБ, или, скажем, если вы будете оценивать коэффициент как 2:1, следовательно, приобретете хранилище на 50ТБ – в итоге, эти совершенно разные подходы, приводят к совершенно разной стоимости покупки! Вы должны на практике понять какой коэффициент вы можете получить на ваших продуктивных данных, прежде чем сделать выбор в пользу определенной модели с определенным объемом.

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

Как минимум, понимание на базовом уровне 8 мифов, приведенных далее, позволит вам осознанно понять дедупликацию и оценить ее коэффициент для ваших данных.

Миф1. Больший коэффициент дедупликации дает больше преимуществ для хранения данных

Верно ли утверждение, что если один вендор предлагает коэффициент дедупликации 50:1 это в пять раз лучше альтернативного предложения 10:1? Нужно проверять и сравнивать совокупную стоимость влдения! Дедупликация позволяет сократить требования к ресурсам, но какова потенциальная экономия объема? 10:1 позволяет уменьшить размер хранимых данных (reduction ratio) на 90%, в то время как коэффициент в 50:1 увеличивает этот показатель на 8% и дает 98% reduction ratio (см. график ниже). Но это только 8% разницы…

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

К примеру, у вас есть офис, в котором работают клерки. Со временем, если увеличивать количество клерков, не увеличивая размер помещения, они будут мешаться под ногами друг у друга и возможно затраты будут превышать доходы.

Рис. 1 Рост коэффициента дедупликации и сокращение объемов хранения

Миф2. Есть четкое определение термина «дедупликация»

Дедупликация позволяет сократить объем хранимых данных, удаляя повторяющиеся последовательности данных из пула. Дедупликация может быть на файловом уровне, блочном уровне или на уровне приложения или контента. Большая часть продуктов сочетают дедупликацию с компрессией, чтобы еще сильнее сократить объем хранимых данных. В то время, как некоторые производители не разделяют эти термины, некоторые разделяют их и вводят такие термины, как «уплотнение» (compaction), что, по сути, является просто другим названием «дедупликации плюс сжатие». К сожалению, не существует единственного определения дедупликации. В обывательском уровне вам будет важно, как вы сможете сэкономить на дисковых ресурсах вашей системы хранения и резервного копирования, применяя дедупликацию. Ниже мы раскроем эту тему.

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

Для систем хранения оперативных данных в массиве 3PAR разработан целый комплекс утилит и механизмов, позволяющий сократить объем данных на продуктивном массиве.
Этот комплекс носит название HPE 3PAR Thin Technologies и состоит из нескольких механизмов:

Рис. 2 Технологии Thin в массивах 3PAR

Миф3. Коэффициенты дедупликации на основном массиве такие же, как и на массиве с резервными копиями.

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

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

Поэтому для оперативных массивов хранения данных иметь коэффициент 5:1 также замечательно, как иметь коэффициент 30:1 или 40:1 для систем резервного копирования, поскольку коэффициент этот зависит от того, сколько копий продуктивных данных хранится на таких массивах.

Если рассматривать продукты компании HPE, то в массивах для оперативного хранения HPE 3PAR поиск повторяющихся последовательностей (например, при инициализации виртуальных машин или создании снэпшотов) проходит «на лету» на специальной микросхеме ASIC, установленной в каждом контроллере массива. Этот подход позволяет разгрузить центральные процессоры массива для других, более важных, задач и дает возможность включить дедупликацию для всех типов данных, не боясь, что массив «просядет» под нагрузкой. Подробнее про дедупликацию на массиве 3PAR можно прочитать.

Рис.3 Дедупликация в массивах 3PAR выполняется на выделенной микросхеме ASIC

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

Рис. 4 Портфель систем резервного копирования HPE StoreOnce

Про преимущества систем резервного копирования StoreOnce можно почитать в других статьях.
Для заказчиков может быть интересно, что связка HPE 3PAR и StoreOnce позволяет упростить и ускорить процесс переноса данных с продуктивного массива на систему резервного копирования без использования ПО резервного копирования или выделенного сервера бэкапа. Такая связка получила название HPE StoreOnce RMC и подробнее о ней также можно почитать в нашей статье.

Миф4. Все данные одинаковы

Здесь не должно быть никаких сомнений- все данные разные. Даже данные одного и того же приложения в различных условиях будут иметь разные коэффициенты дедупликации на одном и том же массиве. Коэффициент дедупликации для конкретных данных зависит от разных факторов:

Рис. 5 Оценка коэффициента дедупликации в зависимости от типов данных и политики резервного копирования

Миф5. Группировка несвязных типов данных повышает уровень дедупликации

В теории, вы можете смешивать совершенно разные типы данных в общем пуле хранения для дедупликации. Может возникнуть ощущение, что вы имеете очень большой набор уникальных данных и, следовательно, вероятность нахождения в этом пуле уже записанных ранее блоков или объектов будет велика. На практике же этот подход не работает между несвязанными типами данных, например, между БД и Exchange, поскольку форматы данных разные, даже если хранится один и тот же набор данных. Такой, все время растущий пул, становится более сложным и требует больше времени для поиска повторяющихся последовательностей. Лучшей практикой является разделение пулов по типу данных.

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

Рис.6 Зависимость коэффициента дедупликации от количества виртуальных машин в пуле и размеров блока данных.

Миф6. Ваше первое резервное копирование покажет вам ожидаемый коэффициент дедупликации.

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

График ниже показывает очень типичную кривую коэффициента дедупликации. Приложение, в этом графике — БД SAP HANA, но большинство приложений показывает схожую кривую. Ваше первое резервное копирование показывает определенную дедупликацию, но большая экономия достигается благодаря сжатию данных. Как только вы начинаете держать в пуле больше копий данных — коэффициент дедупликации пула начинает расти (голубая линия). Коэффициент индивидуального бэкапа взмывает вверх уже после создания второй копии (орнжевая линия), т.к. на блочном уровне первый и второй бэкап очень похожи.

Рис. 7 График роста коэффициента дедупликации при увеличении количества резервных копий (подробнее в документе).

Миф7. Вы не можете увеличить уровень дедупликации

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

Изменение политики резервного копирования, определенно также влияет на коэффициент дедупликации, как можно увидеть в примере ниже для реального типа данных, где сравниваются политики создания полных копий и комбинации полных копий с инкрементальными и дифферентальными бэкапами. В примере ниже лучший коэффициент получается при использовании только дневных полных бэкапов. Тем не менее, на одних и тех же данных объем хранения является довольно разным для всех трех подходов. Поэтому необходимо понимать, что изменение в вашем подходе к резервному копированию может довольно сильно повлиять на коэффициент дедупликации и на физический объем хранимых данных.

Миф8. Нет возможности заранее спрогнозировать коэффициент дедупликации

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

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

Но наиболее точный прогноз по коэффициенту дедупликации получается в ходе проведения испытаний на реальных данных.

Рис. 8 Изменение коэффициента дедупликации и объема занимаемых данных в зависимости от политики резервного копирования на данных конкретного заказчика

У компании HPE есть набор утилит и сайзеров, позволяющий спрогнозировать (с неким допущением) тот объем систем хранения, который необходим заказчикам.

И получить предварительную оценку:

Итак, нет никакой магии за понятием дедупликации, а развенчивание мифов, приведенное выше, позволит вам лучше понять, на что способны ваши данные и позволит вам спрогнозировать утилизацию ваших массивов.

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

И, самое главное, если все это внедрить во всей экосистеме — и разработчикам ПО, и вендорам, и CIO, то через несколько лет экономия от этого будет больше, чем от дедупликации.

Источник

Введение в дедупликацию данных

Введение

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

Действительно, рост объема данных на терабайты в год у какой-нибудь крупной организации – сегодня вполне реальный сценарий. Но как быть с эффективным хранением и резервным копированием? Ведь в сутках есть максимум 24 часа и окно резервного копирования не может расти бесконечно (в отличие от самих данных). Сегодня я хочу рассказать, как дедупликация может помочь уменьшить остроту этой проблемы.

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

В широком смысле, существует два основных вида дедупликации:

Обычно, чем более гранулярная схема дедупликации используется, тем больше экономия места в хранилище данных.

Что такое SIS? Суть метода проста, например, если существуют 2 файла, которые абсолютно идентичны, то один из них заменяется ссылкой на другой. Такой механизм успешно работает в почтовых серверах (например, Exchange) и в базах данных. Например, если один пользователь корпоративной почты отправит письмо с прикрепленным файлом нескольким адресатам, то этот файл будет сохранен в базе Exchange только один раз.

Звучит здорово! Но только до той поры, пока файлы абсолютно идентичны. Если один из идентичных файлов будет изменен хотя бы на байт, будет создана его отдельная измененная копия и эффективность дедупликации снизится.

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

Области применения дедупликации

Большинство разработчиков продуктов с поддержкой дедупликации сосредоточены на рынке резервного копирования. При этом со временем резервные копии могут занимать в два-три раза больше места, чем сами оригинальные данные. Поэтому в продуктах резервного копирования давно применяется файловая дедупликация, которой, однако, может быть недостаточно при определенных условиях. Добавление блочной дедупликации может значительно повысить эффективность использования систем хранения и сделать выполнение требований отказоустойчивости системы более легким.

Другой способ использования дедупликации – использование ее на серверах продуктивной системы. Это может быть сделано средствами самой ОС, дополнительным ПО или аппаратурой хранилища данных (СХД). Здесь требуется внимательность, например, Windows 2008 — ОС, позиционируемая, как способная производить дедупликацию данных, делает только SIS. В тоже время СХД могут производить дедупликацию на блочном уровне, представляя файловую систему для пользователя в развернутом (оригинальном) виде, скрывая все детали связанные с дедупликацией. Предположим, что на СХД есть 4 ГБ данных, дедуплицированных до 2 ГБ. Иными словами, если пользователь обратится к такому хранилищу, он увидит 4 ГБ данных и именно такой их объем будет помещен в резервные копии.

Сокращенные проценты и большие надежды

Процент сохраненного места на диске – наиболее важная область, которой легко манипулируют, говоря о “95% уменьшении размеров файлов резервного копирования”. Однако, алгоритм, используемый для подсчета этого соотношения, может быть не вполне релевантным к вашей конкретной ситуации. Первую переменную, которую следует принять во внимание, – это типы файлов. Такие форматы, как ZIP, CAB, JPG, MP3, AVI – это уже сжатые данные, которые дают меньший коэффициент дедупликации, чем несжатые данные. Не менее важна частота изменения данных для дедупликации и количество архивных данных. Если вы используете продукт, который дедуплицирует существующие данные на файловом сервере, то не стоит переживать. Но если дедупликация используется, как часть системы резервного копирования, то нужно ответить на следующие вопросы:

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

Время – наше все

Говоря о дедупликации в системах резервного копирования, нам важно знать, как быстро она выполняется. Существует три основных типа дедупликации:

Первый тип: Дедупликация на стороне источника данных

Она выполняется на самом устройстве, где находятся исходные данные. Любые данные, помеченные для резервного копирования, поделены на блоки, для них посчитан хеш. Здесь можно заметить 3 потенциальные проблемы.

Target (или пост-процессная) дедупликация

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

Транзитная дедупликация

Транзитная дедупликация объясняется, как процесс, происходящий в течение переноса данных из source на target. Термин немного сбивает с толку. Данные на самом деле не дедуплицируются «в проводе». На самом деле это значит, что данные, собранные в оперативной памяти target устройства, дедуплицируются там перед операцией записи на диск. Это выводит время поиска диска из уравнения. Транзитная дедупликация может рассматриваться как лучшая форма target дедупликации. Она имеет все преимущества глобального представления данных наряду с разгрузкой процесса хеширования, но ни одного из недостатков медленного I/O дисков.

Однако она все еще представляет большой сетевой трафик и потенциальные хеш-коллизии. Этот метод требует наибольших вычислительных ресурсов (процессора и памяти) среди всех перечисленных.

Подведение итогов

Технологии дедупликации могут помочь снизить затраты на покупку систем хранения. Следует продуманно выбирать тип дедупликации. В конечном счете, дедупликация позволит компании медленнее наращивать расходы на хранение своих растущих данных.

Источник