Читать полный материал
Дедупликация и сжатие в бэкапах: как считать реальную экономию места
Маркетинговые коэффициенты дедупликации в духе «до 30:1» звучат впечатляюще, но одинаковый результат для другой инфраструктуры не гарантирован. Реальная экономия места зависит от типа данных, частоты бэкапов и глубины хранения.
В статье — официальная механика дедупликации и сжатия по документации Dell, Veeam, Microsoft и Veritas: чем эти две техники отличаются и как сочетаются, что такое inline и post-process дедупликация, source-side и target-side, почему алгоритм разбиения на блоки влияет на итоговую экономию, и как официально рекомендуется оценивать реальную экономию для конкретной нагрузки. Про выбор самой схемы бэкапа — в статье «Полный, инкрементный, дифференциальный бэкап — как выбрать».
Что разобрано в статье
Дедуп vs сжатие
Официальное разграничение Dell Data Domain: две разные техники, работающие вместе.
Inline / post-process
Официальные архитектуры Dell Data Domain и Microsoft — две разные модели.
Source / target
Официальная механика Veeam и Veritas — где именно выполняется дедупликация.
Chunking
Официальное сравнение Dell: fixed-block против sliding window.
Реальная оценка
Официальный инструмент Microsoft DDPEval и факторы Dell, влияющие на ratio.
Что такое дедупликация и чем она отличается от сжатия
Дедупликация находит повторяющиеся фрагменты в файлах и сохраняет уникальный блок один раз, а остальные обращения связывает с ним. Это уменьшает повторное хранение одинаковых данных в наборе резервных копий.
Сжатие уменьшает размер одного фрагмента алгоритмом кодирования. Дедупликация сравнивает новый блок со всем уже сохранённым набором. На практике техники применяют последовательно: повторяющиеся сегменты исключают, а оставшиеся уникальные регионы дополнительно сжимают.
Inline и post-process дедупликация
Inline-дедупликация обрабатывает данные до записи на диск: на носитель попадает уже сокращённый поток. Post-process сначала записывает данные без оптимизации, а затем выполняет обработку отдельным заданием. Для планирования ёмкости и производительности это принципиально разные режимы.
В Windows Server архитектура дедупликации использует post-process: оптимизация выполняется после записи. Это влияет на потребление ресурсов: системе нужно периодически выделять их отдельно под процесс дедупликации, а не только под запись данных.
Source-side и target-side дедупликация
Source-side дедупликация сравнивает блоки на источнике и не передаёт по сети то, что уже есть в предыдущих точках восстановления. Target-side дедупликация работает в файле резервной копии на стороне хранилища и сохраняет там только уникальные блоки.
У Veritas это соответствует клиентской и серверной дедупликации. В первом случае вычисления выполняются у источника, во втором — на media server. Выбор меняет нагрузку на сеть и серверы, но не должен подменять оценку итоговой экономии.
Как данные режутся на блоки: fixed vs variable
Фиксированный метод делит поток на блоки одного размера: он экономит процессорные ресурсы, но хуже переносит смещение данных. Переменный метод ищет естественные границы контента; он требует больше вычислений, зато обычно лучше находит совпадения между изменёнными версиями файла.
При небольшом изменении файла фиксированные блоки могут «сдвинуться» и перестать совпадать с предыдущей версией. Переменные блоки находят естественные границы данных и устойчивее к таким сдвигам; этот подход использует и реализация дедупликации Microsoft.
Почему коэффициент дедупликации — не гарантия
Коэффициент из маркетингового материала нельзя считать гарантией. Результат зависит от структуры исходных данных, файловой системы назначения и того, насколько похожи очередные копии на уже сохранённые.
На фактический коэффициент влияют алгоритм, тип данных, частота резервного копирования и глубина хранения. В первой копии почти нет накопленного материала для сравнения, поэтому заметная экономия часто возникает позже. Даже одинаковый набор данных на разных системах не обязан дать одинаковый результат.
Как официально оценить реальную экономию
Для предварительной оценки Microsoft предлагает утилиту DDPEval: она показывает размер обработанных и оптимизированных файлов, абсолютную и процентную экономию. Таблицы типичной экономии полезны только как ориентир по классу данных, а не как обещание для конкретной инфраструктуры.
Если готовой оценки для нагрузки нет, правильный путь — пилот на тестовом наборе, который похож на рабочие данные. Так измеряют экономию, влияние на ресурсы и приемлемое окно обработки до покупки или включения функции.
Какие данные дедуплицируются плохо
Уже сжатые и зашифрованные данные обычно дают слабую дедупликацию: преобразование меняет поток, и повторяющиеся части труднее сопоставить. К типичным примерам относятся архивы, образы, базы данных, PDF, аудио и видеофайлы.
Та же логика действует при включённом шифровании: зашифрованный поток плохо сжимается, поэтому в ряде сценариев Veeam не применяет к нему дополнительное сжатие.
Частые вопросы
Дедупликация и сжатие — это одно и то же?
Нет. Сжатие уменьшает отдельный фрагмент, а дедупликация устраняет повторения во всём сохранённом наборе. На практике сначала исключают повторяющиеся сегменты, а затем дополнительно сжимают уникальные данные.
Можно ли доверять маркетинговым цифрам «до 30:1»?
Как ориентир — да, как гарантию — нет. Официальная документация Dell прямо говорит, что нет гарантии получить такой же коэффициент, какой видел другой дата-центр — результат зависит от типа данных, частоты бэкапов и глубины хранения.
Как понять, сколько места реально сэкономит дедупликация на моих данных?
По официальной рекомендации Microsoft — использовать встроенный инструмент DDPEval для оценки конкретного набора данных перед включением дедупликации, либо провести пилотное развёртывание на тестовом датасете, если тип нагрузки не входит в число проверенных вендором сценариев.
Почему в первом бэкапе экономия места намного меньше, чем в последующих?
По официальной документации Dell Data Domain, в первом бэкапе почти нет данных для сравнения, поэтому основная экономия там достигается за счёт сжатия, а не дедупликации. Эффект дедупликации проявляется в полную силу начиная со следующих бэкапов, когда в системе уже накоплены данные для сравнения.
Зашифрованные бэкапы вообще не экономят место?
По официальной документации Dell, уже сжатые или зашифрованные данные дедуплицируются и сжимаются заметно хуже обычных данных, потому что шифрование и сжатие меняют структуру данных так, что повторяющиеся блоки перестают быть похожи друг на друга. Официальная документация Veeam подтверждает это косвенно: включение шифрования у Veeam автоматически отключает попутное сжатие данных.
Поможете подобрать СХД под бэкапы с учётом реальной экономии места?
Да. Пришлите объём данных, тип нагрузки и требуемую глубину хранения на info@andpro.ru или через форму на /services/ — подберём систему хранения и схему резервного копирования под задачу.
Авторство и ответственность
Материал подготовлен для блога ANDPRO / ООО «АНД-Системс» как информационная статья о механике дедупликации и сжатия в системах резервного копирования. Статья не заменяет индивидуальный расчёт ёмкости хранилища под конкретную инфраструктуру и требования к резервному копированию.
Материал подготовлен при участии AI-ассистента, прошёл фактчекинг и редакторскую вычитку. Формулировки проверены против официальной документации Dell, Veeam, Microsoft и Veritas — см. sources.md.
Для подбора инфраструктуры резервного копирования обратитесь в ANDPRO: info@andpro.ru, +7 (495) 545-48-70, +7 (800) 707-78-15.
Дата последнего обновления материала: 8 сентября 2026 года.
