Olá a todos,

Sim, para os que estão na duvida se leram bem, a SuSE lançou um gestor de BTRFS com o nome de um peixe.
O snapper (pargo) está disponível no openSUSE e SLES (desde o 11SP2), e é das melhores ferramentas para a gestão de BTRFS já feitas, fazendo a total integração entre a gestão do sistema no dia a dia  e o filesystem em si.

Em uma instalação básica, o snapper instala os seguintes componentes:

snapper
yast2-snapper
snapper-zypp-plugin
grub2-snapper-plugin

Descrevendo os que os pacotes contem temos:

Snapper é o pacote de que contem o software snapper em si.

Em seguida, temos os subwrappers de suporte para ferramentas de gestão da SuSE (Yast & Zypper) e é aqui que a que a integração realmente começa:

O pacote yast2-snapper cria automaticamente snapshots quando utilizar o YaST (ou ZEN) para adicionar, remover ou atualizar pacotes de software
O snapper-zypp-plugin cria automaticamente snapshots quando se usa o zypper para gerir pacotes de software.

Finalmente o grub2-snapper-plugin cria automaticamente entradas do bootloader, para que possa reverter o seu sistema para um snapshot mais velho, simplesmente reiniciando o mesmo.

Para validar estas funcionalidades, foi instalado um openSuSE 42.1 (em SLES é idêntico) em configuração default (sem LVM):

fvlab05:~ # df
Filesystem     1K-blocks    Used Available Use% Mounted on
devtmpfs          502852       0    502852   0% /dev
tmpfs             508520       0    508520   0% /dev/shm
tmpfs             508520    1540    506980   1% /run
tmpfs             508520       0    508520   0% /sys/fs/cgroup
/dev/sda2       15243264 1774952  13316472  12% /
/dev/sda2       15243264 1774952  13316472  12% /.snapshots
/dev/sda2       15243264 1774952  13316472  12% /usr/local
/dev/sda2       15243264 1774952  13316472  12% /tmp
/dev/sda2       15243264 1774952  13316472  12% /var/spool
/dev/sda2       15243264 1774952  13316472  12% /var/tmp
/dev/sda2       15243264 1774952  13316472  12% /var/log
/dev/sda2       15243264 1774952  13316472  12% /var/opt
/dev/sda2       15243264 1774952  13316472  12% /var/lib/named
/dev/sda2       15243264 1774952  13316472  12% /opt
/dev/sda2       15243264 1774952  13316472  12% /var/crash
/dev/sda2       15243264 1774952  13316472  12% /var/lib/pgsql
/dev/sda2       15243264 1774952  13316472  12% /srv
/dev/sda2       15243264 1774952  13316472  12% /var/lib/mysql
/dev/sda2       15243264 1774952  13316472  12% /var/lib/mailman
/dev/sda2       15243264 1774952  13316472  12% /var/lib/mariadb
/dev/sda2       15243264 1774952  13316472  12% /var/lib/libvirt/images
/dev/sda2       15243264 1774952  13316472  12% /home
/dev/sda2       15243264 1774952  13316472  12% /boot/grub2/i386-pc
/dev/sda2       15243264 1774952  13316472  12% /boot/grub2/x86_64-efi

Numa nova instalação de SuSE, o installer cria uma configuração de Snapper para o sistema deste a root como é visível acima.

Visualizando Configurações e Estado:

O snapper inclui um conjunto extremamente completo de comandos de consola e uma interface gráfica dentro do que seria de esperar da SuSE.
A configuração default faz automaticamente snapshots do sistema de arquivos desde a root sempre que for alterado por Zypper ou YaST.
Se efetuarmos o comando snapper list-configs para ver nossas configurações existentes teremos algo como o demonstrado seguidamente:

fvlab05:~ # snapper list-configs
Config | Subvolume
——-+———-
root   | /    

Imaginemos agora que queremos instalar software neste servidor:

fvlab05:~ # zypper install xclock
Loading repository data…
Reading installed packages…
Resolving package dependencies…

The following 8 NEW packages are going to be installed:
libXaw7 libXft2 libXmu6 libXpm4 libXrender1 libxkbfile1 xbitmaps xclock
…

Depois de completar a instalação,  podemos validar que a operação foi detetada e a mesma surge em consola ou Yast2:

fvlab05:~ # snapper list
Type   | #  | Pre # | Date                     | User | Cleanup | Description           | Userdata     
——-+—-+——-+————————–+——+———+———————–+————–
single | 0  |       |                          | root |         | current               |              
single | 1  |       | Wed Jan 13 23:54:10 2016 | root |         | first root filesystem |              
single | 2  |       | Thu Jan 14 00:00:04 2016 | root | number  | after installation    | important=yes
pre    | 3  |       | Thu Jan 14 00:03:01 2016 | root | number  | zypp(zypper)          | important=yes
post   | 4  | 3     | Thu Jan 14 00:09:55 2016 | root | number  |                       | important=yes
pre    | 5  |       | Thu Jan 14 00:41:55 2016 | root | number  | zypp(zypper)          | important=no
post   | 6  | 5     | Thu Jan 14 00:42:00 2016 | root | number  |                       | important=no
pre    | 7  |       | Thu Jan 14 00:45:37 2016 | root | number  | yast snapper          |              
post   | 8  | 7     | Thu Jan 14 00:54:29 2016 | root | number  |                       |              
pre    | 9  |       | Thu Jan 14 01:00:06 2016 | root | number  | yast snapper          |              
post   | 10 | 9     | Thu Jan 14 01:01:50 2016 | root | number  |                       |         

Utilizando o Yast2 (consola) os snapshots são igualmente visíveis:

Definindo, os snapshots antes de alterações serem efetuadas (pelo funcionamento do YaST e do Zypper) tem o type Pre e os snapshots marcados como Post são efetuados depois depois.

Snapshots marcados com single são snapshots atómicos; São o tipo de snapshot que o administrador faz manualmente, ou automaticamente através do cron.

Cada snapshot tem um número de identificação e data e hora.

Por defeito (é um padrão definível em /etc/snapper/configs/root), apenas os 100 snapshots mais recentes são mantidos.
Quando este valor é excedido, os snapshots mais antigos são automaticamente excluídos e apagados.

Podemos navegar nos menus, até ao snapshot que nos interessa e ver as alterações (no nosso caso vamos ver o 5 &6). O anterior é um zypper update geral:

Voltando ao output de consola, temos:

fvlab05:~ # snapper list
Type   | #  | Pre # | Date                     | User | Cleanup | Description           | Userdata     
——-+—-+——-+————————–+——+———+———————–+————–
single | 0  |       |                          | root |         | current               |              
single | 1  |       | Wed Jan 13 23:54:10 2016 | root |         | first root filesystem |              
single | 2  |       | Thu Jan 14 00:00:04 2016 | root | number  | after installation    | important=yes
pre    | 3  |       | Thu Jan 14 00:03:01 2016 | root | number  | zypp(zypper)          | important=yes
post   | 4  | 3     | Thu Jan 14 00:09:55 2016 | root | number  |                       | important=yes
pre    | 5  |       | Thu Jan 14 00:41:55 2016 | root | number  | zypp(zypper)          | important=no

Explicando:

A coluna Cleanup indica que tipo de algoritmo de limpeza que é usada.

O # apresenta o valor do snapshot (lembrar a capacidade máxima pré definida de 100).
É importante lembrar que quando o administrador de sistemas cria um snapshot, é importante não se esquecer de definir um valor especifico de Cleanup de forma a não ser excluído automaticamente quando a sua vez chegar.

O campo Userdata contém comentários arbitrárias em um formato par key = value, e você pode deixar este campo em branco ou digitar algum texto, por exemplo notas sobre a necessidade que originou o snapshot.

Aplicativos práticos da tecnologia:

Vamos agora demonstrar uma capacidade importante de snapshot on demand, por exemplo para plataformas aplicacionais que residam em continuous integration, por exemplo com Jenkins:

Para a demonstração corrente, iremos utilizar o /srv que é onde reside a nossa aplicação com deployment automático todas as madrugadas de segunda.

Em primeiro lugar temos de inicializar a configuração:

fvlab05:~ # snapper -c application create-config /srv

Os novos arquivos de configuração são criados desde o template primário que está em /etc/snapper/conf-templates/default. Todos  os arquivos de configuração do snapper são user-friendly e em ASCII pelo que podem ser editados manualmente com o VI ou com outra ferramenta de edição de texto a escolha.

Validando o nosso comando anterior temos:

fvlab05:~ # snapper -c application list
Type   | # | Pre # | Date | User | Cleanup | Description | Userdata
——-+—+——-+——+——+———+————-+———
single | 0 |       |      | root |         | current     |       

Como proposto anteriormente,  existe a necessidade de garantir por snapshot a aplicação residente no filesystem antes do próximo deployment, na madrugada de segunda feira.

É altura portanto, de configurar um snapshot on-demand:

fvlab05:~ # snapper -c application create -d “application pre-deployment snap” -c number -u day=Sunday

Validando (snapper -c application list) o snapshot já aparece, com a descrição definida – application pre-deployment snap – e o dia em que o snapshot irá correr – domingo:

fvlab05:~ # snapper -c application list
Type   | # | Pre # | Date                     | User | Cleanup | Description                     | Userdata
——-+—+——-+————————–+——+———+———————————+———–
single | 0 |       |                          | root |         | current                         |
single | 1 |       | Sun Jan 17 02:32:15 2016 | root | number  | application pre-deployment snap | day=Sunday

O que fazer se correu mal?

Vamos imaginando que algo correu mal com a integração aplicacional, e temos que efetuar rollback das alterações que foram efetuadas:

Nota: A SuSE recomenda que para este tipo de manobra seja usado o Yast2.

Em primeiro lugar, procurar no Yast2 – Secção Snapper – A configuração escolhida (no nosso caso application) – Está num drop down menu no canto superior esquerdo:

Entrar no snapshot que nos interessa, neste caso o 1, e selecionar restore – canto inferior direito:

Irá surgir o seguinte alerta quando pedirmos a tarefa de restore:

Após a confirmação, o snapshot tera revertido ao original de quando foi criado.

Outro exemplo extremamente útil será a reposição de um snapshot pós patching de um sistema, por exemplo quando se deteta que algo não correu como esperado.

Assim sendo, efetuar:

fvlab05:~ # snapper rollback

Creating read-only snapshot of default subvolume. (Snapshot 16.)
Creating read-write snapshot of current subvolume. (Snapshot 17.)
Setting default subvolume to snapshot 17.

fvlab05:~ # reboot

Após o servidor completar o ciclo de reboot iremos ter uma nova opção no nosso Grub:

Com esta opção, iremos poder aceder aos snapshots efetuados previamente no nosso BTRFS:

Após escolhermos, o sistema irá voltar ao ponto em que desejamos e o snapshot foi efetuado.

Nota: É necessário ter os snapshots ativados de BTRFS antes de se efetuarem quaisquer alterações. Tentar fazer snapshots depois do problema já ter acontecido, não dará hipótese de rollback.

Concluindo a SuSE e a sua comunidade, através do snapper, conseguiram criar uma ferramenta excelente de gestão de BTRFS que irá certamente dar cartas pela sua utilidade out-of-the box como estamos habituados em ferramentas de virtualização empresarial.

Sublinho que todas as características apresentadas são completamente suportadas ao nível empresarial em SLES (SuSE Enterprise), pelo que são production safe e podem ser usadas com segurança em ambiente Empresarial.

Como sempre, se tiverem alguma duvida já sabem onde me encontrar.
Até á próxima.