Управление файловой системой Btrfs в Termux: создание субтомов, снапшотов и дедупликация данных на Android‑устройстве

Android‑устройства давно стали удобной средой для администрирования и экспериментальной инженерии, а Termux — практичным инструментом для работы в консоли. Когда возникает задача “приблизить” подходы из Linux к повседневной работе с файлами на телефоне, полезно рассмотреть Btrfs: он поддерживает субтомы (subvolumes), снапшоты (snapshots) и механизмы экономии пространства через дедупликацию (в зависимости от выбранного инструмента и конфигурации).

В этой статье разберём практический подход к управлению Btrfs в Termux: как подготовить среду, создать субтомы, сделать снапшоты, выполнить откат и оценить варианты дедупликации данных с учётом особенностей Android и прав доступа.

Важно про ограничения Android и права

Чтобы Btrfs реально работала на вашем устройстве, должны быть выполнены условия платформы: ядро и/или среда исполнения должны поддерживать Btrfs, а права должны позволять монтировать и управлять файловой системой. На части устройств Btrfs может быть недоступна без root, а иногда требуется загрузка собственного ядра или использование специальных сборок.

Termux в общем случае предоставляет пользовательское пространство, поэтому сценарии с Btrfs обычно строят вокруг одного из подходов:

Использование уже смонтированного Btrfs (если в системе есть раздел/образ с Btrfs).
Работа с файловой системой внутри образа (loop‑устройство). В ряде случаев loop‑монтирование и монтирование образа потребуют повышенных прав.
Субтомы и снапшоты — выполняются на смонтированном Btrfs и обычно требуют прав владельца или root (зависит от модели прав).

Если вы планируете дедупликацию и/или операции обслуживания (TRIM, balance, scrub) — заранее проверьте, что ядро и утилиты поддерживают нужные возможности.

Подготовка Termux: зависимости и базовая проверка

Начнём с обновления пакетов и установки утилит Btrfs. В Termux версии пакетов могут отличаться, поэтому команды отражают типовой сценарий.

pkg update
pkg upgrade -y
pkg install btrfs-progs util-linux -y

Далее полезно убедиться, что утилиты доступны и команда btrfs работает.

btrfs --version

Теперь определите, где у вас смонтирована Btrfs‑файловая система. Для этого удобно посмотреть типы ФС и точки монтирования.

mount | head -n 50
df -T

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

Структура: субтомы как “папки с преимуществами”

Btrfs субтомы — это сущности, которые выглядят как каталоги, но на файловом уровне являются отдельными корнями дерева данных. Субтомы удобны для:

разделения данных по назначению (например, home, projects, backup);
создания снапшотов “снэпшот-веток” без остановки работы;
быстрого отката к предыдущему состоянию.

Перед созданием субтомов важно понимать, что Btrfs имеет “subvolume ID 5” — базовый уровень (обычно referred as the top-level). Практика: создавать отдельные субтомы, а не работать напрямую в top-level.

Создание субтомов

Допустим, ваша Btrfs смонтирована в каталог /mnt/btrfs. Ниже показан пример, как создать набор субтомов и сразу задать им понятные имена.

export BTRFS_MNT=/mnt/btrfs

# Создаём субтомы
sudo btrfs subvolume create $BTRFS_MNT/@
sudo btrfs subvolume create $BTRFS_MNT/@home
sudo btrfs subvolume create $BTRFS_MNT/@projects
sudo btrfs subvolume create $BTRFS_MNT/@snapshots

Если команда sudo недоступна в вашей среде, значит требуются права пользователя на уровне точки монтирования или иные способы доступа. Логика операций остаётся той же: вы должны иметь права на создание subvolume.

Посмотреть список субтомов удобно так:

sudo btrfs subvolume list $BTRFS_MNT

Монтаж субтомов (если требуется)

Субтом можно монтировать отдельно, чтобы система/скрипт работали только с нужной областью. В Termux обычно это выполняют пользовательно-ручным способом, но общий принцип такой: используйте опции монтирования с указанием subvol.

Например, создадим точки монтирования внутри Termux.

mkdir -p /data/btrfs-top /data/btrfs-home /data/btrfs-projects

# Пример: монтирование субтомов (потребует прав на монтирование)
sudo mount -t btrfs -o subvol=@home $BTRFS_MNT /data/btrfs-home
sudo mount -t btrfs -o subvol=@projects $BTRFS_MNT /data/btrfs-projects

Примечание: на Android монтирование может быть ограничено, и ваш сценарий может потребовать root или заранее подготовленной среды.

Создание снапшотов: простые и с “копированием”

Снапшоты Btrfs бывают разного типа. В большинстве практических задач используют:

Read-only snapshot: защитный вариант для бэкапов/точек восстановления.
Read-write snapshot: если нужно продолжать работу в “ветке”, сохраняя возможность сравнения и возврата.

Создадим снапшот субтома @projects в каталог @snapshots. Допустим, @snapshots уже создан.

export SNAP_BASE=$BTRFS_MNT/@snapshots

# Название снапшота можно timestamp-ить
SNAP_NAME=snap-projects-$(date +%Y%m%d-%H%M%S)

# Read-only снапшот (рекомендуется для точек отката)
sudo btrfs subvolume snapshot -r $BTRFS_MNT/@projects $SNAP_BASE/$SNAP_NAME

Посмотреть снапшоты и субтомы:

sudo btrfs subvolume list $SNAP_BASE | tail -n 50

Восстановление (откат) к снапшоту

Откат — это то, ради чего снапшоты и нужны. Существует несколько стратегий, но важно не “смешивать” данные. Один из подходов — временно заморозить текущие данные, а затем развернуть снапшот.

Например, если вы хотите заменить текущий @projects на выбранный снапшот, действуйте аккуратно:

убедитесь, что вы выбираете правильный снапшот;
сделайте backup текущего состояния (хотя бы ещё один снапшот);
выполняйте операции на уровне субтомов.

Пример сценария (замена read-write субтома на состояние снапшота):

# 1) Создадим снапшот “сейчас”, чтобы можно было откатиться ещё раз
NOW_SNAP=snap-projects-pre-restore-$(date +%Y%m%d-%H%M%S)
sudo btrfs subvolume snapshot -r $BTRFS_MNT/@projects $SNAP_BASE/$NOW_SNAP

# 2) Допустим, выбранный снапшот называется $RESTORE_SNAP
RESTORE_SNAP=snap-projects-20260723-101530

# 3) Удалим текущий @projects и пересоздадим его из снапшота
sudo btrfs subvolume delete $BTRFS_MNT/@projects
sudo btrfs subvolume snapshot $SNAP_BASE/$RESTORE_SNAP $BTRFS_MNT/@projects

После этого ваши данные в @projects будут соответствовать состоянию снапшота.

Важно: если вы монтировали @projects отдельно в другую точку, убедитесь, что монтирование актуально (иногда после операций субтомов требуется перемонтирование).

Удаление снапшотов и контроль использования пространства

Удаление снапшотов освобождает пространство при соблюдении условий Btrfs (copy-on-write и ссылки на общие блоки). Основной принцип: чем меньше общих “ссылок” на данные, тем больше высвобождение.

Удаление read-only снапшота:

sudo btrfs subvolume delete $SNAP_BASE/$RESTORE_SNAP

Оценить использование пространства можно так:

df -h
sudo btrfs filesystem usage $BTRFS_MNT

Дедупликация: что реально возможно в контексте Termux

Под “дедупликацией” в Btrfs часто подразумевают разные техники. Ключевой момент: встроенная дедупликация в стиле “склейка одинаковых блоков в единую копию” не всегда доступна “из коробки” именно на Btrfs, а набор доступных механизмов зависит от:

версии ядра;
сборки утилит;
разрешений и режима работы (обычный пользователь vs root);
типа носителя и режима TRIM/IO.

На практике в задачах “снижения объёма” часто используют два направления:

Снапшоты и CoW: при одинаковых данных между снапшотами Btrfs экономит место за счёт shared blocks (это не дедупликация “по файлам”, но на практике даёт похожий эффект).
Инструментальная дедупликация на уровне блоков/файлов через сторонние утилиты. Такой подход зависит от наличия утилит в Termux и совместимости с вашей системой.

Практический вариант экономии вместо “агрессивной дедупликации”

Если у вас цель — уменьшить объём при хранении множества версий проектов, снапшоты Btrfs часто дают наилучшее соотношение “эффект/риск”. Поэтому “первой линией” можно считать:

хранение версий в субтомах;
создание read-only снапшотов для контрольных точек;
ограничение частоты снапшотов и применение политики хранения (например, “держать последние N и ежедневные M”);
удаление старых снапшотов по расписанию.

Это позволяет добиваться эффекта дедупликации за счёт механизма copy-on-write и общих блоков.

Если всё же нужна дедупликация “в лоб”: общая стратегия тестирования

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

выберите небольшой тестовый набор (лучше создать отдельный субтом под эксперименты);
проведите оценку до/после через btrfs filesystem usage и df;
не выполняйте потенциально разрушительные операции на “боевых” данных без возможности отката (снапшоты обязательны);
учитывайте нагрузку: дедупликация может быть ресурсоёмкой.

Пример: создаём отдельный субтом для теста и делаем снапшот “до”.

sudo btrfs subvolume create $BTRFS_MNT/@dedup-test
TEST_SNAP=snap-dedup-test-before-$(date +%Y%m%d-%H%M%S)
sudo btrfs subvolume snapshot -r $BTRFS_MNT/@dedup-test $SNAP_BASE/$TEST_SNAP

# Далее размещайте тестовые данные в @dedup-test
# и проводите выбранную вами процедуру дедупликации
# (команды зависят от доступного инструмента/ядра)

После процедуры снова смотрите объём и готовность к откату.

sudo btrfs filesystem usage $BTRFS_MNT
df -h

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

Пример практического набора команд: полный цикл

Ниже компактный пример, объединяющий идеи статьи: создание снапшота, тест изменений и откат при необходимости.

export BTRFS_MNT=/mnt/btrfs
export SNAP_BASE=$BTRFS_MNT/@snapshots

# Точка восстановления перед изменениями
PRE_SNAP=snap-projects-pre-change-$(date +%Y%m%d-%H%M%S)
sudo btrfs subvolume snapshot -r $BTRFS_MNT/@projects $SNAP_BASE/$PRE_SNAP

# Далее вы вносите изменения в данные в $BTRFS_MNT/@projects
# ...

# Если нужно откатить
sudo btrfs subvolume delete $BTRFS_MNT/@projects
sudo btrfs subvolume snapshot $SNAP_BASE/$PRE_SNAP $BTRFS_MNT/@projects

Заключение

Управление Btrfs в Termux на Android может стать эффективным способом организовать данные как “управляемые версии”: субтомы дают структуру, снапшоты — точки восстановления и экономию места за счёт copy-on-write. А подход к дедупликации стоит выстраивать осторожно: во многих сценариях на практике первичный выигрыш даёт именно архитектура снапшотов и shared blocks, а любые агрессивные методы дедупликации требуют тестирования на отдельном субтоме и наличия поддержки на уровне ядра/утилит.

Если хотите подобрать схему под ваше устройство (модель, требования к правам, тип носителя и цель по экономии/восстановлению), специалисты РыбинскЛАБ помогут спроектировать рабочий сценарий и проверить совместимость в безопасном режиме.