>> Одной большой кнопкой "сделайте мне за...сь"?
> Для любой файловой системы в терминах операционной системы — ДА!

Ну, мечтай. Даже крЮтые коммерческие решения обычно подразумевают что за монитором компетентный в своей области человек, понимающий как бэкапать/ресторить и какие проблемы могут быть.

> Почему нет, если любая файловая система для пользователя выглядит однообразно благодаря
> механизму монтирования и POSIX-операциям с ней?

Потому что нет никакого универсального механизма информирования софта на горячую что "а сейчас мы будем тебя бэкапать, приведи-ка свои файлы в консистентное состояние, с которым ты потом точно сможешь работать, и ничего не трогай до зеленого свистка вверх". Проводя бэкап RW файловой системы с работающим софтом этот момент следует четко понимать.

> Что мешает остановить софт, который меняет файлы?

А тут мы приближаемся к оффлайновому бэкапу/RO, только сами педалируем корректность состояния файлов на свой страх и риск. В смысле, прерывание сервиса - имеет место быть. Значит бэкап уже не онлайновый. И одной кнопки уже не получается. Получается что надо более-менее компетентного "оператора бэкапов", который убедится в корректности бэкапа наиболее ценных вещей. Понимая как подшефный софт работает и как его сбэкапать корректно. Ну это я про нормальный энтерпрайз, а не твою супер-инсталляцию о трех ноутбучных дисках в ZFS пуле.

> Открой для себя Single User Mode.

С таким успехом можно и в r/o монтировать и не париться - так уж точно никто не запишет. Ни 1 юзер, ни много юзеров. Только вот прерывание сервиса имеет место быть.

> Или у вас оно давно не работает? Ну тогда прибивай процессы, которые активно
> пишут в бэкапируемую ФС, чтобы действительно получить консистентный бэкап данных

Иногда как-то так и приходится делать. Ну вот например, есть виртуалка. С диском-в-файле. Как бы удачи сбэкапать во время работы виртуалки диск-в-файле в консистентном виде. У него понятие консистентности - очень сложный вопрос. Даже если прямо сейчас host записал все что хотела VM на диск, у VM может быть кэш в памяти. И то что она через минуту захочет его скинуть на диск - мы про это не знаем. Даже если мы заморозим I/O поставив виртуалку на паузу, это предотвратит лишь изменение файла прямо во время копирования, но еще вовсе не означает что ФС внутри этого файла была в консистентном состоянии по мнению guest OS. Ну как, ты еще хочешь поговорить о консистентности данных при горячем бэкапировании? Ну попробуй.

> (не файлов — файлы и так будут консистентны в dump/restore, ничего не пропадёт).

Угу, щаз. Вон я тебе пример с виртуалкой и диском-в-файле привел. Попробуй диск-в-файле таким макаром корректно сбэкапать, не останавливая виртуалку. Не забудь доложить как получилось :).

> Ещё один способ: отмонтировать ФС и снимать данные dd

Можно просто ремоунт в ридонли, если уж на то пошло. Вот только поблочный бэкап носителя - штука нишевая, нужная в сильно некоторых случаях. Без специальных приседаний это к тому же нерационально расходует место на бэкапном носителе.

> — линуксоиды так обычно поступают, не зная вообще про dump/restore.
> Когда им рассказываешь, что  некоторые классические ФС *nix поддерживают
> dump/restore вместо посекторного снятия информации с носителя,
> внезапно удивляются такой возможности.

Я скорее удивляюсь тому что изя пытаетсся меня удивить "крутыми фичами", при том тушуясь объяснить чего такого крутого и необычного в этих фичах есть, собственно :). Впрочем, это же изя...

> Бэкапить сложные СУБД — не входит в свойства файловой системы, так как
> ФС ничего не знает о структуре баз и не умеет управлять
> метаинформацией и запущенными транзакциями СУБД.

Более того - ФС ничего не знает о формате файлов и логике работы и всех остальных программ. Прикинь, какая подстава?! А кто вообще гарантирует что в произвольно взятый момент времени содержимое файла вообще осмысленное? Для программ которые не запущены это еще можно предположить, из соображений что они как-то намеревались стартовать с этим набором данных. А в остальных случаях...

> Это "внутриконтейнерная" задача — задача самой СУБД, которая тоже,
> в свою очередь, может и не иметь никакого понятия о ФС, располагаться на RAW-томе.

Самое забавное что такие рассуждения можно применить к практически всем программам.

> - ФС должна заботиться о целостности и консистентности собственной метаинформации и файлах;

В этом месте даже изя начинает догадываться, что консистентность ФС, ее метаданных и блоков данных ... ничего не говорит о консистентности данных в файлах. Хе-хе.

> - dump/restore должны работать с ФС, не делая из неё лапши;

Что ты к ним привязался? И кому должны? Они что-то у кого-то занимали? Или чего?

> работают, независимо от того, какой носитель они используют.

Ясен перец. Поэтому в общем случае бэкап на горячую требует понимания чего бэкапается и насколько это будет (не)консистентным. Вон я тебе пример с диском виртуалки привел. Это не база. Но это не значит что ты его сбэкапаешь на горячую корректно.

> dump/restore не исключают использование tar, даже используют в процессе бэкапа ФС на
> ленточные носители и в файлы.

Честно говоря я просто не понимаю что ты хочешь достичь используя dump/restore и почему для этого надо использовать именно их. А бэкапаются на ленты нынче в основном махровые энтерпрайзники, которые могут потратить туеву хучу денег на современный стример и кассеты к нему. Остальным проще на жесткие диски бэкапаться по моим наблюдениям. Так что tar давно уже не только про "tape".