Btrfs (иногда произносится butter fs) - новая свободная файловая система, разрабатываемая при поддержке компании Oracle. Распространяется по лицензии GPL. Несмотря на то, что её разработка ещё далека от завершения, 9 января 2009 года файловая система была интегрирована в ядро Linux, и доступна в Debian Squueze.

Хотя Btrfs была включена в ядро 2.6.29, разработчики утверждают, что "начиная от ядра 2.6.31, мы только планируем сделать впредь совместимый формат изменений диска". Разработчики по-прежнему хотят улучшить пользовательские/управленческие средства, чтобы сделать их более удобными в использовании. Для получения дополнительной информации о Btrfs, по ссылке в section.

Ext2/3/4 могут быть превращены в Btrfs (но не наоборот).

Cтатус

Debian Squeeze и новые версии поддержывают Btrfs.

FAQ

Какой пакет содержит утилиты для btrfs?

btrfs-tools (in DebianSqueeze and above)

Смотреть также: Btrfs wiki FAQ

Примеры команд по работе с btrfs

Создание файловой системы:

mkfs.btrfs

Управление томами, подтомами, снимками; проверка целостности файловой системы:

btrfsctl

Сканирование в поисках файловых систем btrfs:

btrfsctl -a btrfsctl -A /dev/sda2

Создание снимков и подтомов:

mount -t btrfs -o subvol=. /dev/sda2 /mnt btrfsctl -s new_subvol_name /mnt btrfsctl -s snapshot_of_default /mnt/default btrfsctl -s snapshot_of_new_subvol /mnt/new_subvol_name btrfsctl -s snapshot_of_a_snapshot /mnt/snapshot_of_new_subvol ls /mnt

Проверка extent-деревьев файловой системы:

btrfsck

Вывести метаданные в текстовой форме:

debug-tree debug-tree /dev/sda2 >& big_output_file

Показать файловые системы btrfs на жестком диске:

btrfs-show /dev/sda*

Дефрагментация (по умолчанию не требуется):

# btrfs filesystem defragment /mnt или # btrfs filesystem defragment /mnt/file.iso

Превращение файловой системы ext3 в btrfs

Файловую систему ext3 можно превратить в btrfs, и работать с ней дальше уже как с новой файловой системой. Причём состояние исходной файловой системы ext3, будет доступно и потом.

# Always run fsck first %# fsck.ext3 -f /dev/xxx # Convert from Ext3->Btrfs %# btrfs-convert /dev/xxx # Mount the resulting Btrfs filesystem %# mount -t btrfs /dev/xxx /btrfs # Mount the ext3 snapshot %# mount -t btrfs -o subvol=ext2_saved /dev/xxx /ext2_saved # Loopback mount the image file %# mount -t ext3 -o loop,ro /ext2_saved/image /ext3

Теперь в каталоге /ext3 видно состояние исходной файловой системы.

Размонтирование происходит в обратном порядке:

%# umount /ext3 %# umount /ext2_saved %# umount /btrfs

Можно вернуться на файловую систему ext3 и потерять сделанные изменения:

%# btrfs-convert -r /dev/xxx

Или можно остаться на btrfs и удалить сохранённый образ файловой системы ext3:

%# rm /ext2_saved/image

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

Посмотреть размер метаданных:

# btrfs filesystem df /mnt/data1tb/

Нормализировать их размер:

btrfs fi balance /mnt/btrfs

Подробнее: Conversion from ext3 (англ.) и Преобразование ext3fs в btrfs (рус.)

Изменение размера файловой системы и разделов

Для btrfs доступно онлайн (на лету) изменение размера файловой системы. Для начала нужно примонтировать нужный раздел:

# mount -t btrfs /dev/xxx /mnt

Добавление 2Гб:

# btrfs filesystem resize +2G /mnt или # btrfsctl -r +2g /mnt

Уменьшение на 4Гб:

# btrfs filesystem resize -4g /mnt или # btrfsctl -r -4g /mnt

Задать размер в 20Гб файловой системе:

# btrfsctl -r 20g /mnt или # btrfs filesystem resize 20g /mnt

Использование всего свободного места:

# btrfs filesystem resize max /mnt или # btrfsctl -r max /mnt

Вышеперечисленные команды справедливы только для файловой системы. Чтобы изменить размер раздела, надо воспользоваеться еще другими утилитами, например fdisk. Рассмотрим пример для уменьшения раздела на 4Гб. Монтируем и уменьшаем раздел:

# mount -t btrfs /dev/xxx /mnt # btrfsctl -r -4g /mnt

Теперь отмонтируем раздел и используем fdisk:

# umount /mnt fdisk /dev/xxx # где dev/xxx - жесткий диск с нужным нам разделом

Я как гик, всё ещё имею привычки, постоянно эксперементировать с системой: пересобирать, ставить несталбильные RC ядра, включать experimental ветки обновлений. Часто, я бы даже сказал слишком часто ломаю систему (мой личный рекорд, 2 недели без переустановки).

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

Собственно, к чему я веду.

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

How-to или очередной велосипед.

Пункт 1: LiveCD

Пост фактум, мы исходим из того что диск разбит на 2 раздела: /boot отформатированный в ext4 и / отформатированный в btrfs.
На диске в MBR записан grub 2.
Соответственно, первый пункт:
Из личных привычек и соображений, намного проще восстановить систему из графического интерфейса, чем любоваться чёрным экраном и порой без доступа к интернету, вспоминать и прописывать команды. Нет, я не считаю что консоль зло, я люблю консоль, но так или иначе, а из графического интерфейса приятнее.
Действие первое
Идея не нова, признаюсь она где-то фигурировала на хабре, но ссылку я не нашёл, потому прошу прощения у источника публикации.
Копируем образ нужного Live дистра в папку /boot
sudo cp /media/timofey/boot/grub/ISO/Linux/Ubuntu/ubuntu-12.10-desktop-amd64.iso /boot/ubuntu-12.10-desktop-amd64.iso
/boot вынесен на отдельный раздел, не потому что так лучше, а потому что по неизвестным мне причинам, LiveCD записанные на btrfs из под grub 2 не загружаются.
Теперь поправляем настройки grub 2 по умолчанию, чтобы при обновлении grub"a, не терять образ.
sudo nano /etc/grub.d/40_custom

И вставляем туда нечто подобное, после комментариев:
menuentry "Ubuntu 12.10 amd64" { set isofile=/ubuntu-12.10-desktop-amd64.iso loopback loop $isofile linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noeject noprompt -- initrd (loop)/casper/initrd.lz }

Собственно по образу и подобию настраивалось (официальная wiki ubuntu):
/Grub2/ISOBoot
Теперь «почти» самое важное, генерируем заново конфиг:

Sudo update-grub

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

Пункт 2: Снимки

Я думаю, любой достаточно давно знакомый с Linux человек как минимум слышал о btrfs, возможно даже, что уже составил своё собтвенное мнение. При установке ubuntu на раздел с btrfs по умолчанию делается очень мудро, используется механизм сабразделов, и создаются 2 саб раздела это @ и home (которые заменяю / и /home), соответственно при граматной переустановке системы, конфиги мы не потеряем. Но сейчас не об этом. Как же использовать эту заботу о конечных пользователях? Очень просто.

Немного предыстории:
Изначально планировалось выполнять скрипт через rc.local, но он не выполнялся, потом было реализовано через cron ежедневное, позже я победил rc.local и к чертям отключил снапшоты в cron.

Код скрипта:

#!/bin/bash #This script for autocreating snapshot on startup #Version 1.2.9 set -e DATA="$(date +%g%m%d%k%M%S)" VOLUME=/dev/sda1 [ ! -d "/tmp/$DATA/" ] && sudo mkdir "/tmp/$DATA/" mount $VOLUME "/tmp/$DATA/" && { [ ! -d "/tmp/$DATA/snapshots/" ] && sudo mkdir "/tmp/$DATA/snapshots/" mkdir "/tmp/$DATA/snapshots/$DATA/" && cd "/tmp/$DATA/" btrfs subvolume snapshot ./@ ."/snapshots/$DATA/@_${DATA}/" btrfs subvolume snapshot ./@home ."/snapshots/$DATA/@home_${DATA}/" [ ! -f ./snapshots/snapshots.log ] && touch ./snapshots/snapshots.log chmod 777 ./snapshots/snapshots.log echo on_startup_$(date +%X_%x) >> ./snapshots/snapshots.log umount -l "/tmp/$DATA/" && sudo rmdir "/tmp/$DATA/" }

Расположен он по адресу /etc/btrfs_snapshot_onstartup
Добавляем его в /etc/rc.local и даём права на исполнение обоим файлам, через sudo chmod +x "путь к файлу"
Может не заработать логирование выполнения в файл./snapshots/snapshots.log, тогда нужно создать его вручную под правами рут. После перезагрузки он сам получит нужные права.

В любой момент мы можем просмотреть состояние снимков системы набрав:
cat /var/log/snapshots.log

Все снимки складываются в раздел с системой в папку snapshots, где создаётся папка каждого успешного запуска системы.
Некоторые могут сказать, что не оправдывает себя, создание снапшотов во время запуска. Отнюдь, оправдывает, за сутки я могу внести кучу изменений в систему и сотню раз её перезапустить и в альтернативных случаях я не смогу вернуться к моменту успешного запуска (актуального), а только однодневной давности.

Вариант, запуска вручную:
#!/bin/bash #This script for autocreating snapshot #Version 1.2.8 set -e DATA=$(date +%g%m%d%k%M%S) ################################## [ ! -d /tmp/$DATA/ ] && sudo mkdir /tmp/$DATA/ sudo mount /dev/sda2 /tmp/$DATA/ && { #################################################################### [ ! -d /tmp/$DATA/snapshots/ ] && mkdir /tmp/$DATA/snapshots/ mkdir /tmp/$DATA/snapshots/$DATA/ cd /tmp/$DATA/ sudo btrfs subvolume snapshot ./@ ./snapshots/$DATA/@_${DATA}/ sudo btrfs subvolume snapshot ./@home ./snapshots/$DATA/@home_${DATA}/ #################################################################### sudo chmod 777 ./snapshots/snapshots.log sudo echo this.hands_$(date +%X_%x) >> ./snapshots/snapshots.log sudo cat ./snapshots/snapshots.log sleep 1 sudo umount -l /tmp/$DATA/ && sudo rmdir /tmp/$DATA/ #################################################################### sudo btrfs filesystem df / #information about fs } read exit 0

Пункт 3: Восстановление

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

Пункт 4: Чистка

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

#!/bin/bash #Version 0.0.9 set -e DATA=$(date +%g%m%d%k%M%S) [ ! -d "/tmp/$DATA" ] && sudo mkdir "/tmp/$DATA" sudo mount /dev/sda1 "/tmp/$DATA" && { cd "/tmp/$DATA/snapshots/" for i in */* do sudo btrfs subvolume delete "$i" done for i in * do sudo rmdir -v "$i" done echo cleanup_$(date +%g%m%d%k%M%S) > "./snapshots.log" sudo cp "./snapshots.log" "/var/log/snapshots.log" sudo umount -l "/tmp/$DATA" && sudo rmdir "/tmp/$DATA" } read exit 0

Итог

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

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

Да я знаю lvm, но мне не нужен дополнительный слой абстракции от железа и выносить снимки на отдельный раздел, тоже не комильфо.

UPD 1:
Спасибо пользователям

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

Введение

*nix-системы всегда были относительно устойчивы к некорректно написанным приложениям (в том случае, конечно, если они запускались не из-под суперпользователя). Однако иногда возникает желание поэкспериментировать с системой - порезвиться с конфигами, отдельные из которых могут быть жизненно важными, запустить подозрительный скрипт, поставить программу, полученную из недоверенного источника… А то и просто одолевает паранойя, и хочется возвести как можно больше барьеров для защиты от потенциальной малвари. В статье будут описаны некоторые средства, позволяющие избежать последствий невынужденных ошибок с помощью отката на заблаговременно созданную точку возврата (снапшоты Btrfs), запустить подозрительную программу в ограниченном окружении и потешить твою паранойю (Arkose и chroot).

Chroot

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

Существует как минимум три способа создания chroot-окружения:

  1. Все необходимые для работы запускаемой программы приложения и библиотеки ты определяешь сам. Это наиболее гибкий способ, но и наиболее замороченный.
  2. Chroot-окружение формируется динамически. Одно время существовал проект Isolate, который это и делал, но нынче по неизвестным причинам он канул в Лету.
  3. Развертывание базовой системы в указанном каталоге и чрутинг на него - его я и опишу.

Grub и Btrfs

Скорее всего, при загрузке с раздела Btrfs Grub будет ругаться, что-де разреженные файлы недопустимы, и просить нажать любую клавишу. Чтобы это сообщение не выскакивало, открой в любимом текстовом редакторе файл /etc/grub.d/00.header и закомментируй там следующую строчку:

If [ -n "\${have_grubenv}" ]; then if [ -z "\${boot_once}" ]; then save_env recordfail; fi; fi

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

Огнелис в песочнице - об этом говорит заголовок

Для начала установим пакет debootstrap, который используется как раз с этой целью.

$ sudo apt-get install debootstrap

Затем создадим каталог, в котором будет находиться chroot, и развернем базовую систему quantal в нем. В общем-то, его можно создать где угодно, но традиционное место его размещения - /var/chroot. Поскольку большинство следующих команд требуют права root, имеет смысл переключиться на аккаунт суперпользователя:

$ sudo su - # mkdir /var/chroot && cd /var/chroot # debootstrap quantal ./quantal-chr1 http://mirror.yandex.ru/ubuntu

Разберем последнюю команду. Она разворачивает релиз убунты Quantal в отдельный каталог quantal-chr1 (мало ли, вдруг понадобится еще один chroot) с ближайшего зеркала. После завершения развертывания необходимо отобразить файловые системы procfs, sysfs и (если это необходимо) каталог /dev на данное поддерево. В случае если chroot будет использоваться для текстовых приложений только до перезагрузки, должно хватить следующих команд:

# mount --bind /proc /var/chroot/quantal-chr1/proc # mount --bind /sys /var/chroot/quantal-chr1/sys # mount --bind /dev /var/chroot/quantal-chr1/dev

Если же требуется, чтобы данное поддерево работало и после перезагрузки, добавь соответствующие строки в /etc/fstab. Ну а для работы некоторых графических приложений также следует отобразить каталоги /tmp и /var/run/dbus. После этого уже можно вводить следующую команду, которая, собственно, и делает chroot:

# chroot /var/chroot/quantal-chr1/

И ты уже заперт в нем. Для того чтобы не спутать chroot с реальной системой, рекомендую изменить приглашение оболочки. Для примера давай установим и запустим в chroot Skype. Для этого потребуется установить на хостовой системе пакет schroot, который позволяет упростить запуск программ в chroot-окружении:


Развертывание в chroot базовой системы с помощью debootstrap # apt-get install schroot

Затем добавим запись в файл /etc/schroot/schroot.conf. В моем случае я добавил следующую:

/etc/schroot/schroot.conf description=Quantal Skype directory=/var/chroot/quantal-chr1 priority=3 users=rom groups=rom root-groups=root,rom

Пробрасываем /dev, /proc, /sys, /tmp и /var/run/dbus - как это сделать, смотри выше. Добавим в chroot пользователя и группу skype - при этом желательно, чтобы uid и gid совпадали с uid/gid основного пользователя реальной системы (в моем случае - rom), для чего набираем следующие команды:

# schroot -c quantal-skype -u root # addgroup --gid 1000 skype # adduser --disabled-password --force --uid 1000 --gid 1000 skype

После этого ставим свежескачанный Skype - опять же в chroot - и удовлетворяем его зависимости:

# dpkg --force-all -i skype-ubuntu-precise_4.1.0.20-1_i386.deb # apt-get -f install # exit

В основной системе разрешаем соединения с X-сервером с localhost и заходим в chroot как обычный пользователь:

$ xhost +localhost $ cd / && schroot -c quantal-skype -u rom /bin/bash

Устанавливаем переменную DISPLAY (которую надо посмотреть в основной системе) и запускаем Skype:

$ export DISPLAY=":0.0" $ skype --dbpath=/home/skype/.Skype &

Скайп успешно установлен и запущен в chroot-окружении.

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


Использование Arkose

Arkose действует аналогично песочницам в Windows, таким, например, как Sandboxie. Практически это удобная обертка для контейнеров LXC. Но, как известно, удобство и гибкость порой несовместимы - тонкая настройка создаваемых контейнеров затруднительна. Из плюсов отмечу интуитивно понятный интерфейс (это если использовать GUI - впрочем, запуск из командной строки тоже очень прост), из минусов же - по умолчанию требует довольно много свободного места на жестком диске и имеются некоторые возможные пути обхода; но, если использовать Arkose как дополнительную обертку для потенциальных путей внедрения малвари (браузер) или даже просто для экспериментов с каким-нибудь интересным приложением, это никак не повредит.

Seccomp и seccomp-bpf

Seccomp - малоизвестный механизм, внедренный еще в ядро 2.6.12, который позволяет процессу совершить односторонний переход в «безопасное» состояние, где ему будет доступно только четыре системных вызова - exit(), sigreturn(), read() и write(), причем последние два доступны только для уже открытых файлов. Если же процесс попытается вызвать любой другой сисколл, он будет немедленно убит.

Очевидно, что это решение не очень гибкое. В связи с этим в ядре 3.5 появился seccomp-bpf, который позволяет с помощью правил BPF тонко настраивать, какие именно системные вызовы (и их аргументы) разрешены, а какие - нет. Seccomp-bpf применяется в Google Chrome, Chrome OS, а также бэкпортирован в Ubuntu 12.04.

Перед тем как использовать Arkose, его надо установить. Процедура стандартна:

$ sudo apt-get install arkose-gui

Будет установлен как графический интерфейс (arkose-gui), так и утилита командной строки (arkose). Графический интерфейс настолько прост, что описывать его я смысла не вижу, лучше сразу перейдем к практике.


Ручное создание
read-only снапшо-
та в Btrfs

Опции командной строки рассмотрю:

  • -n {none,direct,filtered} - отображение сети на песочницу. Опции none и direct не требуют пояснения, filtered создает для каждой песочницы свой интерфейс. На практике же лучше использовать либо none, либо direct, поскольку filtered настраивать достаточно долго.
  • -d {none,system,session,both} - доступ к шинам D-Bus из песочницы.
  • -s размер - устанавливает размер хранилища в мегабайтах. По умолчанию 2000 Мб для ext4 или половина памяти для tmpfs. После завершения работы запускаемой в песочнице программы хранилище уничтожается.
  • -t - тип файловой системы хранилища. По дефолту используется ext4.
  • --root каталог - указывает каталог, который отображается на песочницу в качестве корня.
  • --root-type {cow,bind} - как именно отображать корень. Если использовать cow, то любые изменения после закрытия песочницы пропадут, а если bind - сохранятся.
  • --base-path - указывает место хранения песочницы. По умолчанию это ~/.arkose.
  • --bind каталог и --cow каталог - отображает каталог либо в режиме cow, либо напрямую. Естественно, использование той или иной опции зависит от типа отображения корня - использовать опцию --cow на каталоге, который и так уже copy-on-write, не имеет смысла.
  • -h - использовать реальный домашний каталог. Действует аналогично --bind $HOME.
  • -p - разрешает использовать PulseAudio.

Для примера запустим Firefox:

$ sudo arkose -n direct -p firefox

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

«Но постой! Зачем же sudo?» - может возникнуть резонный вопрос. Дело в том, что некоторые подготовительные операции доступны только из-под root. Однако спешу тебя успокоить - запускаемая программа будет работать с правами текущего пользователя.


Добавление пользователя для запуска Skype в chroot

Кратко о BTRFS

Бывает, что после установки обновлений система рушится. Здесь пригодились бы средства, аналогичные компоненту «Восстановление системы» Windows. С гордостью заявляю - их есть у нас! И одно из этих средств - Btrfs. Из достоинств новой файловой системы от Oracle стоит отметить следующие:

  • Копирование при записи (Copy-on-Write). Эта технология служит для создания снапшотов - мгновенных снимков состояния системы. При создании снапшота драйвер ФС копирует в него метаданные и начинает мониторить фактическую запись. Если она обнаруживается, в снапшот помещаются оригинальные блоки данных, а на их место записываются новые.
  • Динамическое выделение инодfов. В отличие от ФС старого поколения, в Btrfs нет ограничения на количество файлов.
  • Сжатие файлов.
  • Возможность размещения ФС на нескольких физических носителях. Фактически это тот же самый RAID, только более высокоуровневый. На момент написания статьи поддерживались RAID 0, RAID 1 и RAID 10, поддержка же RAID 5 находилась на ранней стадии разработки.

Создание и удаление снапшотов

Для совершения операций над ФС нового поколения, таких, например, как создание снапшотов, дефрагментация тома и многих других, служит команда btrfs. Синтаксис у нее, в общем случае, следующий:

Btrfs <команда> <аргументы>

Какие же именно операции можно производить над Btrfs? Ниже будут приведены команды, которые мне показались интересными.

  • btrfs subvol create [<путь>/]<имя> - создает подтом (см. врезку). Если путь не указан, создает его в текущей директории.
  • btrfs subvol delete <имя> - соответственно, удаляет подтом.
  • btrfs subvol find-new <путь> <поколение> - список последних модифицированных файлов в указанном пути, начиная с указанного поколения. К сожалению, пока что нет возможности простым способом узнать текущее поколение того или иного файла, поэтому применение этой команды может сопровождаться танцами с бубном.
  • btrfs subvol snapshot [-r] <подтом> <путь к снапшоту> - гвоздь программы. Создает снапшот указанного подтома с указанным путем к нему же. Опция -r делает невозможной запись в снапшоты.
  • btrfs subvol list <путь> - показывает список подтомов и снапшотов по указанному пути.
  • btrfs filesys df - использование места для указанной точки монтирования.
  • btrfs filesys resize [+/-]<новый размер> <путь> - да-да, в Btrfs есть возможность изменять размер на «живой» системе, причем не только увеличивать, но и уменьшать! С аргументами, думаю, все более-менее ясно, но, помимо указания размера, можно использовать аргумент max, который расширяет ФС до максимально возможного размера.

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

$ sudo btrfs subvol snap -r / /snapshot-2013-01-16

$ sudo btrfs subvol del /snapshot-2013-01-16

Подтома Btrfs

Подтом Btrfs может выступать в двух ипостасях: как директория и как объект VFS - то, что может быть примонтировано. Например, при установке Ubuntu создается два подтома - @ и @home. Первый содержит системные файлы, второй - данные пользователя. Это похоже на разбиение диска на разделы, только если раньше один раздел мог содержать, как правило, лишь один объект VFS, то теперь на одном разделе могут быть сразу несколько объектов, при этом они могут быть вложенными.

Автоматизация

Создавать снапшоты ручками я не вижу большого смысла - можно банально забыть это сделать. Напрашиваются три сценария автоматизации:

  • написать скрипт и поместить его в rc.local;
  • написать скрипт и поместить его в cron;
  • использовать команду btrfs autosnap.

К сожалению, в Ubuntu 12.10 последний метод по каким-то причинам недоступен, так что выбора, как такового, практически нет. Лично я предпочел написать скрипт для крона, но сначала давай создадим подтом, в котором и будут храниться наши снапшоты. Для чего? Хотя бы для того, чтобы не засорять корневую папку.

# mkdir /mnt/sda11 # mount /dev/sda11 /mnt/sda11 # btrfs subvol create /mnt/sda11/@snapshots # umount /mnt/sda11

Рассмотрим, что делают эти команды. Поскольку фактический корень ФС в данный момент недоступен (вместо него в убунте в качестве корня используется подтом @), мы вынуждены подмонтировать его ручками. В моем случае он находится на /dev/sda11. Третьей командой мы создаем подтом @snapshots - таким образом, если мы не подмонтируем его или реальный корень, его содержимое будет недоступно. А теперь собственно скрипт:

Autosnap.sh #!/bin/bash set -e VOLUME=/dev/sda11 TMP_PATH=/tmp/snapshots MOUNT_OPTS="subvol=@snapshots" # Текущие дата и время - необходимы для формирования имен папок со снапшотами NOW="$(date +%Y%m%d%H%M)" NOW_SEC="$(date +%s)" if [ $# -ne 1 ]; then # Если скрипт запущен без аргументов, ставим по умолчанию один день назад OLDER_SEC="$(date --date "1 day ago" +%s)" else # Если же у нас указан аргумент, считаем, что это дата в любом формате, который понимает команда date, со всеми вытекающими OLDER_SEC="$(date --date "$1" +%s)" fi # Вычитаем из текущей даты требуемую и преобразуем ее в минуты OLDER=$(($NOW_SEC-$OLDER_SEC)) OLDER_MIN=$(($OLDER/60)) [ ! -d "${TMP_PATH}/" ] && mkdir "${TMP_PATH}/" [ -z "`grep "${TMP_PATH}" /proc/mounts`" ] && mount "${VOLUME}" "${TMP_PATH}/" -o "${MOUNT_OPTS}" && { # Монтируем mkdir "${TMP_PATH}/${NOW}/" # Создаем снапшоты btrfs subvol snap / "${TMP_PATH}/${NOW}/rootsnap" > /dev/null 2>&1 btrfs subvol snap /home "${TMP_PATH}/${NOW}/homesnap" > /dev/null 2>&1 } && { # Ищем папки со снапшотами старше указанной даты for f in `find "${TMP_PATH}" -mindepth 1 -maxdepth 1 -type d -cmin +"$OLDER_MIN" -print0 |xargs -0`; do btrfs subvol del "${f}/rootsnap" > /dev/null 2>&1 && btrfs subvol del "${f}/homesnap" > /dev/null 2>&1 && # и удаляем снапшоты и папки, их содержащие rmdir "$f" done } umount -l "${TMP_PATH}" && rmdir "${TMP_PATH}"

Скрипт этот можно разместить, где удобно (лично я предпочитаю подобные вещи размещать в /usr/local/bin, но это дело вкуса), и запускать его либо из крона, либо из rc.local. По умолчанию скрипт ротирует снапшоты старше одного дня, но ты можешь задать любое желаемое количество в формате команды date - главное, не забудь заключить в кавычки.

Использование ISO-образа

Для того чтобы при повреждении каких-либо жизненно важных файлов не дергать каждый раз болванку с записанной убунтой, есть возможность в меню Grub добавить пункт загрузки с ISO-образа, что я и предлагаю сделать. Для этого понадобится не-Btrfs-раздел (поскольку по неизвестным причинам стандартная initramfs убунтовской исошки не желает видеть образ, если он находится на разделе с описываемой ФС) и прямые руки. Добавляем в файл /etc/grub.d/40_custom следующие строчки:

Menuentry "Ubuntu 12.10 i386 iso" { insmod part_msdos insmod fat # Устанавливаем корень, откуда берем ISO set root="hd0,msdos7" # Путь к образу относительно указанного выше корня set isofile=/ubuntu-12.10-desktop-i386.iso # Монтируем в качестве loopback-девайса прямо в Grub loopback loop $isofile linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noeject noprompt -- initrd (loop)/casper/initrd.lz }

и запускаем команду обновления основного конфига Grub:

$ sudo update-grub

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


INFO

Если ты работаешь в chroot-окружении под root, то есть возможность оттуда вырваться. Один из способов - использование системного вызова mknod() с последующим монтированием реального корня. Установка патчсета grsecurity позволяет решить эту проблему.

Команды Btrfs имеют стандартный и сокращенный вид. Например, команду «btrfs subvolume snapshot» можно записать как «btrfs su sn».

Итак, предположим, ты уронил систему и тебе необходимо ее восстановить из снапшота Btrfs. Для этого загрузись с данного ISO-образа, примонтируй тот раздел, систему на котором ты уронил, - именно раздел, не подтом! - и введи следующие команды (естественно, с поправкой на твои снапшоты и разделы):

# cd /mnt/sda11 # mv @ @_badroot # mv @snapshots/201302011434/rootsnap @

То же самое, при необходимости, делаем с @home и перезагружаемся. Если все прошло нормально, то можешь удалить @_badroot:

$ sudo btrfs subvol del @_badroot

Заключение

В *nix-системах есть множество способов обезопасить себя от неудачных экспериментов или смягчить их последствия. Я рассмотрел некоторые из них. Однако стоит заметить, что все эти способы предназначены в основном для экспериментаторов, любящих поковыряться в системе. Для отлова малвари они не подходят - их достаточно легко обнаружить, хотя некоторый уровень безопасности они, конечно же, обеспечивают.

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

Одной из таких файловых систем является Btrfs. Это относительно новая файловая система, которая появилась в 2007 году и была разработана компанией Oracle. Она предлагает очень широкий набор новых возможностей и поэтому сильно интересует пользователей, но до сих пор в сети ходят слухи, что эта файловая система еще не пригодна для постоянного использования. В этой статье мы попытаемся разобраться какие возможности нам дает Btrfs, а также действительно ли ее уже можно использовать.

Как я уже сказал, Btrfs была разработана компанией Oracle в 2007 году. Одной расшифровки названия нет, одни говорят, что это значит B-tree FS, другие Better Fs. Также как и в других файловых системах, все данные хранятся на диске по определенным адресам. Эти адреса сохранены в метаданных. И тут уже начинаются различия. Все метаданные организованны в виде b-деревьев. Это дает большую производительность при работе с файловой системой, а также позволяет добавлять неограниченное количество файлов.

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

Из-за своей структуры Btrfs имеет огромные возможности, например, она может работать с современными очень большими носителями данных. Максимальный размер файловой системы составляет 16 Экзабайт. Это все возможно благодаря правильному использованию пространства на диске. Другие файловые системы используют жесткий диск целиком, от начала до конца для записи своей структуры.

Btrfs поступает по-другому. Каждый диск, независимо от его размера делится на блоки по 1 Гб для данных и 256 Мб для метаданных. Затем эти блоки собираются в группы, каждая из которых может храниться на разных устройствах, количество таких блоков в группе может зависеть от уровня RAID для группы. Менеджер томов уже интегрирован в файловую систему, поэтому больше никакое дополнительное ПО использовать не нужно.

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

  • Поддержка снимков файловой системы, только для чтения или для записи;
  • Контрольные суммы для данных и метаданных с помощью алгоритма crc32. Таким образом, можно очень быстро определить любые повреждения блока;
  • Сжатие с помощью Zlib и Lzo;
  • Оптимизация для работы с SSD, файловая система автоматически определяет ssd и начинает вести себя по-другому;
  • Фоновый процесс для обнаружения и исправления ошибок, а также дефрагментации и дедупликации в реальном времени;
  • Поддерживается преобразование из ext4 и ext3 и обратно.

Все это очень хорошо, но можно ли уже использовать эту файловую систему? Попробуем разобраться и с этим.

Готова ли Btrfs к использованию?

Вокруг Btrfs до сих пор сохранилось много неправильных представлений. Многие из них происходят от реальных проблем, которые были в начале разработки файловой системы. Но люди, просматривая эту информацию не смотрят на ее дату. Да Btrfs действительно была нестабильной и неустойчивой. Было очень много проблем с потерей данных и много пользователей писали об этом, но это было еще в 2010 году.

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

Но почему же Btrfs считается многими нестабильной? Этому есть несколько причин. Во-первых, это боязнь пользователей к новым технологиям. Это было не только в Linux, но и в Microsoft, при их переходе на NTFS, и в Apple. Но здесь есть некоторый парадокс, файловая система XFS прошла 20 лет стабильного развития, но самой стабильной файловой системой считается ext4, которая была разработана из форка ext3 в 2006 году. Фактически она на год старше Btrfs.

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

Но уже есть много подтверждений, что файловая система готова. Эта файловая система используется на серверах Facebook, где компания хранит свои важные данные. А это уже само по себе важный фактор. Над улучшением файловой системы работают такие компании как Facebook, SuSE, RedHat, Oracle, Intel и другие. Эта файловая система используется в SUSE Linux Enterprise по умолчанию, начиная с выпуска 12. Все эти факторы вместе доказывают, что файловая система вполне готова к использованию. А учитывая функциональность и особенности btrfs ее уже можно использовать.

Использования Btrfs

Почему стоит использовать Btrfs и стоит ли вообще, разобрались. Теперь хотелось бы показать немного практики, чтобы вы могли оценить эту файловую систему в действии. Я буду приводить примеры на основе Ubuntu. Сначала установим инструменты для управления файловой системой:

sudo apt install btrfs-tools

Создание файловой системы btrfs

Сначала нужно создать файловую систему. Допустим, у нас есть два жестких диска /dev/sdb и /dev/sdc, мы хотим создать на них единую файловую систему с зеркалированием данных. Для этого достаточно выполнить:

sudo mkfs.btrfs /dev/sdb /dev/sdc

По умолчанию будет использоваться RAID0 для данных (без дублирования, и RAID1 для метаданных (дублирование на один диск). При использовании одного диска метаданные тоже дублируются, если вы хотите отключить это поведение можно использовать опцию -m single:

sudo mkfs.btrfs -m single /dev/sdb

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

Посмотреть информацию о только что созданной файловой системе вы можете командой:

sudo btrfs filesystem show /dev/sdb

Или обо всех подключенных файловых систем:

sudo btrfs filesystem show

Монтирование btrfs

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

sudo mount /dev/sdb /mnt

Вы можете монтировать любой из дисков, это приведет к одинаковому эффекту. Строчка в /etc/fstab будет выглядеть так:

/dev/sdb /mnt btrfs defaults 0 1

Теперь смотрим информацию о занимаемом месте на дисках:

sudo btrfs filesystem df /mnt

Сжатие в btrfs

Для включения сжатия достаточно добавить опцию compress при монтировании. Ей можно передать алгоритм lzo или zlib:

sudo mount -o compress=lzo /dev/sdb /mnt
$ sudo mount -o compress=zlib /dev/sdb /mnt

Восстановление Btrfs

Для восстановления поврежденной Btrfs используйте опцию монтирования recovery:

sudo mount -o recovery /dev/sdb /mnt

Изменение размера

Вы можете изменить размер тома в реальном времени, для этого используйте команду resize:

sudo btrfs filesystem resize -2g /mnt

Уменьшит размер на 2 гигабайта. Затем увеличим на 1 Гигабайт:

sudo btrfs filesystem resize +1g /mnt

Создание подтомов

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

sudo btrfs subvolume create /mnt/sv1
$ sudo btrfs subvolume create /mnt/sv2
$ sudo btrfs subvolume list /mnt

Монтирование подтомов

Вы можете примонтировать подтом по id, полученному с помощью последней команды:

sudo umount /dev/sdb

sudo mount -o subvolid=258 /dev/sdb /mnt

Или вы можете использовать имя:

sudo mount -o subvol=sv1 /dev/sdb /mnt

Удаление подтомов

Сначала подключите корень btrfs вместо подтома:

sudo umount /mnt

sudo mount /dev/sdb /mnt/

Чтобы удалить подтом можно использовать путь монтирования, например:

sudo btrfs subvolume delete /mnt/sv1/

Создание мгновенных снимков

Файловая система Btrfs позволяет создавать мгновенные снимки изменений. Для этого используется команда snapshot. Например, создадим файл, затем сделаем снимок:

touch /mnt/sv1/test1 /mnt/sv1/test2

Создаем снимок:

sudo btrfs subvolume snapshot /mnt/sv1 /mnt/sv1_snapshot

Оригинал: How to create and use BTRFS snapshots - Tutorial
Автор: Igor Ljubuncic
Дата публикации: 25 февраля 2012 года
Перевод: А. Кривошей
Дата перевода: апрель 2012 г.

BTRFS - это сравнительно новая файловая система, основанная на ZFS от компании Sun, которая привнесла больше всего инноваций в Unix за последние 25 лет, до ее поглощения Oracle. BTRFS до сих пор считается нестабильной, и поэтому не подходит для применения на производстве. Однако эта файловая система имеет множество полезных возможностей, которые стоит изучить. Одна из них - создание cнэпшотов системы.
Позвольте уточнить. Снэпшоты - это мгновенные снимки состояния системы. В некотором смысле, если вы копируете файл и делаете резервную копию, вы тем самым делаете его снимок, относящийся к моменту копирования. Это можно сделать в любом месте и в любое время. Подумайте о файловой системе, которая на самом деле может управлять несколькими копиями ваших файлов в рамках своей структуры, и позволяет использовать их, как вам заблагорассудится. Звучит интересно, будем исследовать.

BTRFS, введение

Перед тем, как мы начнем копать глубже, я хотел бы кратко обрисовать возможности этой файловой системы. BTRFS должна обеспечивать выполнение всех системных операций, связанных с дисками и управлением файлами, для которых обычно требуются дополнительные утилиты. BTRFS обеспечивает дефрагментацию, распределение нагрузки, уменьшение, увеличение, горячую замену, RAID, снэпшоты, сжатие, клонирование, и многие другие возможности, и все это встроено в драйвер файловой системы. С другими файловыми системами вам, вероятно, понадобится множество других драйверов и пользовательских утилит для управления всеми этими видами операций, например программа дефрагментации файловой системы, драйверы RAID и LVM, и так далее.
Встроенная функциональность означает производительность и простоту использования. Однако на данный момент BTRFS еще не полностью пригодна для использования вследствие нестабильности, а также снижения производительности по сравнению с другими файловыми системами, такими как Ext4. Но она имеет громадный потенциал, поэтому ее нельзя игнорировать, а нужно изучать.
В данном руководстве я покажу вам, как управлять снэпшотами. Это суперактуальная возможность, которая позволит вам создавать резервные копии важных файлов перед внесением в них любых изменений и затем при необходимости восстанавливать их. В некотором смысле это похоже на восстановление системы в Windows плюс драйвер отката на уровне файловой системы. Кстати, кроме снэпшотов, в этой статье можно будет также найти немного полезной информации о повседеневной работе с файловой системой BTRFS. Тестирование производилось в системе Fedora 16 Verne с рабочим столом KDE.

Как управлять BTRFS

Вы можете использовать BTRFS для корневой файловой системы за исключением /boot, которая должна быть отформатирована в традиционную журналируемую файловую систему. Для простоты в данном руководстве мы будем работать с отдельным устройством /dev/sdb1, отформатированным в BTRFS и используемым при необходимости. На практике это может быть /home или /data, или что-нибудь еще.

Итак, что мы собираемся делать?

Мы возьмем /dev/sdb1 и смонтируем его. Затем создадим несколько подразделов. Считайте подразделы виртуальными корневыми деревьями, так как любой из них представляет собой отдельную, независимую древовидную структуру данных, даже если данные те же самые.
Ниже приведена последовательность необходимых для этого команд. Не пугайтесь, мы объясним, как они работают.

$ btrfs subvolume create /mnt/data $ btrfs subvolume create /mnt/data/orig $ echo "Dedoimedo is l33t" > /mnt/data/orig/file $ btrfs subvolume snapshot /mnt/data/orig /mnt/data/backup

/dev/sdb1 смонтирован в /mnt. Мы создаем подраздел с названием data. Внутри него мы создаем другой подраздел с названием orig. А уже внутри него будут созданы наши файлы. С точки зрения пользователя подразделы выглядят как обычные директории. Другими словами, data и data/orig - это директории.
Далее, мы создаем текстовый файл в origin с названием file, содержащий некоторый текст. И в конце мы создаем снэпшот подраздела orig и называем его backup. Теперь у нас есть идентичная копия подраздела orig. Вот доказательство:

Кроме того, для проверки воспользуемся командой btrfs subvolume list , чтобы просмотреть все подразделы:

$ btrfs subvolume list

Заметьте, что каждый подраздел имеет свой номер ID. Как мы скоро убедимся, это важно.

Вид по умолчанию

В настоящее время в /mnt по умолчанию отображаются как orig, так и backup (все это в data). Мы можем это изменить. Помните, раннее я упоминал о виртуальных корневых древовидных структурах? BTRFS позволяет вам сменить виртуальную корневую директорию на любой из подразделов.
Таким образом, использование подразделов и снэпшотов означает просто переключение между различными иерархиями данных. Не нужно удалять, перезаписывать файлы, или делать что-то еще. Вы просто переключаетесь на другой подраздел. Сейчас мы увидим, как это делается.
Команда btrfs subvolume set-default ID - это все, что нам нужно. Мы установим вид по умолчанию на другой подраздел, затем отмонтируем устройство, и смонтируем его заново. Это важно!
Теперь, если вы работаете с файловой системой, которая не может быть отмонтирована, так как используется, например /usr или /etc, необходимо перезагрузить компьютер, чтобы изменения вступили в силу. Теперь в заданном дереве директорий будет отображаться другой подраздел. Пользователь не заметит разницы, но данные в директориях изменятся.
Чтобы действительно увидеть, как это работает, мы отредактируем файл file в backup. Текст Dedoimedo is l33t заменим на Dedoimedo is NOT l33t.

$ echo "Dedoimedo is NOT l33t" > /mnt/data/backup/file

Хорошо, мы знаем ID для всех подразделов. Поэтому смонтируем ID как вид по умолчанию. Это значит, что как только вы перемонтируем /mnt, мы увидим здесь файл с этим содержимым.

$ btrfs subvolume set-default 257 /mnt $ umount /mnt $ mount /dev/sdb1 /mnt

А теперь вернем все обратно:

Это можно делать столько раз, сколько нужно:

Выше мы меняли вид между 257 и 260, то есть между orig и backup, в результате мы могли просматривать содержимое измененного файла. Мы просто показывали пользователю разные подразделы.
В итоге, если мы хотим видеть как orig, так и backup в директории data, необходимо восстановить вид по умолчанию подраздела верхнего уровня, то есть data. Заметьте, что все данные отображаются в директории /mnt, поскольку мы выбрали ее в качестве точки монтирования. Однако вместо нее можно использовать любую другую директорию.

Заключение

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