Comments 27
Если, как вы сказали, это у вас бэкапы, то используйте restic или borg, и нижележащие файловые системы вообще не будут иметь влияния, хоть на FAT храните.
Если брать чисто кейс с моим дата сетом, то да согласен, но мне хотелось покопаться и сравнить именно разные варианты дедупликации.
У меня в проде был когда то массив от PureStorage, уж не знаю на базе чего у них была построена FS, но массив дедупил на лету все и вся с очень хорошими коэффициентами, я надеялся что найду +- похожее решение на Linux.
Неудобно (хоть и не критично), что нужно использовать рестик или борг, вместо того чтобы "просто скопировать файлы"
Плюс к тому и рестик и борг делают дедуп в рамках одного бэкап-архива. Если у вас бэкап двух почти одинаковых БД, то дедупликации не будет (между ними). В случае с ФС дедеп применяется для всех записанных данных.
С другой стороны в borg/restic дедупликация со сжатием может более эффективная, чем дедупликация сжатых файлов на ФС. Так же при бэкапе боргом по сети сначала производится дедупликация (подсчет хэшей блоков), а потом передача измененных блоков данных. Это может быть полезно, так меньше нагружает сеть, она не будет узким местом при терабайтных бэкапах повторяющихся данных, ведь на удаленный сервер будут переданы только изменённые блоки.
позволю себе вставить свои 5 копеек по поводу bees, а то глаз дёргается когда так пишут systemd юниты.
1) у systemd для сервисов могут быть аргументы (передаются через @ при вызове сервиса) не обязательно создавать свой юнит для каждого uuid
2) не указан type юнита
3) учитывая что такой сервис может знатно так нагрузить систему неплохо было бы его ограничить по ресурсам
с этими мыслями я пошёл посмотреть а что предлагается вместе с пакетом:
довольно большая портянка
[werwolf@power] ~
❯ rpm -ql bees | grep systemd ⏎
/usr/lib/systemd/system/beesd@.service
[werwolf@power] ~
❯ systemctl cat beesd@.service
# /usr/lib/systemd/system/beesd@.service
[Unit]
Description=Bees (%i)
Documentation=https://github.com/Zygo/bees
After=sysinit.target
[Service]
Type=simple
ExecStart=/usr/sbin/beesd --no-timestamps %i
CPUAccounting=true
CPUSchedulingPolicy=batch
CPUWeight=12
IOSchedulingClass=idle
IOSchedulingPriority=7
IOWeight=10
KillMode=control-group
KillSignal=SIGTERM
MemoryAccounting=true
Nice=19
Restart=on-abnormal
RuntimeDirectory=bees
StartupCPUWeight=25
StartupIOWeight=25
# Hide other users' process in /proc/
ProtectProc=invisible
# Mount / as read-only
ProtectSystem=strict
# Forbidden access to /home, /root and /run/user
ProtectHome=true
# Mount tmpfs on /tmp/ and /var/tmp/.
# Cannot mount at /run/ or /var/run/ for they are used by systemd.
PrivateTmp=true
# Disable network access
PrivateNetwork=true
# Use private IPC namespace, utc namespace
PrivateIPC=true
ProtectHostname=true
# Disable write access to kernel variables throug /proc
ProtectKernelTunables=true
# Disable access to control groups
ProtectControlGroups=true
# Set capabilities of the new program
# The first three are required for accessing any file on the mounted filesystem.
# The last one is required for mounting the filesystem.
AmbientCapabilities=CAP_DAC_OVERRIDE CAP_DAC_READ_SEARCH CAP_FOWNER CAP_SYS_ADMIN
# With NoNewPrivileges, running sudo cannot gain any new privilege
NoNewPrivileges=true
[Install]
WantedBy=basic.targetне скажу что в этом юните 100% то что написал бы я, но мейнтейнерам виднее
к своему удивлению не нашёл в пакете .timer юнита для этого .service юнита но это уже лирика.
Спасибо за технический комментарий.
Я привел пример минимального рабочего варианта, честно, статья отняла сильно больше сил и времени чем я планировал, поэтому пример сервиса/юнита получился довольно кривой, я старался сфокусироваться больше на теме стати и результатах.
Хотел еще подтащить OpenDedup, но с ним по быстрому не вышло, да и так портянка получилась не маленькая.
Сравнивалась работа блочной и файловой дедупликации, что не совсем корректно. Хорошо бы тогда под линукс какой-нибудь sdfs или lessfs протестировать, они на файловом уровне работают.
Я на самом деле ожидал что блочная дедупликация будет эффективнее чем файловая, вообще детального описания алгоритма от MS я не нашел, за исключением того самого описания на оффсайте, больше похоже что все таки оно работает на гибридном уровне.
Ну, судя по документации, реализация файловой дедупликации на NTFS — та же блочная, вид сбоку. Напоминает разбиение рекордов в ZFS, только offline и с постобработкой.
На ZFS, фактически, тестировалось совпадение попаданий кусков немного отличающихся файлов в txg, так как recordsize не ограничивался.
Проблемы с дедупликацией tar-архивов заметили в Proxmox еще несколько лет назад — и запилили pxar и использующий его pbs, что позволяет достигать коэффициента дедупликации за 100.
Ну и для дедупликации интереснее было бы передавать не архив а его содержимое, там результаты были бы наверняка веселее.
Опять же, для дедуплицированных блоков NTFS, судя по документации, может использовать компрессию — ZFS умеет zstd, который не включался.
Опять же, ZFS позволет дедуплицировать диски работающих ВМ, а не просто какие-то архивы.
Ремарки про невозможность восстановления ФС тоже требуют раскрытия, особенно для ZFS с ее тремя копиями метаданных.
В общем, модель сферического коня в вакууме вызывает сплошные вопросы…
Вот ради таких стаей стоит заходить на Хабр!
Cпасибо большое за такое детальное исследование и подробное описание результатов! Очень полезно и читается приятно и легко.
Интересно, сколько нужно времени, чтобы "обнаружить" специализированные дедуплицирующие СХД для резервного копирования типа DataDomain или StoreOnce?
Или например СРК (системы резервного копирования) с встроенной дедупликацией, как например Veeam?
Не совсем понимаю как трактовать ваш комментарий, если возможно ответьте более развернуто.
DataDomain — это отличная дедупликация но очень дорого.
Veeam — его эффективность достаточно хромает.
Есть ещё Avamar — это тоже не дёшево но достаточно геморно в настройке.
Хотя! DataDomain есть community edition — 600 gb (до дедупликации) бесплатно.
Илья, я был бы очень рад если бы вы написали от тестировании VDO (Идут в комплекте со всеми RedHat компиляциями). В настройке сложнее ZFS но много проще BTRFS. Производительность в моих экспериментах была не высокой, но я тестировал на Centos 7. Может современные версии шустрее ?
Кстати, под винду есть утилита https://dupecare.com которая делает дедупликацию с компрессией для отдельной папки
Как по мне, в статье очень не хватает краткого сравнения принципов дедупликации. Уж слишком удивляет такая разница в результатах. Может, где-то надо настройки подкрутить, или ещё что-то. Очень подозрительно.
Также любопытно, насколько дедупликация замедляет доступ к файлам. Но тут всё очень от железа должно зависеть, поэтому чужой эксперимент - не показатель.
Для сравнения алгоритмов дедупликации пришлось бы провести полноценное исследование, включая сорсы zfs/btrfs bees, для подобной статьи потребуется затратить около 2х месяцев по вечерам и выходным, в данный момент я к сожалению не располагаю таким ресурсом.
Да и в целом мне хотелось сравнить и показать "а чё там из коробки доступно?"
Большинство пользователей или ИТ специалистов не хотят тратить дни и недели на допиливание кода и сборку на арчах под свои нужды.
Но в целом соглашусь что было бы интересно сделать прям научную статью со сравнением алгоритмов и разбором на разных дата сетах.
С этим — легко помочь, научное исследование тут не нужно.
Начнем с базы.
Любое хранилище с рандомным доступом способно адресовать сырое пространство ровно одном способом: разбивая его на блоки. Соответственно, любой алгоритм любой постобработки — шифрование, сжатие, дедупликация — не сможет оперивать произвольными смещениями и длинами: они всегда будут кратны базовому блоку хранилища. То есть, дедупликация на хранилище всегда блочная.
Далее, сам поиск одинаковых блоков, тут вариантов совсем немного:
- поиск по полному совпадению (медленно)
- поиск по хешу (очевидно, тут все отличия будут в хеш-функции)
- поиск по хешу И проверка на полное совпадение (можно форсировать в ZFS)
Интерфейс доступа к хралищу (ФС) может оперировать как базовыми блоками так и цепочками блоков (экстентами, рекордами, etc).
Архив, в отличие от, можно рассматривать как поток обработанных (или нет) данных, разделенных промежутками с метаданными самого архива — оглавлением, таблицой смещений, словарем и т.д., где минимальное смещение/длина данных принципиально снизу не ограничены (обычно кратны байту или машинному слову).
Соответственно:
- смещение файла внутри архива не обязано совпадать с началом блока хранилища
- последовательность блоков контента внутри архива может иметь разные по величине гапы
Из чего есть два следствия:
- на хранилище соседние архивы могут лечь совершенно разными последовательностями байт — как следствие, дедуплицировать там будет нечего, блоки будут уникальными
- при определенных условиях (архив не сильно меняющегося набора файлов в формате, хранящем сильно меняющиеся части в конце архива) можно будет получить достаточно пригодный для дедупликации архив. При этом эффективность дедупликации будет зависеть от размера блока (что и показало ваше тестирование, у NTFS размер блока — 4кБ по дефолту)
Если вы хотите получить высокий коэффициент дедупликации — ваши данные должны быть к ней пригодны. Это значит:
- или сырые, без контейнеров (архивов), файлы
- или вам нужен специальный формат контейнера, который вы можете подтюнить под особенности хранилища (вроде уже упомянутого pxar)
- или (если вы дедуплицируете ФС) размеры экстентов/рекодов/etc дочерних ФС должны соответсвовать размеру блока хранилища
Очень странные результаты для btrfs, скорее всего не хватило свободного места на диске и дедупликация отвалилась. Некоторые соображения:
Дедупликация в bees всегда происходит одновременно со сжатием и по умолчанию это тормознутый zlib, поэтому и проц жрёт, compress=lzo опция монтирования в помощь
В комплекте с bees уже есть systemd unit
Можно также попробовать duperemove + xfs
По графикам zabbix видно что место не заканчивалось.
Получилось как есть, ничего не менял, не правил.
Btrfs такая хитрая штука, что место есть, а операции записи легко могут вернуть ошибку. Жаль нет исходных данных для тестирования...
Я недавно диск 2 тб с данными 1 тб сконвертировал в btrfs и он уменьшался только до 1.5 тб, пока я не вырубил дублирование метаданных. Balance и прочая запись писали нет места, а в usage было свободно минимум 170 гб.
Немного не про файловые системы, но про дедубликацию данных.
Самая мощная дедупликация есть у архиватора FreeArc, причём не из коробки, а с препроцессорами rep и xtor.
Например я использую добавленную опцию в arc.ini
[Compression methods]
91 = rep:2gb:112:c64:d4m:s64+xtor:3:4m:h32k / $text=ex1b
или ещё более быстрый вариант
81f = rep:1gb:512:c512+xtor:3:4m:h4k
Жаль таких скоростей и сильных степеней сжатия в файловых системах пока нет.
Вся мощь Freearc в том, что для разных типов данных можно указать свой метод упаковки, даже самый экзотичный. Например PackJpg для jpg, Packmp3 для mp3, для Sony Raw .arw - PackRAW. Вообщем выбрать по своему желанию на https://www.squeezechart.com/
Dedup Windows vs Linux, MS снова “удивит”?