>[оверквотинг удален]
> софтом этот момент следует четко понимать.
>> Что мешает остановить софт, который меняет файлы?
> А тут мы приближаемся к оффлайновому бэкапу/RO, только сами педалируем корректность состояния
> файлов на свой страх и риск. В смысле, прерывание сервиса -
> имеет место быть. Значит бэкап уже не онлайновый. И одной кнопки
> уже не получается. Получается что надо более-менее компетентного "оператора бэкапов",
> который убедится в корректности бэкапа наиболее ценных вещей. Понимая как подшефный
> софт работает и как его сбэкапать корректно. Ну это я про
> нормальный энтерпрайз, а не твою супер-инсталляцию о трех ноутбучных дисках в
> ZFS пуле.Ну, не знаю. Лично у меня Запущенный Firefox с X'ами не крашатся, когдя я их перекомпилирую и обновляю используя для этого терминал Xfce. При этом идёт вполне реальная подмена занятых/работающих файлов приложений на их новые версии. ;)
>> Открой для себя Single User Mode.
> С таким успехом можно и в r/o монтировать и не париться -
> так уж точно никто не запишет. Ни 1 юзер, ни много
> юзеров. Только вот прерывание сервиса имеет место быть.
Хомячку открыли глазки и показали, а ему этого не надо, так как достаточно rsync и dd (и tar) в большинстве его невыразительных случаях. Ничего — линукс можно ведь просто переустановить — хуже точно не будет!
> Ну вот например, есть виртуалка. С
> диском-в-файле. Как бы удачи сбэкапать во время работы виртуалки диск-в-файле в
> консистентном виде.
А если электричество вырубится, виртуалке всё, кранты? :))
>> (не файлов — файлы и так будут консистентны в dump/restore, ничего не пропадёт).
> Угу, щаз. Вон я тебе пример с виртуалкой и диском-в-файле привел. Попробуй
> диск-в-файле таким макаром корректно сбэкапать, не останавливая виртуалку. Не забудь доложить
> как получилось :).
Я, как последовательный в своих действиях админ, внутри виртуалки средствами её же утилит сделаю dump/restore её ФС (конечно, если она это поддерживает), файлы дампов заберу из неё. Разрешаешь? Я ж не лазаю с hex-эдитором по файлам СУБД, редактируя неверные с моей точки зрения пользовательские данные. Так и тут. ;)
>> Ещё один способ: отмонтировать ФС и снимать данные dd
> Можно просто ремоунт в ридонли, если уж на то пошло. Вот только
> поблочный бэкап носителя - штука нишевая, нужная в сильно некоторых случаях.
> Без специальных приседаний это к тому же нерационально расходует место на
> бэкапном носителе.
Да, да. Я привёл почти все варианты решения проблем с несуществующим dump/restore на Ext4. Очевидно, лично для тебя ни один из них не имеет смысла, потому как ты даже не задумывался о такой возможности, существующей ШТАТНО в немногих классических (да и новых) ФС, используемых в продакшене даже под Linux. ;)
>> - dump/restore должны работать с ФС, не делая из неё лапши;
> Что ты к ним привязался? И кому должны? Они что-то у кого-то занимали? Или чего?
Речь зашла о крутости Ext4, которая не имеет фич, присущих классическим промышленным ФС.
>> dump/restore не исключают использование tar, даже используют в процессе бэкапа ФС на
>> ленточные носители и в файлы.
> Честно говоря я просто не понимаю что ты хочешь достичь используя dump/restore и почему для этого надо использовать именно их.
Прости пожалуйста. Я всю дорогу талдычу о такой пустяковине, как быстрый, простой и очевидный бэкап файлов и метаинформации ФС стандартными средствами.
> А бэкапаются на ленты нынче в основном махровые энтерпрайзники
Бэкапиться на ленты совсем необязательно. Можно забэкапить дамп файловой системы в файл. Кстати, файлы можно пометить флагом "nodump", если их не нужно включать в дамп — так будет сохраняться только то, что нужно.
> Так что tar давно уже не только про "tape".
tar работает медленнее dump.
