Bom, como eu disse desde ontem eu já estou fuçando plenamente no EXT3COW, um sistema de arquivos para o Linux, baseado no EXT3, que é totalmente versionado.
Primeiro, vamos entender o que significa um sistema de arquivos versionado. Para quem mexe com programação, pode-se entender o sistema de arquivos versionado, como um CVS ( ou SVN ), só que dos arquivos que estão no disco. Ou seja, cada mudança do sistema de arquivos seria guardada em um log, onde o arquivo poderia ser recuperado no momento em que fosse necessário pelo administrador.
Ainda não vou entrar na síntese técnica, ou seja, na explicação via kernel e código do que seria isto, mas na realidade, na prática, seria poder voltar um momento do seu sistema operacional, sem ter que ficar procurando a fita onde está o arquivo que aquele usuário descuidado deletou.
Bem, quando falamos do ext3cow, ele é a primeira tentativa, no mundo Linux de implementar um sistema de arquivos nativo, que consiga fornecer a possibilidade dos snapshots.
O ZFS ( ZETA FILESYSTEM ) da Sun, disponível no Linux via ZFS-FUSE, fornece isto também, mas não é nativo ao kernel, como o ext3cow é ... o que em termos de velocidade, pode até ser que seja melhor ( o ZFS-FUSE já está na lista para testes, como eu também já disse ).
Nestas primeiras 24 horas com este sistema de arquivos, notei que ele é estável. Submeti o mesmo a trocentas cópias, deleções, recuperações e testes infindáveis e o mesmo está lá, firme e forte ( já estou inclusive pensando em passar a minha partição home para ext3cow ), sem causar nenhuma queda eminente do sistema operacional.
Lendo um artigo no site ALL ABOUT LINUX, vi um jeito interessante de se entender o que é o EXT3COW, na prática.
root@matrix:/home/arquivao# vim teste.txt
root@matrix:/home/arquivao# cat teste.txt
ESTE É O TEXTO ORIGINAL
root@matrix:/home/arquivao# ss
Snapshot on .: 1189289168
Atente para o número no final. Ele é o unique number, ou seja, o id do snapshot que tiramos do sistema de arquivos neste momento. Os arquivos e seu estado naquele momento X, estão todos guardados em um log de mudanças que o próprio kernel/sistema de arquivos gerenciam ( não me perguntem ainda como funciona como um todo, pois eu ainda não fucei em todas as documentações ).
root@matrix:/home/arquivao# echo "MUDEI A SENTENÇA ORIGINAL" > teste.txt
root@matrix:/home/arquivao# cat teste.txt
MUDEI A SENTENÇA ORIGINAL
Em um ambiente real, seria um usuário ou algum comando acidental, gerando a mudança de um arquivo que não poderia ter sido realmente mudado. Aí, para salvar o momento, é só ter em mãos o unique number ( id ) do snapshot e mandar bala :
root@matrix:/home/arquivao# cat teste.txt@1189289168
ESTE É O TEXTO ORIGINAL
O que é mostrado com este teste simples, é a grande utilidade de se ter um sistema de arquivos versionado. A realidade, é que se tem diversos retratos de um mesmo local, que podem recuperar pequenas coisas em menor tempo do que seria a recuperação de um backup.
Mas aí, fiquei pensando, e se for um diretório ? Será que a coisa funciona do mesmo jeito ?
Mão na massa, e novamente fiz os testes :
bash-3.1# ls adore1
CVS README ava.c dummy.c startadore
LICENSE TODO cleaner.c libinvisible.c
Makefile.gen adore.c configure libinvisible.h
bash-3.1# ss
Snapshot on .: 1189297250
bash-3.1# rm -rf adore1
bash-3.1# cp -rp adore1@1189297250 adore1
bash-3.1# ls adore1
CVS README ava.c dummy.c startadore
LICENSE TODO cleaner.c libinvisible.c
Makefile.gen adore.c configure libinvisible.h
Ou seja, com a série de comandos acima, é provado que funciona também com diretórios, o que é uma mão na roda :-)
Mas, para usar estas funcionalidades, deve ser lembrado ao administrador que o snapshot do sistema de arquivos não é automático, sendo necessário um cron para gerar este snapshot de x em x minutos.
Criei aqui, para um gerenciamento mais rápido, um crontab do seguinte modo :
#!/bin/sh
date >> /var/log/snapshots
cd /home/arquivao
/sbin/ss >> /var/log/snapshots
O resultado do comando comando em questão gera um log deste formato :
Sat Sep 8 19:19:05 BRT 2007
Snapshot on .: 1189289945
O que por sua vez, facilita a recuperação dos arquivos quando forem necessários, já que há um grande problema relacionado ao ext3cow. Por ser um projeto novo, ainda há uma carência de ferramentas para listar, gerenciar, trabalhar com os snapshots gerados.
Uma bem interessante, citada inclusive no artigo é o TIME TRAVELING FILE MANAGER, mas que ainda apresenta muitos bugs, principalmente quando se tentar operar com ele em um sistema de arquivos já em produção ( como o meu /home/arquivao ).
Assim, só posso dizer que este sistema de arquivos é, sinceramente, super legal. Mas, ainda preciso fuçar todas as documentações, para, em breve, colocar aqui um bom post sobre como trabalhar, realmente, e profissionalmente, com este sistema de arquivos, que torna o Linux uma ferramenta cada vez melhor para ambientes grandes e pequenos no mundo inteiro :-)