> Консистентный набор блоков != консистентное состояние файлов с точки зрения софта.

Видишь ли, традиционно софт в Unix работает с файлами, сокетами, каналами (pipe). И на нормальных классических ФС dump/restrore сохраняют/восстанавливают на бэкапный/новый носитель их в том же виде, в котором их ожидают увидеть Unix-программы, которые с ними работают непосредственно.

В ZFS аналог такого механизма — send/receive.

> Человеков по идее интересует консистентный набор файлов в бэкапе.

И это тоже в том числе.

> Т.е. некое состояние, которое можно раскатать и чтобы это потом еще и работало, желательно без спецэффектов.

Похоже, на неотмонтированной Ext4, в отличие от XFS и UFS2, не может работать dump/restore без "спецэффектов" (если вообще может).

>  А вот тут возможны варианты.

dd, например. Вам больше ничего не остаётся, похоже, для переноса ФС точь-в-точь на новый носитель, с последующим обязательным fsck.

> Бэкап "на горячую" подхватывает файлы в состоянии "как есть" и это весьма зависит от логики работы программ. Никаких гарантий что для произвольной софтины такой набор файлов будет рабочим - нет!

Я вам не предлагаю делать dd RAW-носителя живой СУБД — ничего, кроме лапши, вы не получите от этого. СУБД должна иметь собственные механизмы бэкапа с учётом запуска/остановки своих транзакций.

Конкретно в POSIX/Unix для ЗРЕЛЫХ файловых системы разработан и действует стандартный механизм бэкапа метаданных, файлов, сокетов, каналов — утилиты dump/restore. А что-то другое — это именно что-то другое, которое работает на тех ФС, которые не поддерживают dump/restore, например, это FAT32.