Snapshots são importantes quer esteja a executar uma máquina virtual simples no seu computador de casa ou se é uma base de dados empresarial que está constantemente a ser actualizada e modificada. Ter snapshots, ou seja, uma cópia de todo o sistema de arquivos como era em um determinado período de tempo é importante.
As pessoas frequentemente perdem a noção de onde as coisas deram errado, um arquivo foi deletado e ninguém notou que ele tinha desaparecido. Vários backups passaram e agora você percebe que um arquivo importante está faltando em todos os backups disponíveis das últimas 5 semanas. Neste tutorial, veremos como utilizar instantâneos ZFS e tocaremos em várias políticas de snapshotting que funcionariam de forma ideal, tanto em termos de utilização de recursos quanto de recuperabilidade.
ZFS tem tanto a visão geral de alto nível de arquivos e diretórios, e entende como os dados são escritos no disco. Ao gravar fisicamente dados em um disco, isso é feito em blocos discretos. Tipicamente, o tamanho do bloco pode ir até 1 MB, mas o padrão é normalmente 128 KB. Agora, isso significa que toda modificação (leitura, gravação ou exclusão) acontecerá nos blocos discretos.
O mecanismo copy-on-write assegura que sempre que um bloco é modificado, ao invés de modificar o bloco diretamente, ele faz uma cópia do bloco com as modificações necessárias feitas no novo bloco.
Isso é especialmente útil em casos onde, digamos, há uma falha de energia e seu sistema trava enquanto novos dados estavam sendo gravados no disco. Se isso acontecer em um sistema de arquivos tradicional, seus arquivos serão corrompidos ou deixados com buracos neles. Mas se você estiver usando ZFS, você pode perder a transação em curso como estava acontecendo, mas o último estado válido dos seus arquivos ainda será deixado intocado.
Snapshots também dependem desta funcionalidade, e bastante pesada de fato. Quando você tira uma foto de um dado conjunto de dados (‘dataset’ é o termo ZFS para um sistema de arquivos), o ZFS apenas registra o carimbo da hora em que a foto foi tirada. É isso mesmo! Nenhum dado é copiado e nenhum armazenamento extra é consumido.
Apenas quando o sistema de arquivos muda, e os dados nele divergem do snapshot, o snapshot começa a consumir armazenamento extra. O que acontece debaixo da capa é o seguinte – Ao invés de reciclar os blocos antigos ao longo do tempo, o ZFS os mantém por aí. Isto também melhora a utilização do armazenamento. Se você fotografar um conjunto de dados de 20GB e modificar apenas alguns arquivos de texto aqui e ali, o snapshot pode levar apenas alguns MB de espaço.
Criando Snapshots
Para demonstrar o uso de snapshots, vamos começar com um conjunto de dados que tem muitos arquivos de texto, apenas para manter o assunto simples. A máquina virtual que estarei usando para a demonstração está rodando FreeBSD 11.1-RELEASE-p3 que é a última versão estável disponível no momento em que esta escrita está sendo escrita. O sistema de arquivos raiz é montado no zroot pool por padrão e muitos dos diretórios familiares como /usr/src, /home, /etc são todos seus próprios conjuntos de dados montados no zroot. Se você não sabe o que um pool (ou um zpool) significa, no vernáculo ZFS, valeria bem a pena ler sobre ele antes de continuar.
Um dos muitos sistemas de arquivos, ou conjuntos de dados, que vêm por padrão no FreeBSD é: zroot/usr/src
Para ver as propriedades dele, execute o seguinte comando.
:~$ zfs list zroot/usr/src
Como você pode ver, ele usa 633 MB de armazenamento. Ele contém toda a árvore de origem do sistema operacional.
Vamos tirar um instantâneo do zroot/usr/src
:~$ zfs snapshot zroot/usr/
O símbolo @ age como um delimitador entre o conjunto de dados e o nome do instantâneo, que no nosso caso é o instantâneo1.
Agora vamos olhar para o estado da snapshot tal como é criada.
Por meio da execução do comando:
zfs list -rt all zroot/usr/src
Vemos que a snapshot não usa espaço extra quando nasce. Também não há espaço disponível, porque é um conjunto de dados estritamente lido apenas, a imagem em si não pode crescer, modificar ou encolher. Finalmente, ele não é montado em nenhum lugar, o que o torna completamente isolado da hierarquia do sistema de arquivos dado.
Agora, vamos remover o directório sbin em /usr/src/
:$ rm /usr/src/sbin
Locando no snapshot você verá agora que ele cresceu,
Isso é esperado porque o mecanismo copy-on-write está a funcionar aqui e apagar (ou modificar) os ficheiros levou a que mais dados fossem associados apenas ao snapshot e não ao conjunto de dados realmente em uso.
Note a coluna REFER na saída acima. Ele lhe dá a quantidade de dados acessíveis no conjunto de dados, enquanto a coluna USED apenas mostra quanto espaço está ocupado no disco físico.
ZFS’ Copy-On-Write mechanism frequentemente dá estes resultados contra-intuitivos onde apagar um arquivo faria parecer como se mais espaço estivesse sendo usado agora do que antes. Entretanto, tendo lido até agora, você sabe o que está realmente acontecendo!
Antes de terminar, vamos recuperar o sbin do snapshot1. Para fazer isso simplesmente execute:
:/usr/src$ zfs rollback zroot/usr/
Política de instantâneos
A próxima pergunta a fazer é – Com que frequência você quer tirar os instantâneos? Embora possa variar de uma empresa para outra, vamos pegar o exemplo de uma base de dados muito dinâmica que muda de vez em quando.
Para começar, você começaria a tirar instantâneos a cada 6 horas ou mais, mas como a base de dados muda tanto, logo se tornaria inviável armazenar todos os numerosos instantâneos que foram criados. Então o próximo passo seria purgar os snapshots que são mais velhos que, digamos, 48 horas.
Agora, o problema seria recuperar algo que foi perdido há 49 horas atrás. Para contornar este problema, você pode manter um ou dois instantâneos desse histórico de 48 horas e mantê-los por uma semana. Purgue-os quando eles ficarem mais velhos.
E se você puder continuar assim, você poderia encher os instantâneos até a própria gênese do sistema, apenas em ordem decrescente de freqüência. Finalmente, eu gostaria de salientar que estes snapshots são LEIA-ONLY, o que significa que se você for infectado por um ransomware e tiver todos os seus dados criptografados (modificados). Estes snapshots, muito provavelmente, ainda estariam intactos.