>> Покривляетесь ещё или хоть немножко стыдно стало?
> Михаил, и Вы после этого "стыдно" вместо полного анализа технических аргументов

Каких-каких аргументов?!  В сообщении, на которое я отвечал, их просто нет.

А за _полный_ анализ вопроса применимости dump/restore во FreeBSD и Linux (если Вы его имели в виду) могу при необходимости выставить Вам счёт -- поскольку придётся привлекать наших ядерщиков и системщиков как минимум.

> будете еще что-то заявлять о гордыне?

Вадим, мне бы за то, что спорол некто откомментированный, действительно было стыдно.  Чтоб Вам было понятно -- _естественно_, я _не_ свободен от гордыни.  За себя стыдно в части резкости, но предпочитаю сказать в лоб, что человек дурь сказал, чем поморгать глазками, поулыбаться и показать кукиш в кармане.

> Эти самые "средства другого уровня" весьма долго не умели полностью сохранять
> структуру FS

1) или у Вас оригинальное определение структуры ФС, или это не так;
2) зачем? (если мне нужен образ блокдевайса с отмонтированной или ro-ФС, его сделает dd; образ блокдевайса с rw ФС мне до сих пор нужен не бывал IIRC)

> (скажем, тех же файлов с дырками)

Я уже забыл, когда --sparse сделали в rsync (хотя багфиксы corner case'ов были и не так давно, e.g. в 3.0.8); в GNU tar поддержка sparse files была, когда я с ним столкнулся.

> а заявлять о костылях

Давайте уточним: я сказал, что согласен с тем, что dump и restore, которые ходят к блокдевайсу мимо драйвера ФС -- костыли (и против unix way, btw).

> при необходимости тех же инкрементальных обвязок

Если это было о надстройках над тем же rsync -- то лукавите: это как раз unix way.

Если нет -- то задача распределённого бэкапа (которая востребована) обычно решается с применением реализации инкрементального или инкрементально-дифференциального бэкапа для обеспечения разумного баланса периода, оперативности и стоимости резервных копий.  И не решается разумно в пределах локальной ФС.  Это так удивляет?

> и умалчивании об уже давно реализованном доступе к снапшотам вместо живой FS -
> по меньшей мере, демагогично.

Позвольте поинтересоваться, используете ли Вы эту реализацию в своей практике в сколь-нибудь существенной мере или же именно что демагогию разводите?  У меня давным-давно были под рукой снапшоты в XFS и LVM, но я ими попросту не пользовался (в отличие от иных коллег) -- не требовалось.  И соответственно не носился с ними, как дурак с торбой.

RAID, снапшоты, бэкап, rsync, bacula, диски, ленты, охрана периметра -- друг друга не заменяют, а дополняют.  У них разные плюсы, минусы и зоны применимости.  Местами перекрывающиеся.

> Как и игнорирование того факта, что развитием идеи dump/restore в
> "правильном ключе" является zfs send/receive

С этим незнаком, потому обсуждать не могу.

> а не отказ от подобного способа решения целиком в пользу
> изначально предназначенных для слегка других целей утилит.

По смыслу их предназначение такое же -- копирование информации; по реализации -- да, другое, только IMHO не "слегка", а существенно.  Вы о чём?

Dump was a stupid program in the first place. Leave it behind.
  -- Linus Torvalds (http://lwn.net/2001/0503/a/lt-dump.php3)