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

?

Почему ты решил, что контейнеры не поддерживают дедупликацию на pbs?

А про дедупликацию речь и не шла

на Rust переходят же

дедуп - прерогатива ФС
это к zfs в данном случае

в данном случае - нет

pbs - инкремент
не перепутали теплое с мягким? )

если вы pbs на zfs развернете и вкл дедуп на пуле - будет дедуп

только так

just be aware that the deduplication is not on the file level, but on a chunk level (for fidx/VM/block device backups, chunk size is static 4MB, for didx/CT/file level/pxar backups, it's dynamically calculacted within certain limits). so an identical file A in two containers can end up being represented as one or more chunks and be deduplicated, or end up in a chunk with file B in one container, and file C in another, and not be deduplicated. so deduplication will work more reliably with snapshots of one source (chances for the chunker to split the input stream into chunks at similar boundaries are higher).

пруф?

именно для pbs

у меня в  pbs работает дедуп без включенного в zfs дедупа

а кстати, там в 2 местах можно дедуп включить, в zfs и в самом pbs

скрины и выхлоп от дедупа покажите

я отстал от жизни )

профит от дедупа в зфс ПЕРЕД вкл дедупа можно рассчитать так

https://habr.com/ru/post/328048/#comment_10208284

Вообще есть прекрасная возможность заранее получить точные цифры — у zdb есть возможность имитации дедупликации:
zdb -S название_пула

На выходе будет Total allocated blocks, перемножив его на 320 байт получим требуемое количество ОЗУ. Также там приводится коэффициент дедупликации.

если оно меньше 2-х - толку от вкл не будет