>[оверквотинг удален]
> Что опенсорсные, что всякие монстрики от всяких проприерасов типа симантека. Если
> надо нечто крутое, типа горячего бэкапа БД без остановки сервиса, и
> чтобы база при этом еще и консистентрая была - у баз
> обычно есть какие-то свои интерфейсы для таких вещей. Без влезания в
> специфику ты все-равно корректно бэкапать базы "онлайн" не сможешь. Ну то-есть
> ты можешь попытаться, но когда ты заметишь что бэкап неконсистентный и
> с тебя снимут стружку за факапнутую базу - ты сам себе
> баклан.
>> главное, однообразно и очевидным образом.
> Одной большой кнопкой "сделайте мне за...сь"?Для любой файловой системы в терминах операционной системы — ДА!
> Мечтать не вредно.
Почему нет, если любая файловая система для пользователя выглядит однообразно благодаря механизму монтирования и POSIX-операциям с ней?
>[оверквотинг удален]
> при минимальном понимании семантики работы с файлами ты можешь вдруг внезапно
> осознать пару простых истин.
> 1) Софт может менять файлы во время бэкапа, если ты живую систему
> бэкапишь в rw.
> 1.1) Следствие: отнюдь не факт, что софт будет счастлив получить половину старых
> и половину новых файлов, которые в таком бэкапе образовались.
> 1.2) Борьба с этим явлением - отдельное приключение. Можно в принципе заморозить
> запись на ФС и бэкапать без помех. Но I/O на некоторое
> время встанет колом, это уже "не совсем онлайновый" бэкап и не
> совсем rw, в общем нишевая хрень для специальных случаев.
Что мешает остановить софт, который меняет файлы?
> 2) А с чего ты взял что софт вообще в курсе что
> его файлы бэкапают? И кто сказал что "сию секунду" файлы у
> этого софта вообще были в консистентном состоянии на диске? Кто это
> гарантировал и как это было обеспечено? Глобального общесистемного сигнала "чуваки, мы
> тут ща все бэкапать будем, а ну все дружненько приведите свои
> файлы в консистентное состояние и не трогайте следующие 5 минут!" -
> нету!
Открой для себя Single User Mode. Или у вас оно давно не работает? Ну тогда прибивай процессы, которые активно пишут в бэкапируемую ФС, чтобы действительно получить консистентный бэкап данных (не файлов — файлы и так будут консистентны в dump/restore, ничего не пропадёт).
Ещё один способ: отмонтировать ФС и снимать данные dd — линуксоиды так обычно поступают, не зная вообще про dump/restore. Когда им рассказываешь, что некоторые классические ФС *nix поддерживают dump/restore вместо посекторного снятия информации с носителя, внезапно удивляются такой возможности.
> Для софта где это реально критично и чревато факапами, типа
> СУБД - лепят отдельные интерфейсы, специфичные для такого софта. В таких
> случаях придется RTFMать весьма отдельно как оно у них сделано и
> кто умеет все это использовать в человеческом виде.
Бэкапить сложные СУБД — не входит в свойства файловой системы, так как ФС ничего не знает о структуре баз и не умеет управлять метаинформацией и запущенными транзакциями СУБД. Это "внутриконтейнерная" задача — задача самой СУБД, которая тоже, в свою очередь, может и не иметь никакого понятия о ФС, располагаться на RAW-томе.
Задача администратора разграничивать области ответственности механизмов хранения и управления данными:
- ФС должна заботиться о целостности и консистентности собственной метаинформации и файлах;
- dump/restore должны работать с ФС, не делая из неё лапши;
- СУБД должна обеспечить сохранность собственных данных и данных пользователей, которые под её управлением;
- вообще, пользовательские процессы ответственны за данные пользователя, с которыми они работают, независимо от того, какой носитель они используют.
>> А сейчас ты как делаешь бэкапы корневой ФС?
> Например, tar'ом иногда бэкаплю нужные диры оттуда.
dump/restore не исключают использование tar, даже используют в процессе бэкапа ФС на ленточные носители и в файлы.
