Чем ещё может быть полезно для нас использование такой вещи как подтома btrfs?
Недавно мы установили Манджаро Линукс с помощью программы Manjaro Architect. Напомню, что мы установили систему на файловую систему btrfs с использованием подтомов. Преимуществом Архитектора является то, что он устанавливает систему на btrfs абсолютно корректно, и для дальнейшей нормальной работы не требуется никаких дополнительных настроек. А установка системы с использованием подтомов позволяет использовать снапшоты (снимки) файловой системы. При установке системы также автоматически устанавливается пакет grub-btrfs, что даёт возможность загружаться с созданных снапшотов также без дополнительных настроек.
Для начала…
Если верить АрчВики, подтом не является блочным устройством, но в каждом томе btrfs создаётся один подтом верхнего уровня (ID 5), в этом подтоме могут создаваться другие подтома и снапшоты.
А снапшот (снимок) — это просто подтом, который делит свои данные с другим подтомом. Название «снимок» хорошо объясняет суть снапшота: это снимок файловой системы определённого подтома на определённый момент времени. Места на диске такой «снимок» занимает совсем немного (это, впрочем, зависит от того, насколько сильно меняются данные на диске).
Для нас же важно то, что подтома могут иметь сложную иерархию, они могут быть смонтированы в файловую систему, система может работать с ними почти также, как с обычными каталогами. Их можно даже перемещать.
Архитектор, напомню, в автоматическом режиме создаёт четыре подтома: @ — для корневого каталога, @home — для /home, @cache — для /var/cache и @snapshots — для хранения снапшотов, который автоматически не монтируется. Я же чуть меняю эту схему в ручном режиме: если для @ и @home ничего не меняется, то @snapshots я монтирую в /.snapshots, а @cache — в /var/cache/pacman. То есть я выношу в @cache только кэш pacman, поскольку очевидно, что архивировать его нет смысла. В то же время я могу допустить, что в папке /var/cache вполне может быть и полезная информация.
При работе с подтомами и снимками важно помнить об их иерархии. Например, если вы хотите восстановить данные из снапшота, смотрите, куда будете их копировать. При невнимательной работе можно скопировать файлы совсем не туда, куда нужно, а допущенную ошибку не всегда можно исправить (особенно если вы будете не копировать, а перемещать данные командой mv).
Для работы с подтомом верхнего уровня нужно загрузиться с загрузочной флешки и смонтировать ваш раздел btrfs (а не его подтома) в папку (например, /mnt). Впрочем, об этом позже.
Как создать снапшот?
Краткую справку о том, как использовать подтома и снапшоты btrfs можно получить с помощью команды btrfs. Так, команда
btrfs subvolume
выведет справку по управлению подтомами, а команда
btrfs subvolume snapshot
расскажет о создании снапшота
Итак, как же создать снапшот подтома? Это просто, нужна только одна команда:
sudo btrfs subvolume snapshot / /.snapshots/my_system
Здесь создаётся снапшот подтома @ (который, напомню, смонтирован в корневой каталог), который будет записан в папку /.snapshots/my_system.
Если мы теперь дадим команду
sudo btrfs subvolume list /
то увидим, что у нас появился новый снапшот в подтоме @snapshots, а если мы откроем файловым менеджером папку /.snapshots/my_system (вы не забыли включить режим отображения скрытых файлов?), то убедимся, что снапшот внешне очень похож на обычный каталог (и, как мы вскоре увидим, на подтом). А это значит, что если мы создадим снапшот подтома @home
sudo btrfs subvolume snapshot /home /.snapshots/my_data
то в папке /.snapshots/my_data будем иметь копию наших данных в папке /home. То есть, если вы (после создания снапшота, естественно!) удалили (или неудачно отредактировали) файл, который хранится в домашней папке, то всё, что вам нужно сделать, это зайти в папку со снапшотом и скопировать оттуда нужный файл.
А вот такая команда
sudo btrfs subvolume snapshot -r / /.snapshots/my_system
создаст снапшот, доступный только для чтения. Нужно ли это делать — решать вам, нужно только сказать, что если вы хотите иметь возможность загрузки в снапшот, то ключ -r лучше не использовать.
После создания снимка системного раздела нужно также ещё дать команду
sudo update-grub
Теперь grub увидит ваши снапшоты, и, после перезагрузки системы, вы можете в меню grub загрузиться с этого снапшота. Таким образом, получается очень простой алгоритм действий при обновлении системы:
- Создать снимок системы;
- Обновить систему;
- Проверить работоспособность обновлённой системы, если всё в порядке — спокойно работать дальше;
- Если что-то пошло не так — загрузиться в сделанный заранее снапшот.
- Если всё в порядке — откатить систему. Если и здесь что-то не так — значит, проблема в чём-то другом, дальше последует либо поиск причин, либо (по привычке, унаследованной от Windows) — переустановка системы :((.
Автоматизация процесса
У ручного создания снапшотов есть только один недостаток: по какой-то непонятной причине вы, скорее всего, забудете сделать снимок системы именно перед тем обновлением, которое и убьёт вашу систему (в стабильной ветке Манджаро вероятность такого обновления исчезающе мала, но закон подлости и следствия закона Мерфи никто ещё не отменял…).
Для автоматического создания снапшотов можно использовать специальные программы, например, Snapper. Эта программа позволяет создавать снапшоты и управлять ими, но мне она показалась несколько запутанной. Например, при настройках по умолчанию она начинает создавать снапшоты системы каждый час, а сам процесс настройки мне показался не очень понятным.
Но в Интернете можно найти большое количество скриптов, выполняющих ту же задачу. Я потратил на поиск некоторое время и довольно быстро нашёл то, что мне нужно.
Вот здесь можно скачать скрипт, который не только создаёт снимки btrfs, но и умеет удалять ранее созданные, но уже устаревшие. К скрипту прилагается и файл справки. Для его использования нужно:
- Скачать скрипт;
- Распаковать его;
- Сделать скрипт исполняемым (с помощью файлового менеджера или из командной строки).
Теперь можно опробовать его в действии. Если скрипт находится в папке /home/data/btrfs-snapshot, то команда
sudo /home/data/btrfs-snapshot/btrfs-snapshot / /.snapshots daily 8
создаст в папке /.snapshots снимок файловой системы (подтом @) с именем типа 2018-01-15—09-31-43-@daily. То есть предполагается, что это — ежедневный снимок (daily), и в папке их должно быть не более восьми. По мере добавления новых снимков старые будут удаляться.
Единственный недостаток этого скрипта — он создаёт снапшоты, доступные только для чтения. Однако попытка загрузиться с такого снимка закончится ошибкой (у меня, по крайней мере, было именно так). Поэтому я немного поправил скрипт: в строке 73 в команде создания нового снапшота я просто убрал ключ -r, вы можете сделать так же.
Осталось сделать так, чтобы скрипт запускался регулярно. В справочном файле есть информация о том, как настроить для этого cron. Я, например, добавил в файл /etc/anacrontab такие строки:
1 10 daily_snap /home/data/btrfs-snapshot/btrfs-snapshot / /.snapshots daily 8
7 20 weekly_snap /home/data/btrfs-snapshot/btrfs-snapshot / /.snapshots weekly 5
1 30 update_grub update-grub
Первые две строки создают ежедневный и еженедельный снимки системы. Третья строчка, как вы, конечно, поняли, обновляет меню grub.
Теперь каждый день, через некоторое время после включения компьютера (обычно утром), у меня создаётся ежедневный снимок системы, а раз в неделю — еженедельный.
Достаточно ли такого количества снимков, нужны ли снимки месячной и более давности, нужно ли делать ежемесячные снимки — пусть каждый решит для себя сам. Аналогичным образом можно автоматизировать создание снимков не только системы, но и данных. Кстати, периодичность создания снимков определяется не скриптом, а периодичностью запуска скрипта. daily и weekly — это только часть имени снапшота, она, правда, используется скриптом для подсчёта количества снапшотов.
Спасательная операция
Но что же делать, если, например, обновление системы прошло неудачно, вы перезагрузились в последний снапшот и убедились, что всё в порядке. Как обычно, в Интернете есть разные рецепты решения этой задачи, я, на данный момент, пришёл к следующему:
- Загружаемся с установочного диска Манджаро (или другого дистрибутива);
- Запускаем терминал (в Манджаро KDE можно нажать F12 и вызвать окно yakuake).
- Начинаем вводить команды:
sudo mount /dev/sda2 /mnt
3.1 Монтируем раздел btrfs в папку /mnt. Ваш раздел может быть другим! Если монтирование прошло успешно, то можно дополнительно открыть папку /mnt в файловом менеджере, чтобы контролировать процесс.
sudo btrfs subvolume list /mnt
ID 257 gen 97 top level 5 path @
ID 258 gen 97 top level 5 path @home
ID 259 gen 92 top level 5 path @cache
ID 260 gen 79 top level 5 path @snapshots
ID 264 gen 22 top level 257 path @/var/lib/machines
ID 265 gen 79 top level 260 path @snapshots/system
3.2 Проверяем подтома и снапшоты. Наша задача — скопировать файлы из снимка @snapshots/system в подтом @.
sudo mv /mnt/@ /mnt/@oldsys
sudo btrfs subvolume list /mnt
ID 257 gen 97 top level 5 path @oldsys
ID 258 gen 97 top level 5 path @home
ID 259 gen 92 top level 5 path @cache
ID 260 gen 79 top level 5 path @snapshots
ID 264 gen 22 top level 257 path @oldsys/var/lib/machines
ID 265 gen 79 top level 260 path @snapshots/system
3.3 Переименовываем /mnt/@ в /mnt/@oldsys (название может быть другим). Как видим, подтом можно просто переименовать, почти как обычную папку (но id не меняется!). Ещё раз повторюсь: будьте внимательны!
sudo mv /mnt/@snapshots/system /mnt/@
sudo btrfs subvolume list /mnt
ID 257 gen 97 top level 5 path @oldsys
ID 258 gen 97 top level 5 path @home
ID 259 gen 92 top level 5 path @cache
ID 260 gen 79 top level 5 path @snapshots
ID 264 gen 22 top level 257 path @oldsys/var/lib/machines
ID 265 gen 79 top level 5 path @
3.4. А теперь перемещаем (фактически — переименовываем) наш снапшот в /mnt/@ (а именно эта папка будет потом смонтирована как корневой каталог!).
sudo mv /mnt/@oldsys/var/lib/machines /mnt/@/var/lib
sudo btrfs subvolume list /mnt
ID 257 gen 97 top level 5 path @oldsys
ID 258 gen 97 top level 5 path @home
ID 259 gen 92 top level 5 path @cache
ID 260 gen 100 top level 5 path @snapshots
ID 264 gen 22 top level 265 path @/var/lib/machines
ID 265 gen 79 top level 5 path @
3.5. Возвращаем на место подтом @/var/lib/machines. Если честно, этот шаг вызывает у меня сомнение. Подтом @/var/lib/machines создаётся системой автоматически, он нужен системе для обеспечения работы виртуальных машин. Нужно ли (и можно ли) переносить его вручную? Я пока не смог найти точную информацию об этом, поэтому не знаю, насколько корректен этот шаг.
sudo nano /mnt/@/etc/fstab
3.6. И последний шаг. Редактируем файл /etc/fstab нашей системы. Нужно изменить параметры монтирования корневого каталога (заменить его id, в данном случае с 257 на 265). В принципе, система должна загрузиться и без этого (в fstab указаны имена подтомов, которые используются grub), но не будем рисковать и путать самих себя.
На этом всё. Остаётся размонтировать нашу файловую систему и перезагрузить компьютер.
И в результате…
…систему мы восстановили. Весь процесс займёт не больше десяти минут. Оставшийся на диске подтом @oldsys можно удалить позже. Для этого можно снова загрузиться с установочного диска, смонтировать файловую систему и скомандовать:
sudo btrfs subvolume delete /mnt/@oldsys
При всём сходстве подтомов и снапшотов с папками для их удаления (в отличие от переименования) требуется специальная команда.
Обратите внимание, что мы восстановили только систему, но не данные, поэтому после загрузки в восстановленную систему возможны некоторые небольшие сюрпризы. Например, если после создания снапшота вы установили Libre Office, то после восстановления из снапшота самого офисного пакета мы в системе не найдём, а вот ярлыки для запуска программ в меню приложений KDE останутся. Эта проблема, впрочем, решается очень просто.
Снапшоты btrfs, как мы видим, хорошо защищают систему от неудачного обновления, а ваши данные — от неосторожного удаления или неудачного редактирования. Но от серьёзного сбоя файловой системы или от отказа диска они, конечно, не спасут, тут нужны другие средства. Вряд ли что-то сохранит ваши данные лучше копирования на внешний носитель или в облако (но даже этот способ не является идеальным — не каждое облачное хранилище / программа резервного копирования умеют работать с версиями файла, так что лучше использовать несколько способов резервного копирования).
Впрочем, btrfs имеет и механизм передачи снапшотов на другой диск, но это уже другая история…
Максим Перехрест