>> Покривляетесь ещё или хоть немножко стыдно стало?
> Михаил, и Вы после этого "стыдно" вместо полного анализа технических аргументовКаких-каких аргументов?! В сообщении, на которое я отвечал, их просто нет.
А за _полный_ анализ вопроса применимости 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)