btrfs - мнимое «Не осталось свободного места»

я не использую фс со снепшотами за неимением таковой.

вопрос странный. многие бд хорошо восстанавливаются после сбоя в виде внезапной остановки машины/отключения света. sqlite и postgres в их числе. но бд нужно бекапить встроенными средствами.

Судя по тому, сколько народа знает про btrfs balance, будет примерно одинаково. :)

Странно, а я всю жизнь думал, что «ручное» обслуживание — это когда надо всё время это обслуживание делать вручную. Ну там, команды в консоль писать, вот это вот всё.

Поставить один пакет (который в OpenSuSE вообще из коробки идёт, ЕМНИП) и забыть — насколько «ручное» обслуживание?

То, что восстанавливаются - не значит, что бэкап будет консистентным. Кроме того, это всего лишь пример. Снепшоты ФС вообще как бэкап годятся слабо на чуть более-менее серьезных задачах, да и цели у них несколько другие. Это всего лишь еще один слой защиты от собственных кривых рук, хотя использование этого слоя требует некоторых дополнительных знаний. А вот то, как это преподносят многие адепты подобных ФС - печально. На самом деле, снепшоты не отменяют необходимости классического бэкапа. Типа рейд - не бэкап, а снепшоты - еще более страшная штука, чем рейд.

я согласен, да, оно автоматическое, я неправильно выразился.

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

инодов конечно же не хватает!!

CoW, snapshots, менять raid на лету - это все дикие фичи.

То, что восстанавливаются - не значит, что бэкап будет консистентным.

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

Ты долго будешь позориться? эту тему про бд снепшоты начал ты, но я тебе ответил как оно есть на самом деле, даже посоветовал тебе, что лучше конечно другим путем это делать.

я (внимание, я не говорил про БД!!! ничего тут):

позволяет днем, фоново снять crash-consistеnt бекап

ты (откуда-то друг БД, в контексте снепшотов btrfs):

И чо, БД бекапит без поломок?

я:

вопрос странный. многие бд хорошо восстанавливаются после сбоя в виде внезапной остановки машины/отключения света. sqlite и postgres в их числе. но бд нужно бекапить встроенными средствами.

еще раз, две конкретные названные мной БД нормально консистентно восстановятся из crash-consistent бекапов. и я тебе сразу сказал это будет нормально работать, но лучше импользовать средства БД конечно. про другие БД я не знаю, я изначально сказал именно про postgres и sqlite

короче обосрался ты эпично.

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

за консистентность бэкапах выдают крэш-консистентное состояние

Эй-эй-эй, ты оборзел? Я такого не говорил.

Тут «консистентный бэкап» == «крэш-консистентное», потому что на _работающей_ машине для _всей ФС_ и _произвольных_ программ ты что-то больше не получишь, я надеюсь это очевидно. (для отдельных я уже сказал, что бд есть процедура). Так вот с этого к.-к. снимка и снимается к.-к. бекап (снимается со снимка, да), если ты еще не понял.

Использовал бы зиэфэс и не мучался.

У btrfs не используются иноды. :)

То, что восстанавливаются - не значит, что бэкап будет консистентным.

Что ты вообще понимаешь под «консистентностью» бэкапа?

Снапшот по определению атомарный, иначе в них не было бы смысла. Снятие снапшота равносильно принудительной остановке ОС. Все дальнейшие вопросы — к приложению, которое там крутится (если ты хочешь сказать, что твоя БД не crash-proof, тебе нужно менять БД, а не жаловаться на снапшоты).

<снапшот — не бэкап>

Unless it is.

Ты ведь понимаешь, да, что без модели угрозы этот разговор не имеет смысла? Если ты Гугл и твоя модель угрозы — это пожар в датацентре или природный катаклизм, то тебе нужен не просто бэкап, а офф-сайт бэкап в нескольких локациях и потенциально на нескольких континентах. А если ты обычный десктопный юзер и твоя модель угрозы — это собственные кривые руки, то снапшот — это вполне себе бэкап.

если ты хочешь сказать, что твоя БД не crash-proof, тебе нужно менять БД, а не жаловаться на снапшоты

То есть, по твоему мнению, не корректное завершение приложения не должно приводить к сбоям? Окей. Мне просто интересно, сколько народу предпочитают терять данные. Снапшот он должен производиться при отсутствии активной работы с диском и все приложения должны записать данные, именно это я хочу сказать.

То есть, по твоему мнению, не корректное завершение приложения не должно приводить к сбоям?

Безусловно.

Мне просто интересно, сколько народу предпочитают терять данные.

Слушай, вылезай уже из криокамеры. ACID в начале 80-х придумали.

Снапшот он должен производиться при отсутствии активной работы с диском и все приложения должны записать данные

У большинства людей всё-таки принято выбирать инструмент под задачу, а не задачу под инструмент.

Переходи на xfs, у нас тоже есть рефлинки и онлайн-дефрагментация :)

снапшоты мне нужны

LVM

снапшоты

LVM

Это те самые, которые тихо превращаются в тыкву, если под них выделить недостаточно места?

если ты хочешь сказать, что твоя БД не crash-proof, тебе нужно менять БД, а не жаловаться на снапшоты

Любая БД крэшниться рано или поздно от хард ребута.
В остальном вы все верно написали.

Это те самые, которые тихо превращаются в тыкву, если выделить недостаточно места?

Это вы про тонкие? Их использование до сих пор сомнительно.

Это вы про тонкие?

Нет, это я про обычные. Про тонкие я первый раз слышу.

Их использование до сих пор сомнительно.

А что с ними не так? Они звучат как решение проблемы, которую я имел в виду.

Нет, это я про обычные. Про тонкие я первый раз слышу.

Хм. И что тогда с «которые тихо превращаются в тыкву, если под них выделить недостаточно места?» Вроде все робит. Недостаток только падение производительности.

А что с ними не так? Они звучат как решение проблемы, которую я имел в виду.

Отдельные разделы под метаданные и под данные. Вот на нем как раз можно получить проблему «выделить недостаточно места»

И что тогда с «которые тихо превращаются в тыкву, если под них выделить недостаточно места?»

Я вот про это (LVM-HOWTO):

# lvcreate -L592M -s -n dbbackup /dev/ops/databases 
lvcreate -- WARNING: the snapshot must be disabled if it gets full

Full snapshot are automatically disabled

If the snapshot logical volume becomes full it will be dropped (become unusable) so it is vitally important to allocate enough space. The amount of space necessary is dependent on the usage of the snapshot, so there is no set recipe to follow for this. If the snapshot size equals the origin size, it will never overflow.

Если в примере выше записать на databases более чем 592M данных, то dbbackup по-тихому превратится в тыкву. Или уже нет?

В целом хз, до таких извращений не добирался.

В смысле «извращений»? Приведён пример стандартного использования снапшотов LVM. А что тогда не «извращение»?

В смысле место есть. )

из удаленных

Да, народ, если мне кто покажет строчку в документации, где написано, что SQLite и Postgres 100% восстанавливаются после сбоя по питанию без проблем - дайте ссыль, а то я этого умалишенного в игнор отправил.

Умалишенный у нас похоже ты.

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

sqlite

An SQLite database is highly resistant to corruption. If an application crash, or an operating-system crash, or even a power failure occurs in the middle of a transaction, the partially written transaction should be automatically rolled back the next time the database file is accessed. The recovery process is fully automatic and does not require any action on the part of the user or the application.

All changes within a single transaction in SQLite either occur completely or not at all, even if the act of writing the change out to the disk is interrupted by a program crash, an operating system crash, or a power failure. The claim of the previous paragraph is extensively checked in the SQLite regression test suite using a special test harness that simulates the effects on a database file of operating system crashes and power failures.

postgresql

Reliability is an important property of any serious database system, and PostgreSQL does everything possible to guarantee reliable operation. One aspect of reliable operation is that all data recorded by a committed transaction should be stored in a nonvolatile area that is safe from power loss, operating system failure, and hardware failure (except failure of the nonvolatile area itself, of course).

An alternative file-system backup approach is to make a “consistent snapshot” of the data directory, if the file system supports that functionality (and you are willing to trust that it is implemented correctly). The typical procedure is to make a “frozen snapshot” of the volume containing the database, then copy the whole data directory (not just parts, see above) from the snapshot to a backup device, then release the frozen snapshot. This will work even while the database server is running. However, a backup created in this way saves the database files in a state as if the database server was not properly shut down; therefore, when you start the database server on the backed-up data, it will think the previous server instance crashed and will replay the WAL log. This is not a problem; just be aware of it (and be sure to include the WAL files in your backup).

из удаленных

Каковы шансы повреждения таблиц в MyISAM

майкрософта их ShadowCopy ломает к чертям MSSQL и SHarePoint

Причем тут mysql/myisam и mssql? Я же изначально сказал: некоторые базы данных, в их числе sqlite и postgresql. Учись быть внимательным, если тебе еще не поздно.

Кроме того, зачем ты вообще бекапишь БД таким образом? Любая БД бекапится встроенной в нее процедурой. В sqlite и postgreqsl они есть (в mysql тоде). Осиль уже их наконец, там ничего сложного.

И ещё docker не работает. (если специальные опции при форматировании не указать)

Превратится. Но в lvm давно завезли тонкие тома, у которых снапшоты не ломаются, и не тормозят так дико. Но их тоже, при определенном положении звезд, можно сломать.

LVM в отличии от btrfs ничего не знает про writeback данные, они не попадут в снапшот.

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

большинства людей всё-таки принято выбирать инструмент под задачу

И у большинства нормальных людей принято называть вещи своими именами. Снепшот не бэкап. Точка.

Ты полностью расписался в своей некомпетентности. Показал, что не понимаешь о чем говоришь, не знаешь значений простых терминов. Каким еще тоном можно с тобой разговаривать? Ты должен сначала принести мне извинения за свою хамскую некомпетентность, а потом самозабаниться.

Ты мне сейчас пытаешься сказать то, что я и так знаю.

ну-ну.

Снапшот он должен производиться при отсутствии активной работы с диском и все приложения должны записать данные, именно это я хочу сказать

Хотел уточнить, я правильно понимаю, что ты имеешь ввиду, что перед тем как запросить btrfs-снапшот по-твоему нужно остановить postgresql и завершить другие программы? И только после этого, ты хочешь скачать, уже снимать со снепшота бекап?

Хотя бы. Но, чтоб ты знал, иногда нельзя делать бинарный бэкап. Т.е. если у тебя там не файлопомойка - существуют ситуации, когда твой бэкап окажется тыквой, так как целостность данных (а это одно из базовых понятий) всё равно будет нарушена. Да даже если и файлопомойка - если с файлом происходит работа в момент снятия снепшота - есть не нулевая вероятность, что этот файл окажется тыквой или нулевого размера, ага.

Снепшот не бэкап.

Что-что? Откуда ты это взял?

Путаешь снепшот с бекапом тут только ты. (Видимо из-за того, что до сих пор не можешь освоить штатные дампы своей БД).

Хотел уточнить, я правильно понимаю, что ты имеешь ввиду, что перед тем как запросить btrfs-снапшот по-твоему нужно остановить postgresql и завершить другие программы? И только после этого, ты хочешь скачать, уже снимать со снепшота бекап?

Хотя бы.

Рукалицо.жпг. Если ты остановил postgresql и завершил другие программы, то никакой снепшот вообще тут не ненужен, т.к. снимать бекап базы и файлов теперь можно непосредственно с файловой системы, а не со снепшота. Ты окончательно «загнался».

Но, чтоб ты знал

Ты не можешь мне ничего сообщить. Т.к. ты не понимаешь элементарных основ, не знаешь что такое бекапы, консистентность, креш-консистентный, не знаешь как работают базы данных и как с ними обращаться, Не знаешь что такое снепшоты и зачем они нужны. И заметь, я не сисадмин, а программист, и снепшот-капабельную ФС никогда не использовал, т.к. мне это не особенно нужно. Но я и то больше тебя понимаю. Ну и позорник же ты. Как ты можешь мне хамить если ты чайник? Как ты можешь настаивать на чем-то что откровенная чушь? Я за бан.

исправление «снепшот вообще тут не нужен»

если с файлом происходит работа в момент снятия снепшота - есть не нулевая вероятность, что этот файл окажется

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

то никакой снепшот вообще тут не ненужен, т.к. снимать бекап базы и файлов теперь можно непосредственно с файловой системы, а не со снепшота

Делаем снепшот и запускаем софт обратно. И уже снимаем бэкап со снепшота, а софт продолжает работать.

я не сисадмин, а программист, и снепшот-капабельную ФС никогда не использовал, т.к. мне это не особенно нужно

Ну и чего ты распинаешься? Некомпетентен - притуши пукан, смени стул и хватит уже петушиться.

Я

Ты никто и ничто. И звать тебя никак. Устал я от того, что ты кроме очередного возвышения себя не можешь ничего сказать по делу, постоянно поворачивая свой флюгер. Ты жиденько обкакался, привёл документацию, которая в общем-то не содержит того, что я просил, высрал тонну гавна и больше ничего не смог. Незачем с тобой больше разговаривать. Даже понятия не имеешь, со специалистом какого уровня ты разговариваешь.

Ты жиденько обкакался, привёл документацию, которая в общем-то не содержит того, что я просил

Т.е. ты даже не смог понять, что там написано? Печально. Именно это она и содержит. Буква в букву. Я привел эти абзацы документации из жалости к тебе, чтобы ты хоть понял, что существует еще целый мир базовых вещей о которых ты как выяснилось даже приблизительного представления не имеешь. Но, похоже, заниматься просвещением таких как ты это неблагодарное дело.

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

ну-ну.

позволяет днем, фоново снять crash-consistеnt бекап

Woolf:

И чо, БД бекапит без поломок?

Woolf:

Делаем снепшот и запускаем софт обратно. И уже снимаем бэкап со снепшота, а софт продолжает работать.

Ахахах, так зачем же весь этот бред с остановкой БД, если во-первых названные мной БД нормально восстановятся* из бекапа снятого с креш-консистентного снепшота без всяких остановок? Во-вторых зачем тебе вообще эта идея с БД и снепшотами, тем более с остановкой, если в нормальной базах данных есть нормальные механизмы бекапа? Хамил, выпендривался, а потом сам себя уже загнал в угол, вот клоун!

* - о чем ты у упорно не догадываешься, даже после того, как я тебя ткнул мордой в документацию, которую ты так требовал будучи, конечно, уверенным что ее не существует.

Можно и бекапы делать. Даже инкрементальные. Тоже очень удобно в BTRFS это делается

btrfs send /path/to/subvolume > /path/to/bakup.btrfs

И заметь, я не сисадмин, а программист

Если вы не «поргамист php» то тем более должны понимать, что при спапшоте fs как ее не готовь, получить битые данные вполне возможно. Все зависит от конкретных случаев.

ЗЫ Напомнили старую историю, когда-то давно в сшп-ных абрамсах в кач-ве субд была выбрана interbase как самая устойчивая в хард перезагрузке (ЭМИ удар). У нас она тоже использовалась на объектах (считайте тоже некий вариант эмбедет), так юзеры регулярно ребутающие по питалову достаточно «уверено», хоть и не часто, приводили ее к смерти. Сама БД мелкая, мельче некуда, дикая активность на запись бывает редко и то мелкими транзакциями.

должны понимать, что при спапшоте fs как ее не готовь, получить битые данные вполне возможно. Все зависит от конкретных случаев.

Я вас не понял, что значит «битые данные»? Мы исходим из того, что снепшот-механим дает креш-консистентные бекапы, эквивалентные остановке машины, т.е. отключению света или нажатию reset. Т.е. каждый его байт представлен в состоянии на один и тот же момент времени.

«Нюансы» в виде ошибок в снепшот-механиме мы в контексте данной дискуссии выносим за скобки, так же как ошибки контроллеров и жестких дисков, операционной системы, битой памяти и т.д. и т.п. В документации к выше названым мной БД, насколько я помню, делаются аналогичные оговорки. Таким образом, я не очень понимаю, что вы имеете в виду.

Ну и наконец, хоть названые мной БД действительно это умеют, неразумно злоупотреблять этим и считать эту способность абсолютно гарантированной. Кроме того, что я уже раз 5 (включая удаленные сообщения) сказал, что вообще, конечно, бекапить таким способом БД - не лучшая идея, когда в БД доступны специальные механизмы для этого.

Если вы не «поргамист php»

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

Мы исходим из того, что снепшот-механим дает креш-консистентные бекапы, эквивалентные остановке машины, т.е. отключению света или нажатию reset.

«Маша ты за хлебом?» Речь о том что снапшот != бэкап. Вы оспаривали этот момент.
Но выше вы уже сами согласились что это не оно «бекапить таким способом БД - не лучшая идея»
Думаю на этом можно закончить. Все всех поняли.

Речь о том что снапшот != бэкап. Вы оспаривали этот момент.

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

Могу лишь предложить перечитать тред (там есть еще и удаленные) или сделать поиск по фразам «rsync» и «вопрос странный».

btrfs - мнимое «Не осталось свободного места» (комментарий)

btrfs - мнимое «Не осталось свободного места» (комментарий)

btrfs - мнимое «Не осталось свободного места» (комментарий)

btrfs - мнимое «Не осталось свободного места» (комментарий)

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

Ну значит показалось. Сорри.

Тема «снапшот != бэкап» мне вообще кажется дикой. Я вообще не сразу заметил, как она появилась. Этот персонаж сначала вменил ее мне, и потом убедил в этом и себя и невнимательных наблюдателей. Я говорил о том, что btr позволяет (видимо) без остановки работы снять снепшот и фоново далее с него уже снять креш-консистеный бекап (таром, боргом, рсинком в сеть, чем угодно), ни про какие БД я не говорил ( btrfs - мнимое «Не осталось свободного места» (комментарий) ). И далее, внимание, этот кадр сам начал вплетать тему БД и употребил «бекапит» в контексте снепшотов (можете убедиться сами btrfs - мнимое «Не осталось свободного места» (комментарий) ). То есть бекапы и снепшоты на самом деле путает _он_, и именно _он_ завел странную тему про то, чтобы бекапить ими базы данных. Он всё путает, предлагает глупости, но смог как бы поместить меня в этот же профанаторский дискурс удачно сыграв на публику.