Дедупликация резервных копий на реальных данных

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

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

Экономит повторяемость, а не объем

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

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

Полезно держать три величины раздельно:

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

Коэффициент дедупликации обычно считают как отношение логического объема к объему уникальных данных. Если 100 ТБ логических копий превратились в 20 ТБ уникальных блоков, коэффициент равен 5:1, а экономия места составляет 80 процентов. Формулировка «экономия в пять раз» понятна, но для финансовой модели нужна именно физическая емкость. При коэффициенте 5:1 нельзя заполнять купленные 20 ТБ до последнего байта: индексу, сборке мусора, временным операциям и росту новых данных нужен запас.

Документация Microsoft по Data Deduplication приводит высокие диапазоны для библиотек виртуализации и более умеренные для пользовательских файлов. Это хороший пример связи результата с типом данных, но плохая основа для сметы чужой системы. Там описан конкретный механизм Windows Server, его размеры фрагментов, правила отбора файлов и собственное сжатие. Переносить цифру из таблицы на другую платформу, другую политику хранения и зашифрованный резервный поток нельзя.

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

Большой выигрыш дают похожие версии

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

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

Хорошие кандидаты обычно выглядят так:

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

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

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

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

Сжатые и зашифрованные потоки почти не повторяются

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

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

Порядок операций решает исход. Рабочая последовательность внутри одной доверенной системы выглядит так: найти повторы, сжать уникальные фрагменты, затем зашифровать сохраненные данные. В материале Dell о PowerProtect DD именно такой порядок объясняется как причина, по которой внутреннее шифрование в состоянии покоя совместимо с сокращением данных. Тот же материал предупреждает, что предварительно сжатый или зашифрованный вход меняет битовые последовательности и ухудшает внешний поиск совпадений. Это конкретное поведение продукта, но физика применима шире.

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

Низкий результат также ожидаем для таких наборов:

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

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

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

Границы фрагментов меняют результат

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

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

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

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

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

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

Процессор и память оплачивают каждый пропущенный блок

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

Универсальной формулы «столько гигабайт RAM на терабайт диска» нет. Память зависит прежде всего от числа уникальных фрагментов и структуры индекса, а не только от физической емкости. Средний размер фрагмента 64 КиБ дает примерно 16 миллионов фрагментов на 1 ТиБ уникальных данных до учета упаковки и метаданных. Десятки миллионов записей не означают, что весь индекс обязан постоянно лежать в RAM, но показывают масштаб задачи. Более мелкая нарезка и большой уникальный набор повышают требования.

Для конкретного ориентира Microsoft рекомендует своей Data Deduplication оптимально выделять около 1 ГБ памяти на 1 ТБ логических данных, а минимальная формула в документации ниже. Это число нельзя переносить на аппаратный дедупликатор или другую программу. Оно полезно как напоминание: производитель связывает максимальную производительность со значительным объемом памяти, а режим с минимальным ресурсом прямо описывает как более медленный.

Нагрузка появляется в разных местах:

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

Inline-обработка должна успевать за входным потоком. Если массив способен принять 4 ГБ/с, а дедупликатор обрабатывает 1,5 ГБ/с, полезная скорость всей системы равна меньшему числу. Добавление дисков не исправит узкое место в вычислении хешей или индексе. Постпроцессная схема может принять данные быстрее, но до завершения оптимизации хранит больше и конкурирует за I/O с новыми заданиями.

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

Восстановление читает уникальные блоки в неудобном порядке

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

Для одного небольшого восстановления кеш часто скрывает цену. Популярные блоки читаются повторно и остаются в памяти, поэтому отдельная виртуальная машина возвращается быстро. Аварийное восстановление всего узла или площадки ведет себя иначе: система одновременно запрашивает много уникальных блоков, метаданные и данные конкурируют за I/O, а процессор распаковывает поток. Именно этот сценарий надо сравнивать с целевыми RTO, а не восстановление одного файла на стенде.

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

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

Тест восстановления должен отвечать на четыре вопроса:

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

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

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

Пилот на ваших данных дает честный коэффициент

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

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

Для Windows Server Data Deduplication исходное состояние и результат можно снять так:

Get-DedupStatus | Select-Object Volume,Capacity,FreeSpace,SavedSpace,SavingsRate,OptimizedFilesCount,InPolicyFilesCount
Get-DedupJob
Get-DedupMetadata D:

Форма первой строки вывода выглядит так, значения у вашей системы будут другими:

Volume Capacity FreeSpace SavedSpace SavingsRate OptimizedFilesCount InPolicyFilesCount
D:     ...      ...       ...        ...         ...                 ...

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

План измерения состоит из пяти действий:

1. Зафиксируйте физически занятое место, логический объем и свободную емкость до загрузки.
2. Выполните одну полную копию, затем обычные задания до окончания выбранного цикла хранения.
3. Запишите входной объем, новые уникальные данные, CPU, пиковую RAM, сетевой трафик и длительность каждого задания.
4. Удалите просроченную точку, дождитесь штатной сборки мусора и снова измерьте физическое место.
5. Восстановите один файл, одну крупную систему и несколько систем параллельно с холодным кешем.

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

Отдельно посчитайте цену вычислений. Если дедупликация экономит 40 ТБ диска, но ради нее нужны лицензия, 256 ГБ дополнительной RAM, более мощные CPU и второй узел для требуемой скорости, сравнивать нужно суммарную стоимость владения. В нее входят питание, поддержка, резервная емкость на период обслуживания и время оператора. Иногда дешевле хранить уникальный медиапоток без дедупликации на плотных дисках, а механизм применять только к виртуальным машинам.

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

Финансовая модель начинается с ежедневного прироста

Закупку надо считать по новым уникальным данным в день и сроку хранения. Пусть источники отправляют 8 ТБ в сутки, а после дедупликации и сжатия физически добавляется 1,6 ТБ. Текущий фактор сокращения равен 5:1. При хранении 30 дневных точек грубая рабочая емкость для этого потока составит 48 ТБ, но к ней нужны базовый набор, метаданные, запас для обслуживания и рост.

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

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

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

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

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

Архитектуру выбирают по восстановлению

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

При выборе платформы задайте поставщику конкретные вопросы: где строится индекс, каков его предел, что происходит при переполнении RAM, как восстанавливается индекс, какой запас свободного места нужен, когда запускается сборка мусора и какова скорость массового восстановления с холодным кешем. Попросите результат на вашем профиле данных. Ответ «зависит от нагрузки» верен, но за ним должен следовать план пилота.

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

Фиксируйте исходные допущения в проекте: типы данных, ежедневное изменение, срок хранения, долю полных копий, положение шифрования, окно дедупликации, целевой RTO и параллелизм восстановления. Через квартал сравните их с фактом. Если уникальный прирост ушел вверх, план расширения надо менять до заполнения массива, а не после первого сорванного задания.

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