LINUX.ORG.RU
Форум — General  

Инкрементальный backup BtrFS.

 ,


2

2

Здравствуйте. Вот ссылка https://btrfs.wiki.kernel.org/index.php/Incremental_Backup

Не могу понять следующее. Вот в этом месте: 

btrfs send -p /home/BACKUP /home/BACKUP-new | btrfs receive /backup/home
если я правильно понимаю, «выгружается» разница между двумя снимками, но по факту при выполнении этой команды я не вижу разницу между этим и командой send выполненой ранее из одного снимка.

Вопрос 1:в чём именно заключается эта разница?

Далее автор делает следующее: 

btrfs subvolume delete /home/BACKUP
   mv /home/BACKUP-new /home/BACKUP
   btrfs subvolume delete /backup/home/BACKUP
   mv /backup/home/BACKUP-new /backup/home/BACKUP
тут он удаляет старый снимок и помещает на его место новый, чтобы в дальнейшем использовать его для вычисления разницы. и тоже самое делает с самими данными.

Вопрос 2: для чего делается последние две строки? Ведь если бы на этапе ранее выгружалась лишь разница то возможно было бы правильнее к примеру наложить эти папки друг на друга. Но он просто удаляет 1ый вариант и переименовывает второй, что приводит к мысли что это самодостаточный backup, но в таком случае в чём заключается смысл было делать первый backup и опять таки возвращаемся к вопросу 1.

Вопрос 3: Посмотрел man на btrffs-send, но ясности недобавило. Раскажите про отличие опций -p и -c.

Заранее спасибо.


← Помогите понять прикол с клавиатурой (цифры с нампада не весь софт принимает)
настройка раскладки клавиатуры для X11 →

Отправляется разность, а снапшот и должен быть самодостаточным. Читай как работают снапшоты, CoW, reflink.

anonymous
()
Ответ на: комментарий от anonymous

Для тебя объясню простыми словами. Зачем было делать /backup/home/BACKUP если он просто создался и удалился?

garcol
() автор топика
Ответ на: комментарий от garcol

Для тебя объясню простыми словами.

Для себя объясни.

Зачем было делать /backup/home/BACKUP если он просто создался и удалился?

Замени BACKUP на 2017-02-16, а BACKUP-new — на 2017-02-23.

anonymous
()
Ответ на: комментарий от anonymous

Твой backup-new в данном случае создан только на разнице между снимками. Если же он в себя включает все файлы и является самодостаточным, то к чему эти лишние движения с -p, так же можно было сделать обычную выгрузку из нового снимка как и ранее.

garcol
() автор топика
Ответ на: комментарий от garcol

Он включает в себя разницу. То есть в /backup/home/ получается то же, что в /home: исходный подтом (снапшот) и ещё один с разницей. BACKUP-new содержит рефлинки на блоки данных BACKUP, и если удалить последний, то сами данные никуда не денутся, потому что на них есть ссылки. Проще говоря, BACKUP и BACKUP-new содержат рефлинки на общие для обоих блоки и на уникальные для каждого. Наверно проще попробовать :)

anonymous
()
Ответ на: комментарий от anonymous

В том то и дело что я пробую.

Я не вижу в твоих последних словах объяснения тому зачем выполнять эту операцию с --parent. У меня закрадывается сомнение что возможно я с ZFS путаю схему и тут немного иначе. Вот в твоём последнем сообщении не понятно о снимке ли ты говоришь или о backup. Если о backup, то ссылки то и в самом снимке хранятся к чему тогда send вообще?

Автор неудобные имена выбрал. И пример немного не такой. Давай немного видоизменим и приведём к такому виду: 

btrfs send -p /home/BACKUP /home/BACKUP-new > dump.file

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

btrfs send /home/BACKUP-new > dump.file

garcol
() автор топика
Ответ на: комментарий от garcol

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

anonymous
()
Ответ на: комментарий от anonymous

то есть ты уверен что если сначала сделать

btrfs send /home/BACKUP > dump.file

а затем 

btrfs send -p /home/BACKUP /home/BACKUP-new > dump.file

То он допишет файл, а не перезапишет новым?

garcol
() автор топика
Ответ на: комментарий от Pinkbyte

мне тут трудно спорить т.к. я действительно не гуру и уровень ваших знаний мне не известен, но >> допишет файл на сколько я знаю в конецe. Вы оба уверены что дописывание определённых данных должно происходить именно в конец файла, а не может быть необходимо изменение их в начале или в середине?

Думаю чтобы не гадать, можно просто посмотреть на это со стороны опции -f. 

btrfs send -f dump.file -p /home/BACKUP /home/BACKUP-new

Что в этом случае?

garcol
() автор топика
Ответ на: комментарий от garcol

Анонимус поправил тебя, т.к. ты говорил о дописывании файла и упоминал оператор >, что в корне не верно - он ничего не допишет.

Речь тут не о btrfs, а о основах операторов в шелле.

Pinkbyte ★★★★★
()
Ответ на: комментарий от Pinkbyte

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

garcol
() автор топика
Ответ на: комментарий от garcol

Каким образом это относится к теме?

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

Серьезно, что сложного в данной схеме differential-бэкапа?

Грубо говоря берется diff на блочном уровне из карты блоков и пересылается в файл/через пайп куда угодно. Низкоуровневые подробности - в исходниках btrfs.

Ответ на вопрос 2 еще более простой - один блок в CoW системе может принадлежать нескольким subvolume. И он будет окончательно удален только, когда количество ссылок на него станет равно нулю(например будут удалены все subvolume, имеющие ссылки на этот блок).

что приводит к мысли что это самодостаточный backup

В общем случае так оно и есть, если ты делаешь полный, а не differential бэкап - разницы нет.

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

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 2)
Ответ на: комментарий от Pinkbyte

Ну я не стал бы «запись в файл» приравнивать к перенаправлению stdout. Отсюда я думаю и недопонимание.

Дальше если ты говоришь что разницы нет.

Но я и спрашиваю что по факту разницы нет, тогда к чему автор использует --parent. Почему в этом случае вываливается полный, а не только сами изменения? И тут ты можешь сказать что, потому что чтобы добавлять изменения ему нужна, «основа» и поэтому первый раз он вываливает ПОЛНЫЙ /backup/home/BACKUP-new. Но зачем тогда было делать до этого НЕ МЕНЕЕ полный /backup/home/BACKUP? Тут переходит пересечение на следующий вопрос. Этот первый полный просто удаляется. А то что ты описываешь на мой взгляд укладывается если бы происходило вот так: 

btrfs send -p /home/BACKUP /home/BACKUP-new | btrfs receive /backup/home/BACKUP
но на деле то он вот так: 
btrfs send -p /home/BACKUP /home/BACKUP-new | btrfs receive /backup/home/BACKUP-new
и тут безусловно можно сделать замечание что это нужно для того чтобы было несколько копий (если не считать ньюанса что они оба ПОЛНЫЕ), но тогда зачем просто удалять /backup/home/BACKUP? Он ведь тупо создался и удалился ни как не использовался.

garcol
() автор топика
Ответ на: комментарий от garcol

Он ведь тупо создался и удалился ни как не использовался.

Он использовался. Иди читай про снапшоты, либо проси кого-то терпеливого ( intelfx) тебе заново всё разжевать.

anonymous
()
Ответ на: комментарий от anonymous

Если ты так уверен что знаешь то объяснил бы. А если такой не терпеливый то чего было сюда заходить ничего толкового так и не донёс, как тебе только терпения хватило на 10 безъинформативных постов.

garcol
() автор топика
Ответ на: комментарий от garcol

если не считать ньюанса что они оба ПОЛНЫЕ

Ээээ, что? o_O

Судя по всему ты не понимаешь чем отличается subvolume от снапшота. Рекомендуют вот это к прочтения

Именно из-за такого непонимания тобой принципа CoW у нас троих(я, ты и анонимус) и не получается диалога.

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от Pinkbyte

имхо garcol под «допишет файл» имел ввиду то, что перезаписанный dump.file будет содержать только разницу между двумя исходными снапшотами.

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

torvn77 ★★★★★
()
Ответ на: комментарий от Pinkbyte

Что у вас за привычка «иди читай то иди читай сё». Я не спрашиваю у вас что такое чтение при записи, сснимки или инноды. Если ты понимаешь в чём суть то объясни так как будто объясняешь сам себе, ведь ты то знаешь всё и вполне можешь сам себе объяснить не правда ли? А если я спрошу что такое снимки то тогда уже кидайся ссылками.

И в данном случае судя по всему ты чего то не понимаешь ибо я говорил про 2 поддтома и причём тут твоя разница subvolume и snapshot? Речь шла про /backup/home/BACKUP-new и /backup/home/BACKUP, а это по сути два поддтома. И ты сам выше говорил что backup/home/BACKUP-new полный, сейчас заднюю даёшь.

garcol
() автор топика
Ответ на: комментарий от garcol

Если ты понимаешь в чём суть то объясни так как будто объясняешь сам себе

Тебе что я, что анонимус, уже разжевали всё что можно. У тебя явно пробелы в теории. С таким же успехом можно пробовать учить матан, элементарно не зная сложения/вычитания. Провальная затея.

Речь шла про /backup/home/BACKUP-new и /backup/home/BACKUP, а это по сути два поддтома

Нет

И ты сам выше говорил что backup/home/BACKUP-new полный, сейчас заднюю даёшь.

Нет. Я говорил о том, что если нужно сделать ПОЛНЫЙ бэкап(например через rsync/tar/cp) - нет разницы откуда его делать - из BACKUP или из BACKUP-NEW

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 2)
Ответ на: комментарий от Pinkbyte

Не подтомы говоришь? Может аргументировал бы как-то? А то всезнайность так и прёт, а объяснения сам ищи. Как я уже говорил, не знаешь, не хочешь помогать пройди мимо, нахрен тему засорять?

То есть по твоему вот это не подтом получается 

btrfs send /home/BACKUP | btrfs receive /backup/home/BACKUP

А если в конвеер добавить scp на другой хост то тоже не подтом? Или уже том? Тогда почему тут не том?

garcol
() автор топика
Ответ на: комментарий от garcol

Может аргументировал бы как-то?

Это команда из приведенной в первом посте wiki-страницы: 

btrfs subvolume snapshot -r /home /home/BACKUP-new

А это - из приведенной мною ссылки:

A snapshot in Btrfs is a special type of subvolume

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

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

Тебя попросили прочитать даже не man-ы, статью! Где всё разжевывают доступно и по шагам! Статью за тебя нашли! Она не 100500 страниц, вдумчиво читая её можно потратить 5, ну 10 минут. А потом, приходить с вопросами, ЕСЛИ таковые останутся после прочтения статьи.

Но ты же такой умный. А все вокруг просто смеются над тобой и не могут лично тебе объяснить, всё тыкают в какие-то непонятные писульки!

С таким отношением тебе вообще никто помогать не будет.

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от garcol

Тебе пытались указать правильное направление, но у тебя напрочь отсутствует понимание матчасти, а заполнять пробелы в твоём образовании и терпеть твои жалобные понты это не сюда - это ЛОР, детка, тут и нах&й послать могут.

anonymous
()
Ответ на: комментарий от Pinkbyte

Ну вот видишь ведь совсем другое дело, привнёс немного конструктивизма.

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

На вопрос так и не ответил кстати. Могу повторить. Ты утверждаешь что вот тут 

btrfs send /home/BACKUP | btrfs receive /backup/home/BACKUP
btrfs send -p /home/BACKUP /home/BACKUP-new | btrfs receive /backup/home/BACKUP-new
мы получаем не 2 тома, а если рассуждать твоей логике видимо снимки.

То есть по твоему если мы туда же в конвеер добавим пересылку на другой хост то в итоге мы получим тоже снимки? Или всё же тома?

garcol
() автор топика
Ответ на: комментарий от garcol

То есть по твоему если мы туда же в конвеер добавим пересылку на другой хост то в итоге мы получим тоже снимки? Или всё же тома?

Ты плохо читал то, что я тебе процитировал.

A snapshot in Btrfs is a special type of subvolume
special type
of subvolume

Два вопроса:

1) чем отличается снимок от обычного подтома со стороны прикладного ПО(не утилиты btrfs, а например ls/cat/cp/whatever)?
2) чем отличается снимок от обычного подтома со стороны утилиты btrfs? Тем же самым, что и в 1) или чем-то еще?
Если чем-то еще, то чем?

Немного отвлекусь от темы и посетую, что мне больше нравиться идея ZFS, где снапшоты - это снапшоты(хотя их тоже можно примонтировать и изменять), а на базе их уже делаются клоны, которые обычно и монтируют. Потому что, например, нельзя сделать снапшот снапшота(как бы курьезно это не звучало). Иерархичность структуры том->снапшот->клон. Собственно клон обладает всеми свойствами обычного тома(и с него таки можно делать снапшоты, а уже от них клоны - и так далее), за исключением того, что является зависимым(то есть том, от которого сделан клон просто так удалить нельзя, правда есть трюк с promote).

В Btrfs же это всё упрощено(и это не хорошо и не плохо, это просто данность), из-за чего у некоторых невнимательно читающих возникает дикая каша в голове - ведь снапшот «внешне»(для сторонних утилит) ничем не отличается от subvolume, в чём тогда разница при btrfs send?

А разница в потрохах :-)

Надеюсь после этой портянки ты сможешь сам ответить на вопрос: что же мы получим на принимающей стороне - обычный subvolume или снапшот?

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 3)
Ответ на: комментарий от Pinkbyte

Мне самому ZFS больше нравится, она сделана более последовательно чтоли, но ZFS я оставил с FreeBSD. Да и там после покупки Sun судя по всему не всё так гладко видимо с ней будет. На Linux с ZFS на сколько я знаю всё ещё темнее. И да опыт работы с ZFS вносит небольшую неясность при работе с BtrFS. Но сейчас мы говорим не про ZFS.

Если вернуться к теме, то разумеется на той стороне мы получим том, не могу понять почему в твоём представлении на локальной машине в данном случае получается снимок. Поэтому просто смотрим на инструкцию к receive и видим, там сказано «восстанавливает том из потока stdin». Да и какой смысл тогда вообще из снимка делать другой снимок через send, тут даже сама миссис логика с тобой не согласится.

И разумеется ты тут снова ткнёшься пальцем в свою любимую надпись про «special type of subvolume». Да я её видел конечно, но что это меняет? Тут явно принцип кошек и львов.

Поэтому опять возвращаемся к вопросу: /backup/home/BACKUP и /backup/home/BACKUP-new тома?

garcol
() автор топика
Ответ на: комментарий от garcol

Если вернуться к теме, то разумеется на той стороне мы получим том

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

Твоя цитата вполне укладывается в логику. Можно послать снапшот, можно послать весь том. Учитывая что снапшот - это особый вид тома, всё логично.

/backup/home/BACKUP и /backup/home/BACKUP-new тома?

Это снапшоты. Так как используется -p, а не -c.

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

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Помогите понять прикол с клавиатурой (цифры с нампада не весь софт принимает)
General
настройка раскладки клавиатуры для X11 →