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

Прямой ответ

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

# Создание копии с дедупликацией и сжатием
restic -r /backup/repo backup /data --compression auto

# Проверка целостности хранилища
restic -r /backup/repo check

# Статистика хранилища
restic -r /backup/repo stats

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

Порядок операций, размер блока и проверка восстановимости

Три аспекта определяют эффективность и надёжность хранилища резервных копий.

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

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

Проверка восстановимости. Хранилище с дедупликацией зависит от целостности индекса: повреждение индекса делает блоки недоступными, даже если данные целы.

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

Отдельный аспект — объём метаданных. Индекс блоков занимает место, сопоставимое с объёмом уникальных данных при малом размере блока. Соотношение объёма метаданных и выигрыша от дедупликации проверяется измерением.

Три признака неэффективной дедупликации.

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

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

Отсутствие проверки целостности. Повреждение индекса обнаруживается в момент восстановления, когда данные требуются.

О стратегии хранения копий — в статье про стратегию резервного копирования; о переводе старых копий в долгосрочное хранение — в статье про архивацию данных.

Метод сжатия влияет на время создания копии и восстановления, поскольку сжатие и распаковка выполняются для каждого уникального блока.

Влияние на время восстановления

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

Сборка блоков. Файл восстанавливается из блоков, которые могут храниться в разных частях хранилища, поэтому восстановление требует чтения нескольких блоков и проверки контрольных сумм.

Распаковка. Каждый уникальный блок распаковывается при восстановлении, поэтому время зависит от метода сжатия и объёма данных.

Проверка целостности. Контрольные суммы блоков проверяются при сборке, поэтому повреждённый блок обнаруживается в процессе восстановления, а не после.

Практическое следствие: время восстановления больше времени создания копии, поэтому план восстановления учитывает дополнительную длительность.

Отдельный аспект — проверка восстановления. Тестовое восстановление выполняется периодически, поскольку копия, из которой данные не извлекаются, не выполняет назначения.

Практика: настройка дедупликации и сжатия копий

1. Выполняйте дедупликацию до сжатия. Дедупликация определяется по исходному содержимому блоков, поэтому сжатие выполняется после.

2. Выберите размер блока по характеру данных. Малый блок повышает долю совпадений, но увеличивает объём метаданных.

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

4. Измеряйте фактическую экономию. Статистика хранилища показывает объём уникальных блоков и долю дедупликации.

5. Проверяйте восстановление. Копия, из которой данные не извлекаются, не выполняет назначения.

6. Учитывайте объём метаданных. Индекс блоков занимает место, сопоставимое с объёмом уникальных данных при малом блоке.

7. Не храните единственную копию в хранилище с дедупликацией. Зависимость от индекса делает повреждение метаданных потерей доступа ко всем копиям.

Рекомендации:

1. Различайте дедупликацию и инкрементальное копирование. Дедупликация исключает повторное хранение блоков, инкрементальная копия сокращает объём переноса.
2. Учитывайте стоимость восстановления. Распаковка и сборка блоков выполняются при восстановлении, поэтому время восстановления больше времени создания копии.
3. Проверяйте поведение на изменяющихся данных. Данные, которые переписываются целиком, дают низкую долю совпадений.
4. Фиксируйте параметры хранилища. Размер блока и метод сжатия задаются при создании и не изменяются для существующего хранилища.
5. Ведите журнал проверок целостности. Периодичность и результаты проверок фиксируются, чтобы обнаруживать деградацию хранилища.

Практический сценарий: хранилище копий не сократило объём

Контекст: хранилище с дедупликацией настроено, но объём занят под копии почти пропорционально их числу.

1. Диагностика. Данные представляли собой архивные файлы, которые пересоздавались целиком при каждом сохранении. Блоки внутри архива не совпадали с предыдущими, поскольку порядок и выравнивание содержимого менялись.
2. Причина. Дедупликация выполняется по блокам содержимого, а пересоздание архива меняет расположение данных внутри файла. Совпадающих блоков оказалось мало, поэтому экономия не проявилась.
3. Действия. (а) Перешли к копированию исходных файлов вместо пересозданного архива, чтобы расположение данных оставалось стабильным; (б) уменьшили размер блока, чтобы повысить долю совпадений для малых изменений; (в) измерили долю дедупликации по статистике хранилища после изменения; (г) включили периодическую проверку целостности хранилища; (д) выполнили тестовое восстановление для подтверждения пригодности копий.
4. Результат. Объём хранилища перестал расти пропорционально числу копий, поскольку совпадающие блоки хранятся один раз.

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

FAQ

В каком порядке выполнять дедупликацию и сжатие? Дедупликация по исходному содержимому блоков, затем сжатие уникальных блоков. Сжатие до дедупликации изменяет содержимое и снижает долю совпадений.

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

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

Можно ли хранить единственную копию в хранилище с дедупликацией? Нет, зависимость от индекса делает повреждение метаданных потерей доступа ко всем копиям. Требуется отдельная копия без дедупликации.

Источники: restic, BorgBackup, Zstandard — ссылки в шапке.