BTRFS. Готова ли к использованию в 16.04?

[Sly_tom_cat]

Я попробовал бекапить в файл.

Полный бекап то я из файла обратно вытянул.

А вот что делать с инкременталным файлом - не ясно - просит парента... но на том конце у меня не btfs слить полный и инкремент в команде btfs send -c increment base | .... я не могу.... 

[Pilot6]

Sly_tom_cat,
Если в файл, то так не получится. Так работает, если принимать в подтом. Если в приемном подтоме есть парент, то само все получится.
Пользователь добавил сообщение 17 Июня 2016, 18:29:11:Вот скрипт, который бэкапит @ и @home на другой диск.

Код: [Выделить]

#!/bin/bash

mount /dev/sda1 /mnt
btrfs sub snap -r /mnt/@ /mnt/@-BACKUP-new
btrfs sub snap -r /mnt/@home /mnt/@home-BACKUP-new

sync

btrfs send -p /mnt/@-BACKUP /mnt/@-BACKUP-new | btrfs receive /media/HardDrive/Clonezilla
btrfs send -p /mnt/@home-BACKUP /mnt/@home-BACKUP-new | btrfs receive /media/HardDrive/Clonezilla

btrfs sub del /mnt/@-BACKUP
mv /mnt/@-BACKUP-new /mnt/@-BACKUP

btrfs sub del /media/HardDrive/Clonezilla/@-BACKUP
mv /media/HardDrive/Clonezilla/@-BACKUP-new /media/HardDrive/Clonezilla/@-BACKUP

btrfs sub del /mnt/@home-BACKUP
mv /mnt/@home-BACKUP-new /mnt/@home-BACKUP

btrfs sub del /media/HardDrive/Clonezilla/@home-BACKUP
mv /media/HardDrive/Clonezilla/@home-BACKUP-new /media/HardDrive/Clonezilla/@home-BACKUP

umount /mnt

echo $(date +%d.%m.%Y\ %T) >> /media/HardDrive/Clonezilla/log
Только этот скрипт будет работает, если сначала руками в первый раз сделать паренты.

В результате получаются два подтома с полными бэкапами. А если сохранять в файл, то там сложнее будет с инкрементами. Сразу не сообразишь.
Пользователь добавил сообщение 17 Июня 2016, 18:41:36:Поставил это дело в cron.weekly. Буду смотреть.

[Sly_tom_cat]

Все равно не понял

Вот есть на источнике @-BAKUP (с прошлого раза) и @-BAKUP-new - новый.
Делаем диф @-BAKUP-new - @-BAKUP = @-BAKUP-new, который отправляется на приемник.

На приемнике лежит прошлый бекап @-BAKUP и диф @-BAKUP-new

.... и тут мы удаляем на приемнике @-BACKUP и @-BAKUP-new (который диф) переименовываем в @-BAKUP. 

  как теперь из @-BAKUP на примнике что-то можно восстановить если там долько диф
Пользователь добавил сообщение 17 Июня 2016, 18:50:22:С файлами надо бы тоже разобраться, но пока мне даже со снимками не ясно....

[Pilot6]

Sly_tom_cat,
Не поверишь!! В приемнике получается полный бэкап, хоть и отправляли только диф. Этот диф применится. И в new будет то что надо.
Сам дивлюсь до сих пор, но работает.

Просто сам попробуй.

Бэкапы получаются очень быстро, так как диф отпраляется. А применение дифов - это нативная фича btrfs. Она вся на них построена. Там только с метадатой манипуляции происходят.
Пользователь добавил сообщение 17 Июня 2016, 18:54:55:А восстановить элементарно. Надо только не забыть атрибут read-only с подтома снять. И можно пользоваться хоть на месте, хоть копировать куда хошь.

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

Можно компрессию на приемнике сделать помощнее, чем lzo, чтобы места меньше занимало. Фантастика!

[Sly_tom_cat]

Я понял в чем магия.

На источнике мы делаем диф от базового @-BAKUP и при отправке имя @-BAKUP указано как родительский снимок.
На применике есть тот же самый базовый снимок @-BAKUP и с-но при приемке диф и база мерджатся и получается обратно полный снимок.

Диф при этом можно выкинуть в файл и потом из файла принять в тот каталог где лежит парент снимок.

И вот тут фантастика у меня вышла...

В @ я создал через truncate -s5M новый файл. После этого сделал диф в файл.
из файла принял в приемник - в приемнике новый файл размером 5Мб появился. Все ок.

Какой вы думаете размер у диф файла? 5Мб + копейки....  а вот и нет - 471 байт   



Пользователь добавил сообщение 17 Июня 2016, 19:31:38:Все упаковщики в мире отдыхают.... 5MB передать в файле размером 471 байт - это вам не хухры-мухры....


На самом деле я догадываюсь что btrfs как-то осознала, что truncate - это как бы пустой файл.... НО в файлах то пусто (нули) и оно таки и передалось типа как файл с 5Мб нулей....

[Pilot6]

Sly_tom_cat,
А чего ты удивляешься. Там же компрессия. Вот она и сжала.
Пользователь добавил сообщение 17 Июня 2016, 19:35:09:Sly_tom_cat,

Диф при этом можно выкинуть в файл и потом из файла принять в тот каталог где лежит парент снимок.

Это понятно. Вопрос в том как делать инкрементальные бэкапы, если они храниться будут не на btrfs. В облаке например.
Файлы туда можно инкрементальные накидать. Можно и начальный образ тоже кинуть. Только восстанавлиать придется последовательно.

[Sly_tom_cat]

То же самое проделал с файлом созданным через dd if=/dev/urandom of=file4 bs=1M count=20
Размер файла - 20 971 520 байта
Размер дифа - 20 987 034 байта

- никакой фантастики. А вот сжать 5Мб нулей в 400 байт - это все равно сильно. gzip смог зажать этот файл только в 5121 байт...
Пользователь добавил сообщение 17 Июня 2016, 19:54:29:Если хранить инкрементальный бекап в файлах, то само собой - только последовательно - базовый + последовательно дифы. Но по большому счету это все скриптом делается на раз-два. Но по времени будет конечно не слишком быстро ИМХО.

[Pilot6]

Sly_tom_cat,
 

Но по времени будет конечно не слишком быстро ИМХО.

Ну думаю, что будет шибко медленно. Это же COW, а работа с дифами встроена. Так вообще обычные файлы пишутся.
И при восстановлении из бэкапа скорость не так уж критична.

А вот сжать 5Мб нулей в 400 байт - это все равно сильно.

На самом деле правильная комапрессия так и должна делать. Что 5Мб, что 5Гб. Указываешь скока нулей и всё.

[victor00000]

Sly_tom_cat, что он ноут Асус крышка открыть очень медлено загрузка.

[alsoijw]

- никакой фантастики. А вот сжать 5Мб нулей в 400 байт - это все равно сильно. gzip смог зажать этот файл только в 5121 байт...

Если ситуация с группой подряд идущих нулей встречается часто, то имеет смысл написать раеализация. количество байт в 5МБ запросто влезет в i64(8 байт) конечно надо ещё пояснить что эти 8 байт значат... Так что 400 как-то многовато.

[Sly_tom_cat]

Коллеги, степень упаковки - для универсального решения и для случая 5Мб нулей - вещи разные.

Но, в том то и дело, что даже на установление факта, что в файле ничего кроме нулей нет - тоже нужно время/ресурсы. При условии того, что это в среднестатистическом случае крайне невероятное событие.

Но, давайте уже закроем эту тему. Чуда с файлом из urandom нет - все в полном порядке - без обмана.
А то что BTRFS умеет работать с дырками в файлах - это вроде известная фича, когда весь файл - дырка - то дырка от бублика и передается .

[AnrDaemon]

Sly_tom_cat, ты упускаешь из виду, что sparse files - нормальное для файловой системы явление.
Она просто готова к таким вывертам
В отличие от gzip.

[Sly_tom_cat]

AnrDaemon, я как раз о том же.

[Pilot6]

Появилась новая фича при обновлении дистрибутива на btrfs. Вчера обновлял с 14.04 на 16.04.
Появился автоматом подтом @apt-snapshot-release-upgrade-xenial-(дата). Я-то руками сначала создал. А оказывается теперь это на автомате.

[Azure]

Возможно это объясняется установленной из коробки утилитой apt-btrfs-snapshot?