Перейти к содержанию
HexaTransfer
Вернуться к блогу
Облако и хранение

Стратегии дедупликации файлов в облачном хранилище

Снижайте расходы на хранение с помощью дедупликации файлов. Блочная, пофайловая и inline-дедупликация объяснены подробно.

Дедупликация файлов сокращает облачное хранилище на 20–90% в зависимости от рабочей нагрузки, используя одну из трёх техник: пофайловая (хранить одинаковые файлы один раз, с ключом по SHA-256-хешу), блочная (нарезать файлы на блоки 4–128 КБ и дедуплицировать по блокам) или нарезка переменной длины через content-defined chunking (CDC) с отпечатками Рабина. Резервные копии ВМ дают снижение 10:1; обычные офисные файлы — 2:1; медиатеки — почти ничего. Выбирайте технику, соответствующую вашим данным — запуск блочной дедупликации на библиотеке уникальных .mp4 тратит CPU впустую.

Пофайловая дедупликация: простейший выигрыш

Пофайловая дедупликация сравнивает хеши целых файлов. Два файла с одинаковым SHA-256 идентичны: храним один, другой указывает на него. Реализация занимает выходные:

  1. Составьте инвентарь бакета (S3 Inventory, Azure Inventory, GCS bucket list)
  2. Вычислите SHA-256 для каждого объекта (или используйте ETag провайдера, с оговорками)
  3. Сгруппируйте по хешу, выберите канонический ключ на группу, обновите ссылки, удалите дубликаты

Оговорки: ETag S3 соответствует SHA-256 только для однокомпонентных загрузок до 5 ГБ. Составные загрузки используют другую формулу (хеш хешей). Для надёжной дедупликации вычисляйте собственный хеш через aws s3 cp s3://bucket/key - | sha256sum или вычисляйте при загрузке и храните в метаданных.

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

Блочная дедупликация: крупный множитель

Блочная дедупликация делит каждый файл на чанки фиксированного размера (4 КБ, 16 КБ, 64 КБ) и хеширует каждый. Два файла, разделяющих 80% чанков, хранят только уникальные 20% плюс одну копию общих блоков. Продукты резервного копирования (Veeam, Rubrik, Commvault), файловые системы (ZFS с dedup=on, Btrfs) и некоторые облака резервного копирования используют это.

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

Для облачного объектного хранилища блочная дедупликация обычно происходит внутри продукта резервного копирования, а не как нативная функция. S3 сам по себе не дедуплицирует; Backblaze B2 дедуплицирует при загрузке, когда клиент сначала отправляет хеши блоков.

Content-Defined Chunking (CDC)

Фиксированная нарезка ломается при вставке байта в начало файла — каждый последующий блок хешируется по-другому. CDC использует скользящий хеш (отпечаток Рабина-Карпа) для определения границ чанков на основе паттернов содержимого. Вставьте байт — изменится только непосредственный чанк.

CDC — основа restic, BorgBackup, Duplicacy и Kopia. Эти open-source инструменты дедуплицируют на стороне клиента с переменными чанками, в среднем по 1–4 МБ. При резервном копировании 500 ГБ файлов с инкрементными изменениями CDC-based резервные копии часто используют менее 50 ГБ уникального хранилища.

Если вы строите систему резервного копирования или синхронизации, CDC через библиотеку fastcdc-rs или chunky — современный выбор. Не реализуйте собственный скользящий хеш — крайние случаи тонкие.

Inline против постобработки дедупликации

Inline-дедупликация работает во время записи — прежде чем данные попадают на диск, система проверяет, существует ли блок. Если да — пишет ссылку; если нет — пишет блок. Используется ZFS, большинством backup-аплайансов и некоторыми облачными уровнями хранения.

Постобработка пишет сначала, затем запускает фоновое задание для поиска дублей и освобождения места. Используется дедупликацией данных Windows Server, NetApp SnapVault и большинством пользовательских инструментов. Постобработка имеет меньшую задержку записи, но требует большего пикового хранилища (дубли кратко существуют до высвобождения).

Для облачных нагрузок inline-дедупликация обычно недоступна — S3 не предлагает её. Постобработка с запланированным заданием (ежедневная инвентаризация, ежедневный прогон дедупликации) — практический паттерн.

Когда дедупликация не помогает

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

Это означает, что сквозное зашифрованное хранилище файлов не может дедуплицировать между пользователями. Конвергентное шифрование (хешировать открытый текст, использовать хеш как ключ) было попыткой включить дедупликацию для E2EE, но имеет уязвимости — позволяет атаки подтверждения файла. Для E2EE-сервисов файлов принимайте, что дедупликация происходит внутри собственных файлов пользователя, но не между пользователями.

Сторона безопасности дедупликации

Кросс-пользовательская дедупликация в не-E2EE системах создаёт побочный канал: если загружаемый вами файл дедуплицируется с существующим блоком, сервер узнаёт, что у кого-то другого уже был этот файл. Dropbox столкнулся с этим в 2011 году; другие сервисы тоже. Для общих бизнес-аккаунтов это нормально, но для сервисов, заявляющих о конфиденциальности, — это утечка.

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

Измерение эффективности дедупликации

Не просто включайте дедупликацию и надейтесь. Измеряйте коэффициент:

dedup_ratio = logical_bytes / physical_bytes

Соотношение 2:1 означает, что на каждый 1 физический байт хранится 2 логических. Инструменты отчётности: zpool get dedupratio для ZFS, Get-DedupStatus на Windows Server, статистика по репозиторию в restic/Borg.

Здоровые коэффициенты по нагрузкам:

  • Образы ВМ: 8–20:1
  • Резервные копии баз данных: 10–30:1
  • Файловый сервер (офисные документы): 1,5–3:1
  • Почтовые архивы: 2–5:1
  • Медиатеки: 1,0–1,1:1 (не стоит)
  • Зашифрованные архивы: 1,0:1 (невозможно)

Если коэффициент нагрузки ниже 1,5:1, отключите дедупликацию — CPU и память не окупаются.

Интеграция с продуктами резервного копирования

Большинство предприятий не реализуют дедупликацию с нуля — они используют продукт резервного копирования. Точки сравнения при выборе:

  • Veeam: Inline блочная дедупликация, чанки по 512 КБ по умолчанию, сжатие после дедупликации
  • Rubrik: Переменные чанки CDC, подблочная дедупликация
  • Commvault: Клиентская дедупликация с пулами на клиента и глобальными
  • restic/Borg/Kopia: Open-source CDC, клиентская, бэкенды S3/B2/Azure
  • BackupPC: Пофайловые жёсткие ссылки, просто, но устарело

Для малого бизнеса, резервирующего 2 ТБ в S3 Glacier, restic в Glacier Instant Retrieval стоит около 1 350 ₽/месяц при дедупликации 5:1. Для корпоративного архива в 500 ТБ полноценная платформа резервного копирования с дедупликацией окупается в первый же год экономии на хранилище.

Когда добавлять сжатие поверх дедупликации

Дедупликация удаляет дублированные байты; сжатие удаляет избыточность внутри уникальных байт. Они складываются. После дедупликации применяйте zstd-сжатие для ещё 1,5–2-кратного снижения на текстоёмких данных. BorgBackup поддерживает --compression zstd; restic — --compression max; AWS EFS имеет прозрачное сжатие для OneZone-IA.

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

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

Попробуйте на hexatransfer.com — бесплатно, без регистрации, до 10 ГБ.

Безопасная отправка больших файлов со сквозным шифрованием

Передавайте файлы до 10 ГБ бесплатно со сквозным шифрованием. Регистрация не требуется. Ваши файлы шифруются в браузере перед загрузкой — никто другой не может их прочитать.

Отправить файл