Explicando melhor o problema

A função de snapshots do BTRFS é algo muito útil em qualquer situação, ela permite voltar a um ponto anterior do disco em segundos. Nós temos a ferramenta chamada TimeShift, e ela funciona bem se o seu sistema foi instalado sem nenhuma configuração especial.

O problema aparece quando, por exemplo, usamos criptografia total no disco, neste caso o TimeShift simplesmente não reconhece o sistema instalado sob BTRFS, pois ele está por debaixo de uma camada de criptografia, acredito que o mesmo aconteça caso você utilize o sistema instalado dentro de um volume lógico.

Hoje em dia, eu considero indispensável ter um computador totalmente criptografado, pois existem várias ocasiões onde o seu computador ou HDD, seja tirado de você contra a sua vontade, deixando todos os seus dados expostos, incluindo redes sociais abertas, senhas, documentos, etc. Se isso acontecer, seus dados na mão de outra pessoa vai ser uma preocupação a menos na sua vida, pois a pessoa de posse do seu HDD sem a senha mestre, não terá nada a fazer, além de formatar reinstalar o sistema nele. Nem mesmo o governo e agências de segurança conseguirão acessar seus dados (apesar deles falarem o contrário), se você tiver usando uma senha muito boa, é claro.

A instalação do Ubuntu até oferece instalação com criptografia total, mas usa o Ext4 como sistema de arquivos, neste caso, perdemos o recurso do BTRFS. Se você quer instalar o Ubuntu com criptografia total, usando o BTRFS, eu fiz um script que te ajudará no processo, ele está nesta página do GitHub:

• GitHub - dantavares/ucryptinstall: Installs any ubuntu and variant with full encryption

Sendo assim, vamos usar outra ferramenta para criar e restaurar snapshots, o Snapper. Mas infelizmente, o Ubuntu (e seus derivados), não soube utilizar uma boa configuração para utilizar o BTRFS em meu ponto de vista. E isso implica no funcionamento do Snapper. Então, não é uma falha do Snapper, e sim o Ubuntu que monta de forma errada o sistema de arquivos BTRFS, impedindo o Snapper de funcionar como deveria.

O Bug do Ubuntu

O bug do Ubuntu está na forma como ele monta o sistema BTRFS como root. Quando você instala usando o BTRFS, ele cria dois subvolumes, o "@" e o "@home" (isso se você não mandou montar o /home em outra partição), podemos ver isso ao executar o comando como root:

# btrfs sub list /

O subvolume "@" é onde está o root do sistema e a subvolume "@home" é a sua pasta Home. Isso é uma coisa boa, pois podemos trabalhar somente com subvolume "@" que nada influenciará nos seus arquivos de usuário. O problema é que, forçadamente, o Ubuntu sempre vai montar o subvolume "@" como root e vai ignorar o subvolume definido como padrão no sistema de arquivos BTRFS, deixando o sistema engessado.

Ou seja, não adianta criarmos um snapshot do "@", que na verdade é uma cópia linkada do "@", mas com os dados congelados na presente criação do mesmo, e definir este snapshot como subvolume padrão, que ele sempre irá montar o "@" como root. Tanto que ele ignora o subvolume padrão, que se você quiser ver qual subvolume padrão está definido, usando o comando como root:

# btrfs sub get-default /

...ele irá te retornar "ID 5 (FS_TREE)", o subvolume de ID 5 é o próprio root do sistema de arquivo, como ele mesmo cita "FS_TREE", ou seja, totalmente errado considerando o esquema de usar subvolumes. O subvolume padrão correto seria o "@", pois ele é montado como o root do sistema, e será a partir dele que os snapshots serão criados.

Este bug, inclusive, já foi confirmado desde 2018:

• Bug #1734496 ?snapper rollback does not work on ubuntu for btrfs...? : Bugs : snapper package : Ubuntu

Mas até a criação deste artigo, ele não foi corrigido. Ou seja, fique esperto, pois pode ser que futuramente ele seja corrigido e este artigo fique obsoleto. Uma maneira fácil de ver se este bug foi corrigido depois de anos, é verificar qual subvolume está marcado como padrão, se não for o "@", ainda continua na mesma.

Sendo assim, o próximo passo é corrigir este erro de montagem, e fazer primeiramente que o Ubuntu passe a montar o root a partir do subvolume definido como padrão, não sempre o "@".