19.4. Administração do `zfs`
Anterior | Capítulo 19. O sistema de arquivos Z (ZFS) | Próxima

## 19.4. Administração do `zfs`

O utilitário `zfs` é responsável por criar, destruir e gerenciar todos os conjuntos de dados ZFS existentes em um pool. O pool é gerenciado usando o `zpool`.

### 19.4.1. Criando e destruindo conjuntos de dados

Ao contrário dos discos tradicionais e gerenciadores de volume, o espaço no ZFS não é pré-alocado. Nos sistemas de arquivos tradicionais, depois que todo o espaço é particionado e atribuído, não há como adicionar um sistema de arquivos adicional sem adicionar um novo disco. Com o ZFS, novos sistemas de arquivos podem ser criados a qualquer momento. Cada conjunto de dados tem propriedades incluindo recursos como compactação, deduplicação, armazenamento em cache e cotas, bem como outras propriedades úteis como somente leitura, diferenciação de maiúsculas e minúsculas , compartilhamento de arquivos de rede e um ponto de montagem. Os conjuntos de dados podem ser aninhados uns dentro dos outros e os conjuntos de dados filhos herdarão propriedades de seus pais. Cada conjunto de dados pode ser administrado, delegado, replicado, preservado por um snapshot, preso, e destruído como uma unidade. Há muitas vantagens em criar um conjunto de dados separado para cada tipo ou conjunto de arquivos diferente. A única desvantagem de ter um número extremamente grande de conjuntos de dados é que alguns comandos como `zfs list` serão mais lentos, e a montagem de centenas ou mesmo milhares de conjuntos de dados pode retardar o processo de inicialização do FreeBSD.

Crie um novo conjunto de dados e ative a compactação LZ4 nele:

    # zfs list
    NAME                  USED  AVAIL  REFER  MOUNTPOINT
    mypool                781M  93.2G   144K  none
    mypool/ROOT           777M  93.2G   144K  none
    mypool/ROOT/default   777M  93.2G   777M  /
    mypool/tmp            176K  93.2G   176K  /tmp
    mypool/usr            616K  93.2G   144K  /usr
    mypool/usr/home       184K  93.2G   184K  /usr/home
    mypool/usr/ports      144K  93.2G   144K  /usr/ports
    mypool/usr/src        144K  93.2G   144K  /usr/src
    mypool/var           1.20M  93.2G   608K  /var
    mypool/var/crash      148K  93.2G   148K  /var/crash
    mypool/var/log        178K  93.2G   178K  /var/log
    mypool/var/mail       144K  93.2G   144K  /var/mail
    mypool/var/tmp        152K  93.2G   152K  /var/tmp
    # zfs create -o compress=lz4 mypool/usr/mydataset
    # zfs list
    NAME                   USED  AVAIL  REFER  MOUNTPOINT
    mypool                 781M  93.2G   144K  none
    mypool/ROOT            777M  93.2G   144K  none
    mypool/ROOT/default    777M  93.2G   777M  /
    mypool/tmp             176K  93.2G   176K  /tmp
    mypool/usr             704K  93.2G   144K  /usr
    mypool/usr/home        184K  93.2G   184K  /usr/home
    mypool/usr/mydataset  87.5K  93.2G  87.5K  /usr/mydataset
    mypool/usr/ports       144K  93.2G   144K  /usr/ports
    mypool/usr/src         144K  93.2G   144K  /usr/src
    mypool/var            1.20M  93.2G   610K  /var
    mypool/var/crash       148K  93.2G   148K  /var/crash
    mypool/var/log         178K  93.2G   178K  /var/log
    mypool/var/mail        144K  93.2G   144K  /var/mail
    mypool/var/tmp         152K  93.2G   152K  /var/tmp

A destruição de um conjunto de dados é muito mais rápida que a exclusão de todos os arquivos que residem no conjunto de dados, pois não envolve a verificação de todos os arquivos e a atualização de todos os metadados correspondentes.

Destrua o conjunto de dados criado anteriormente:

    # zfs list
    NAME                   USED  AVAIL  REFER  MOUNTPOINT
    mypool                 880M  93.1G   144K  none
    mypool/ROOT            777M  93.1G   144K  none
    mypool/ROOT/default    777M  93.1G   777M  /
    mypool/tmp             176K  93.1G   176K  /tmp
    mypool/usr             101M  93.1G   144K  /usr
    mypool/usr/home        184K  93.1G   184K  /usr/home
    mypool/usr/mydataset   100M  93.1G   100M  /usr/mydataset
    mypool/usr/ports       144K  93.1G   144K  /usr/ports
    mypool/usr/src         144K  93.1G   144K  /usr/src
    mypool/var            1.20M  93.1G   610K  /var
    mypool/var/crash       148K  93.1G   148K  /var/crash
    mypool/var/log         178K  93.1G   178K  /var/log
    mypool/var/mail        144K  93.1G   144K  /var/mail
    mypool/var/tmp         152K  93.1G   152K  /var/tmp
    # zfs destroy mypool/usr/mydataset
    # zfs list
    NAME                  USED  AVAIL  REFER  MOUNTPOINT
    mypool                781M  93.2G   144K  none
    mypool/ROOT           777M  93.2G   144K  none
    mypool/ROOT/default   777M  93.2G   777M  /
    mypool/tmp            176K  93.2G   176K  /tmp
    mypool/usr            616K  93.2G   144K  /usr
    mypool/usr/home       184K  93.2G   184K  /usr/home
    mypool/usr/ports      144K  93.2G   144K  /usr/ports
    mypool/usr/src        144K  93.2G   144K  /usr/src
    mypool/var           1.21M  93.2G   612K  /var
    mypool/var/crash      148K  93.2G   148K  /var/crash
    mypool/var/log        178K  93.2G   178K  /var/log
    mypool/var/mail       144K  93.2G   144K  /var/mail
    mypool/var/tmp        152K  93.2G   152K  /var/tmp

Nas versões modernas do ZFS, o `zfs destroy` é assíncrono, e o espaço livre pode levar vários minutos para aparecer no pool. Use o `zpool get freeing `poolname`` para ver a propriedade `freeing`, indicando quantos conjuntos de dados estão tendo seus blocos liberados em segundo plano. Se houver conjuntos de dados filhos, como snapshots ou outros conjuntos de dados, o pai não poderá ser destruído. Para destruir um conjunto de dados e todos os seus filhos, use `-r` para destruir recursivamente o conjunto de dados e todos os seus filhos. Use `-n` `-v` para listar os conjuntos de dados e snapshots que seriam destruídos por esta operação, mas na verdade não destruirão nada. O espaço que seria recuperado pela destruição dos snapshots também é mostrado.

### 19.4.2. Criando e Destruindo Volumes

Um volume é um tipo especial de conjunto de dados. Em vez de ser montado como um sistema de arquivos, ele é exposto como um dispositivo de bloco em `/dev/zvol/`poolname`/`dataset``. Isso permite que o volume seja usado para outros sistemas de arquivos, para fazer backup dos discos de uma máquina virtual ou para ser exportado usando protocolos como iSCSI ou HAST.

Um volume pode ser formatado com qualquer sistema de arquivos ou usado sem um sistema de arquivos para armazenar dados brutos. Para o usuário, um volume parece ser um disco normal. Colocar sistemas de arquivos comuns nesses zvols fornece recursos que os discos comuns ou sistemas de arquivos normalmente não possuem. Por exemplo, o uso da propriedade de compactação em um volume de 250 MB permite a criação de um sistema de arquivos FAT compactado.

    # zfs create -V 250m -o compression=on tank/fat32
    # zfs list tank
    NAME USED AVAIL REFER MOUNTPOINT
    tank 258M  670M   31K /tank
    # newfs_msdos -F32 /dev/zvol/tank/fat32
    # mount -t msdosfs /dev/zvol/tank/fat32 /mnt
    # df -h /mnt | grep fat32
    Filesystem           Size Used Avail Capacity Mounted on
    /dev/zvol/tank/fat32 249M  24k  249M     0%   /mnt
    # mount | grep fat32
    /dev/zvol/tank/fat32 on /mnt (msdosfs, local)

Destruir um volume é o mesmo que destruir um conjunto de dados regular do sistema de arquivos. A operação é quase instantânea, mas pode levar vários minutos para que o espaço livre seja recuperado em segundo plano.

### 19.4.3. Renomeando um Conjunto de Dados

O nome de um conjunto de dados pode ser alterado com `zfs rename`. O pai de um conjunto de dados também pode ser alterado com esse comando. A renomeação de um conjunto de dados para um conjunto de dados pai diferente alterará o valor das propriedades herdadas do conjunto de dados pai. Quando um conjunto de dados é renomeado, ele é desmontado e, em seguida, remontado no novo local (que é herdado do novo conjunto de dados pai). Esse comportamento pode ser evitado com `-u`.

Renomeie um conjunto de dados e mova-o para um conjunto de dados pai diferente:

    # zfs list
    NAME                   USED  AVAIL  REFER  MOUNTPOINT
    mypool                 780M  93.2G   144K  none
    mypool/ROOT            777M  93.2G   144K  none
    mypool/ROOT/default    777M  93.2G   777M  /
    mypool/tmp             176K  93.2G   176K  /tmp
    mypool/usr             704K  93.2G   144K  /usr
    mypool/usr/home        184K  93.2G   184K  /usr/home
    mypool/usr/mydataset  87.5K  93.2G  87.5K  /usr/mydataset
    mypool/usr/ports       144K  93.2G   144K  /usr/ports
    mypool/usr/src         144K  93.2G   144K  /usr/src
    mypool/var            1.21M  93.2G   614K  /var
    mypool/var/crash       148K  93.2G   148K  /var/crash
    mypool/var/log         178K  93.2G   178K  /var/log
    mypool/var/mail        144K  93.2G   144K  /var/mail
    mypool/var/tmp         152K  93.2G   152K  /var/tmp
    # zfs rename mypool/usr/mydataset mypool/var/newname
    # zfs list
    NAME                  USED  AVAIL  REFER  MOUNTPOINT
    mypool                780M  93.2G   144K  none
    mypool/ROOT           777M  93.2G   144K  none
    mypool/ROOT/default   777M  93.2G   777M  /
    mypool/tmp            176K  93.2G   176K  /tmp
    mypool/usr            616K  93.2G   144K  /usr
    mypool/usr/home       184K  93.2G   184K  /usr/home
    mypool/usr/ports      144K  93.2G   144K  /usr/ports
    mypool/usr/src        144K  93.2G   144K  /usr/src
    mypool/var           1.29M  93.2G   614K  /var
    mypool/var/crash      148K  93.2G   148K  /var/crash
    mypool/var/log        178K  93.2G   178K  /var/log
    mypool/var/mail       144K  93.2G   144K  /var/mail
    mypool/var/newname   87.5K  93.2G  87.5K  /var/newname
    mypool/var/tmp        152K  93.2G   152K  /var/tmp

Os snapshots também podem ser renomeados dessa maneira. Devido à natureza dos snapshots, eles não podem ser renomeados para um conjunto de dados pai diferente. Para renomear um snapshot recursivo, especifique `-r` e todos os snapshots com o mesmo nome nos conjuntos de dados filho também serão renomeados.

    # zfs list -t snapshot
    NAME                                USED  AVAIL  REFER  MOUNTPOINT
    mypool/var/newname@first_snapshot      0      -  87.5K  -
    # zfs rename mypool/var/newname@first_snapshot new_snapshot_name
    # zfs list -t snapshot
    NAME                                   USED  AVAIL  REFER  MOUNTPOINT
    mypool/var/newname@new_snapshot_name      0      -  87.5K  -

### 19.4.4. Configurando Propriedades do Conjunto de Dados

Cada conjunto de dados do ZFS possui várias propriedades que controlam seu comportamento. A maioria das propriedades é herdada automaticamente do conjunto de dados pai, mas pode ser substituída localmente. Defina uma propriedade em um conjunto de dados com `zfs set `property`=`value` `dataset``. A maioria das propriedades tem um conjunto limitado de valores válidos, o `zfs get` exibirá cada propriedade e valor válido possível. A maioria das propriedades pode ser revertida para seus valores herdados usando `zfs inherit`.

Propriedades definidas pelo usuário também podem ser definidas. Eles se tornam parte da configuração do conjunto de dados e podem ser usados ​​para fornecer informações adicionais sobre o conjunto de dados ou seu conteúdo. Para distinguir essas propriedades personalizadas daquelas fornecidas como parte do ZFS, dois pontos (`:`) são usados ​​para criar um namespace personalizado para a propriedade.

    # zfs set custom:costcenter=1234 tank
    # zfs get custom:costcenter tank
    NAME PROPERTY           VALUE SOURCE
    tank custom:costcenter  1234  local

Para remover uma propriedade customizada, use o `zfs inherit` com `-r`. Se a propriedade personalizada não estiver definida em nenhum dos conjuntos de dados pai, ela será removida completamente (embora as alterações ainda sejam registradas no histórico do pool).

     #   zfs inherit -r  customizado :  costcenter   tanque
     #   zfs  customizado :  costcenter   tank
    NAME PROPERTY VALUE SOURCE
    tanque personalizado: costcenter - -
     #   zfs obtém todos  tank  | grep  personalizado :  costcenter
     #

#### 19.4.4.1. Obtendo e definindo propriedades de compartilhamento

Duas propriedades de conjunto de dados comumente usadas e úteis são as opções de compartilhamento NFS e SMB. Configurar estas define se e como os conjuntos de dados do ZFS podem ser compartilhados na rede. Atualmente, apenas o compartilhamento de configurações via NFS é suportado no FreeBSD. Para obter o status atual de um compartilhamento, insira:

    # zfs get sharenfs mypool/usr/home
    NAME             PROPERTY  VALUE    SOURCE
    mypool/usr/home  sharenfs  on       local
    # zfs get sharesmb mypool/usr/home
    NAME             PROPERTY  VALUE    SOURCE
    mypool/usr/home  sharesmb  off      local

Para ativar o compartilhamento de um conjunto de dados, insira:

    #  zfs set sharenfs=on mypool/usr/home

Também é possível definir opções adicionais para compartilhar conjuntos de dados por meio do NFS, como `-alldirs`, `-maproot` e `-network`. Para definir opções adicionais para um conjunto de dados compartilhado por meio do NFS, insira:

    #  zfs set sharenfs="-alldirs,-maproot=root,-network=192.168.1.0/24" mypool/usr/home

### 19.4.5. Gerenciando Snapshots

Os snapshots são um dos recursos mais poderosos do ZFS. Um snapshot fornece uma cópia point-in-time somente leitura do conjunto de dados. Com Copy-On-Write (COW), os snapshots podem ser criados rapidamente, preservando a versão mais antiga dos dados no disco. Se não houver snapshots, o espaço será recuperado para uso futuro quando os dados forem reconfigurados ou excluídos. Os snapshots preservam o espaço em disco gravando apenas as diferenças entre o conjunto de dados atual e uma versão anterior. Os snapshots são permitidos apenas em conjuntos de dados completos, não em arquivos ou diretórios individuais. Quando um snapshot é criado a partir de um conjunto de dados, tudo contido nele é duplicado. Isso inclui as propriedades do sistema de arquivos, arquivos, diretórios, permissões e assim por diante. Os snapshots não usam espaço adicional quando são criados pela primeira vez, consumindo espaço apenas quando os blocos de referência são alterados. Snapshots recursivos obtidos com `-r` criam um instantâneo com o mesmo nome no conjunto de dados e em todos os seus filhos, fornecendo um snapshot moment-in-time de todos os sistemas de arquivos no momento. Isso pode ser importante quando um aplicativo possui arquivos em vários conjuntos de dados relacionados ou dependentes um do outro. Sem snapshots, um backup teria cópias dos arquivos de diferentes pontos no tempo.

Os snapshots no ZFS fornecem uma variedade de recursos que até mesmo outros sistemas de arquivos com a funcionalidade de snapshots não têm. Um exemplo típico de uso de snapshots é ter uma maneira rápida de fazer backup do estado atual do sistema de arquivos quando uma ação arriscada, como uma instalação de software ou uma atualização do sistema, é executada. Se a ação falhar, o snapshot poderá ser revertido e o sistema terá o mesmo estado de quando o snapshot foi criado. Se a atualização foi bem sucedida, o instantâneo pode ser excluído para liberar espaço. Sem snapshots, uma atualização com falha geralmente requer uma restauração de backup, o que é tedioso, consome tempo e pode exigir tempo de inatividade durante o qual o sistema não pode ser usado. Os snapshots podem ser revertidos rapidamente, mesmo enquanto o sistema está sendo executado em operação normal, com pouco ou nenhum tempo de inatividade. A economia de tempo é enorme com sistemas de armazenamento de vários terabytes e o tempo necessário para copiar os dados a partir do backup. Os snapshots não substituem um backup completo de um pool, mas podem ser usados ​​de maneira rápida e fácil para armazenar uma cópia do conjunto de dados em um momento específico.

#### 19.4.5.1. Criando Snapshots

Os snapshots são criados com `zfs snapshot `dataset`@`snapshotname``. Adicionar a opção `-r` cria um snapshot recursivamente, com o mesmo nome em todos os conjuntos de dados filho.

Crie um Snapshot recursivo de todo o pool:

    # zfs list -t all
    NAME                                   USED  AVAIL  REFER  MOUNTPOINT
    mypool                                 780M  93.2G   144K  none
    mypool/ROOT                            777M  93.2G   144K  none
    mypool/ROOT/default                    777M  93.2G   777M  /
    mypool/tmp                             176K  93.2G   176K  /tmp
    mypool/usr                             616K  93.2G   144K  /usr
    mypool/usr/home                        184K  93.2G   184K  /usr/home
    mypool/usr/ports                       144K  93.2G   144K  /usr/ports
    mypool/usr/src                         144K  93.2G   144K  /usr/src
    mypool/var                            1.29M  93.2G   616K  /var
    mypool/var/crash                       148K  93.2G   148K  /var/crash
    mypool/var/log                         178K  93.2G   178K  /var/log
    mypool/var/mail                        144K  93.2G   144K  /var/mail
    mypool/var/newname                    87.5K  93.2G  87.5K  /var/newname
    mypool/var/newname@new_snapshot_name      0      -  87.5K  -
    mypool/var/tmp                         152K  93.2G   152K  /var/tmp
    # zfs snapshot -r mypool@my_recursive_snapshot
    # zfs list -t snapshot
    NAME                                        USED  AVAIL  REFER  MOUNTPOINT
    mypool@my_recursive_snapshot                   0      -   144K  -
    mypool/ROOT@my_recursive_snapshot              0      -   144K  -
    mypool/ROOT/default@my_recursive_snapshot      0      -   777M  -
    mypool/tmp@my_recursive_snapshot               0      -   176K  -
    mypool/usr@my_recursive_snapshot               0      -   144K  -
    mypool/usr/home@my_recursive_snapshot          0      -   184K  -
    mypool/usr/ports@my_recursive_snapshot         0      -   144K  -
    mypool/usr/src@my_recursive_snapshot           0      -   144K  -
    mypool/var@my_recursive_snapshot               0      -   616K  -
    mypool/var/crash@my_recursive_snapshot         0      -   148K  -
    mypool/var/log@my_recursive_snapshot           0      -   178K  -
    mypool/var/mail@my_recursive_snapshot          0      -   144K  -
    mypool/var/newname@new_snapshot_name           0      -  87.5K  -
    mypool/var/newname@my_recursive_snapshot       0      -  87.5K  -
    mypool/var/tmp@my_recursive_snapshot           0      -   152K  -

Os snapshots não são mostrados por uma operação normal do `zfs list`. Para listar snapshots , a opção `-t snapshot` é anexado ao `zfs list`. A opção `-t all` exibe os sistemas de arquivos e snapshots.

Os snapshots não são montados diretamente, portanto, o caminho é mostrado na coluna `MOUNTPOINT`. Não há menção ao espaço disponível em disco na coluna `AVAIL`, já que os snapshots não podem ser gravados após serem criados. Compare o snapshot com o conjunto de dados original a partir do qual foi criado:

    # zfs list -rt all mypool/usr/home
    NAME                                    USED  AVAIL  REFER  MOUNTPOINT
    mypool/usr/home                         184K  93.2G   184K  /usr/home
    mypool/usr/home@my_recursive_snapshot      0      -   184K  -

A exibição do conjunto de dados e dos snapshots juntos revela como os snapshots funcionam no modo COW. Eles salvam apenas as alterações (deltas) que foram feitas e não o conteúdo completo do sistema de arquivos novamente. Isso significa que os snapshots ocupam pouco espaço quando poucas alterações são feitas. O uso do espaço pode se tornar ainda mais aparente copiando um arquivo para o conjunto de dados e fazendo um segundo snapshots:

    # cp /etc/passwd /var/tmp
    # zfs snapshot mypool/var/tmp@after_cp
    # zfs list -rt all mypool/var/tmp
    NAME                                   USED  AVAIL  REFER  MOUNTPOINT
    mypool/var/tmp                         206K  93.2G   118K  /var/tmp
    mypool/var/tmp@my_recursive_snapshot    88K      -   152K  -
    mypool/var/tmp@after_cp                   0      -   118K  -

O segundo snapshot contém apenas as alterações feitas no conjunto de dados após a operação de cópia. Isso resulta numa enorme economia de espaço. Observe que o tamanho do snapshot `mypool/var/tmp@my_recursive_snapshot` também foi alterado na coluna `USED` para indicar as alterações entre ela mesma e o snapshot obtido posteriormente.

#### 19.4.5.2. Comparando Snapshots

O ZFS fornece um comando interno para comparar as diferenças de conteúdo entre dois snapshots. Isso é útil quando muitos snapshots foram gerados com o passar do tempo e o usuário deseja ver como o sistema de arquivos mudou ao longo do tempo. Por exemplo, o `zfs diff` permite que um usuário localize o ultimo snapshot que ainda contém um arquivo que foi acidentalmente excluído. Fazer isso para os dois snapshots criados na seção anterior produz essa saída:

    # zfs list -rt all mypool/var/tmp
    NAME                                   USED  AVAIL  REFER  MOUNTPOINT
    mypool/var/tmp                         206K  93.2G   118K  /var/tmp
    mypool/var/tmp@my_recursive_snapshot    88K      -   152K  -
    mypool/var/tmp@after_cp                   0      -   118K  -
    # zfs diff mypool/var/tmp@my_recursive_snapshot
    M       /var/tmp/
    +       /var/tmp/passwd

O comando lista as alterações entre o snapshot especificado (neste caso ``mypool/var/tmp@my_recursive_snapshot``) e o sistema de arquivos ativo. A primeira coluna mostra o tipo de mudança:

+ | O caminho ou arquivo foi adicionado.
- | O caminho ou arquivo foi excluído.
M | O caminho ou arquivo foi modificado.
R | O caminho ou arquivo foi renomeado.

Comparando a saída com a tabela, fica claro que o ``passwd`` foi adicionado após o snapshot ``mypool/var/tmp@my_recursive_snapshot`` ter sido criado. Isso também resultou em uma modificação no diretório pai montado em ``/var/tmp``.

A comparação de dois snapshots é útil ao usar o recurso de replicação do ZFS para transferir um conjunto de dados para um host diferente para fins de backup.

Compare dois snapshots fornecendo o nome completo do conjunto de dados e o nome do snapshot de ambos os conjuntos de dados:

    # cp /var/tmp/passwd /var/tmp/passwd.copy
    # zfs snapshot mypool/var/tmp@diff_snapshot
    # zfs diff mypool/var/tmp@my_recursive_snapshot mypool/var/tmp@diff_snapshot
    M       /var/tmp/
    +       /var/tmp/passwd
    +       /var/tmp/passwd.copy
    # zfs diff mypool/var/tmp@my_recursive_snapshot mypool/var/tmp@after_cp
    M       /var/tmp/
    +       /var/tmp/passwd

Um administrador de backup pode comparar dois snapshots recebidos do host de envio e determinar as alterações reais no conjunto de dados. Consulte a seção Replicação para obter maiores informações.

#### 19.4.5.3. Reversão de um Snapshot

Quando pelo menos um snapshot estiver disponível, ele poderá ser revertido a qualquer momento. Na maioria das vezes, esse é o caso quando o estado atual do conjunto de dados não é mais necessário e uma versão mais antiga é preferida. Cenários em que testes de desenvolvimento local deram errado, atualizações de sistemas com falhas que dificultam o funcionamento geral do sistema ou a necessidade de restaurar arquivos ou diretórios excluídos acidentalmente são ocorrências muito comuns. Felizmente, reverter um snapshot é tão fácil quanto digitar `zfs rollback `snapshotname``. Dependendo de quantas alterações estão envolvidas, a operação será concluída em um determinado período de tempo. Durante esse período, o conjunto de dados permanece sempre em um estado consistente, da mesma forma que um banco de dados em conformidade com os princípios do ACID ao realizar uma reversão. Isso está acontecendo enquanto o conjunto de dados está ativo e acessível, sem exigir um tempo de inatividade. Depois que o snapshot for revertido, o conjunto de dados terá o mesmo estado de quando o snapshot foi originalmente criado. Todos os outros dados nesse conjunto de dados que não faziam parte do snapshot são descartados. Criar um snapshot do estado atual do conjunto de dados antes de reverter para um anterior é uma boa ideia quando alguns dos dados são necessários mais tarde. Desta forma, o usuário pode alternar entre os snapshots sem perder dados que ainda são valiosos.

No primeiro exemplo, um snapshot é revertido por causa de uma operação descuidada com o comando `rm` que removeu muito mais dados do que o pretendido.

    # zfs list -rt all mypool/var/tmp
    NAME                                   USED  AVAIL  REFER  MOUNTPOINT
    mypool/var/tmp                         262K  93.2G   120K  /var/tmp
    mypool/var/tmp@my_recursive_snapshot    88K      -   152K  -
    mypool/var/tmp@after_cp               53.5K      -   118K  -
    mypool/var/tmp@diff_snapshot              0      -   120K  -
    # ls /var/tmp
    passwd          passwd.copy     vi.recover
    # rm /var/tmp/passwd*
    # ls /var/tmp
    vi.recover

Neste ponto, o usuário percebeu que muitos arquivos foram excluídos e os quer de volta. O ZFS fornece uma maneira fácil de recuperá-los usando reversões, mas somente quando os snapshots de dados importantes são executados regularmente. Para recuperar os arquivos e recomeçar a partir do último snapshot, emita o comando:

    # zfs rollback mypool/var/tmp@diff_snapshot
    # ls /var/tmp
    passwd          passwd.copy     vi.recover

A operação de reversão restaurou o conjunto de dados para o estado do último snapshot. Também é possível reverter para um snapshot que foi gerado muito antes e que possui outros snapshots criados após ele. Ao tentar fazer isso, o ZFS irá emitir este aviso:

    # zfs list -rt snapshot mypool/var/tmp
    AME                                   USED  AVAIL  REFER  MOUNTPOINT
    mypool/var/tmp@my_recursive_snapshot    88K      -   152K  -
    mypool/var/tmp@after_cp               53.5K      -   118K  -
    mypool/var/tmp@diff_snapshot              0      -   120K  -
    # zfs rollback mypool/var/tmp@my_recursive_snapshot
    cannot rollback to 'mypool/var/tmp@my_recursive_snapshot': more recent snapshots exist
    use '-r' to force deletion of the following snapshots:
    mypool/var/tmp@after_cp
    mypool/var/tmp@diff_snapshot

Esse aviso significa que existem snapshots entre o estado atual do conjunto de dados e o snapshot para o qual o usuário deseja retroceder. Para concluir a reversão, esses snapshots devem ser excluídos. O ZFS não pode rastrear todas as alterações entre estados diferentes do conjunto de dados, porque os snapshots são somente de leitura. O ZFS não excluirá os snapshots afetados, a menos que o usuário especifique a opção `-r` para indicar que essa é a ação desejada. Se essa for a intenção e as consequências da perda de todos os snapshots intermediários forem compreendidas, o comando poderá ser emitido:

    # zfs rollback -r mypool/var/tmp@my_recursive_snapshot
    # zfs list -rt snapshot mypool/var/tmp
    NAME                                   USED  AVAIL  REFER  MOUNTPOINT
    mypool/var/tmp@my_recursive_snapshot     8K      -   152K  -
    # ls /var/tmp
    vi.recover

A saída de `zfs list -t snapshot` confirma que os snapshots intermediários foram removidos como resultado do `zfs rollback -r`.

#### 19.4.5.4. Restaurando arquivos individuais a partir de Snapshots

Os snapshots são montados em um diretório oculto no conjunto de dados pai: `.zfs/snapshots/`snapshotname``. Por padrão, esses diretórios não serão exibidos mesmo quando um `ls -a` padrão for executado. Embora o diretório não seja exibido, ele está lá e pode ser acessado como qualquer diretório normal. A propriedade denominada `snapdir` controla se esses diretórios ocultos aparecem em uma listagem de diretórios. Definir a propriedade como `visible` permite que eles apareçam na saída do `ls` e de outros comandos que lidam com o conteúdo do diretório.

    # zfs get snapdir mypool/var/tmp
    NAME            PROPERTY  VALUE    SOURCE
    mypool/var/tmp  snapdir   hidden   default
    # ls -a /var/tmp
    .               ..              passwd          vi.recover
    # zfs set snapdir=visible mypool/var/tmp
    # ls -a /var/tmp
    .               ..              .zfs            passwd          vi.recover

Arquivos individuais podem ser facilmente restaurados para um estado anterior, copiando-os do snapshot de volta para o conjunto de dados pai. A estrutura de diretórios abaixo de `.zfs/snapshot` tem um diretório nomeado exatamente como os instantâneos criados anteriormente para facilitar sua identificação. No próximo exemplo, presume-se que um arquivo deve ser restaurado a partir do diretório `.zfs` oculto, copiando-o do snapshot que continha a versão mais recente do arquivo:

    # rm /var/tmp/passwd
    # ls -a /var/tmp
    .               ..              .zfs            vi.recover
    # ls /var/tmp/.zfs/snapshot
    after_cp                my_recursive_snapshot
    # ls /var/tmp/.zfs/snapshot/after_cp
    passwd          vi.recover
    # cp /var/tmp/.zfs/snapshot/after_cp/passwd /var/tmp

Quando o comando `ls .zfs/snapshot` foi emitido, a propriedade `snapdir` pode ter sido definida como oculta, mas ainda seria possível listar o conteúdo desse diretório. Cabe ao administrador decidir se esses diretórios serão exibidos. É possível exibi-los para determinados conjuntos de dados e impedi-los para outros. Copiar arquivos ou diretórios deste diretório `.zfs/snapshot` oculto é bastante simples. Tentar o contrário, resulta neste erro:

    # cp /etc/rc.conf /var/tmp/.zfs/snapshot/after_cp/
    cp: /var/tmp/.zfs/snapshot/after_cp/rc.conf: Read-only file system

O erro lembra ao usuário que os snapshots são somente de leitura e não podem ser alterados após a criação. Os arquivos não podem ser copiados para ou removidos dos diretórios de snapshot porque isso alteraria o estado do conjunto de dados que eles representam.

Os snapshots consomem espaço com base em quanto o sistema de arquivos pai foi alterado desde o momento da criação do snapshot. A propriedade `written` de um snapshot rastreia quanto espaço está sendo usado pelo snapshot.

Snapshots são destruídos e o espaço recuperado com o `zfs destroy `dataset`@`snapshot``. Adicionar `-r` remove recursivamente todos os snapshots com o mesmo nome sob o conjunto de dados pai. Adicionar `-n -v` ao comando exibe uma lista dos snapshots que seriam excluídos e uma estimativa de quanto espaço seria recuperado sem executar a operação de destruição real.

### 19.4.6. Gerenciando Clones

Um clone é uma cópia de um snapshot que é tratado mais como um conjunto de dados regular. Ao contrário de um snapshot, um clone não é somente de leitura, ele pode ser montado e pode ter suas próprias propriedades. Uma vez que um clone tenha sido criado usando `zfs clone`, o snapshot do qual ele foi criado não pode ser destruído. O relacionamento filho/pai entre o clone e o snapshot pode ser revertido usando `zfs promote`. Depois que um clone é promovido, o snapshot se torna um filho do clone, em vez de filho do conjunto de dados pai original. Isso mudará a maneira como o espaço é contabilizado, mas não mudará a quantidade de espaço consumida. O clone pode ser montado em qualquer ponto dentro da hierarquia do sistema de arquivos ZFS, não apenas abaixo do local original do snapshot.

Para demonstrar o recurso de clonagem, este conjunto de dados de exemplo é usado:

    # zfs list -rt all camino/home/joe
    NAME                    USED  AVAIL  REFER  MOUNTPOINT
    camino/home/joe         108K   1.3G    87K  /usr/home/joe
    camino/home/joe@plans    21K      -  85.5K  -
    camino/home/joe@backup    0K      -    87K  -

Um uso típico de clones é experimentar um conjunto de dados específico, mantendo o snapshot em volta, para o caso de algo dar errado. Como os snapshots não podem ser alterados, um clone de leitura/gravação de um snapshot é criado. Depois que o resultado desejado é alcançado no clone, o clone pode ser promovido para se tornar um conjunto de dados e o sistema de arquivos antigo é removido. Isso não é estritamente necessário, pois o clone e o conjunto de dados podem coexistir sem problemas.

    # zfs clone camino/home/joe@backup camino/home/joenew
    # ls /usr/home/joe*
    /usr/home/joe:
    backup.txz     plans.txt

    /usr/home/joenew:
    backup.txz     plans.txt
    # df -h /usr/home
    Filesystem          Size    Used   Avail Capacity  Mounted on
    usr/home/joe        1.3G     31k    1.3G     0%    /usr/home/joe
    usr/home/joenew     1.3G     31k    1.3G     0%    /usr/home/joenew

Depois que um clone é criado, ele é uma cópia exata do estado em que o conjunto de dados estava quando o snapshot foi criado. O clone agora pode ser alterado independentemente de seu conjunto de dados de origem. A única conexão entre os dois é o snapshot. O ZFS registra essa conexão na propriedade `origin`. Uma vez que a dependência entre o snapshot e o clone foi removida promovendo-se o clone usando `zfs promote`, a `origem` do clone é removida, pois agora ele é um conjunto de dados independente. Este exemplo demonstra isso:

    # zfs get origin camino/home/joenew
    NAME                  PROPERTY  VALUE                     SOURCE
    camino/home/joenew    origin    camino/home/joe@backup    -
    # zfs promote camino/home/joenew
    # zfs get origin camino/home/joenew
    NAME                  PROPERTY  VALUE   SOURCE
    camino/home/joenew    origin    -       -

Depois de fazer algumas alterações, como copiar o `loader.conf` para o clone promovido, por exemplo, o diretório antigo torna-se obsoleto nesse caso. Em vez disso, o clone promovido pode substituí-lo. Isso pode ser conseguido por dois comandos consecutivos: `zfs destroy` no dataset antigo e `zfs rename` no clone para nomeá-lo como o conjunto de dados antigo (ele também poderia ter um nome totalmente diferente).

    # cp /boot/defaults/loader.conf /usr/home/joenew
    # zfs destroy -f camino/home/joe
    # zfs rename camino/home/joenew camino/home/joe
    # ls /usr/home/joe
    backup.txz     loader.conf     plans.txt
    # df -h /usr/home
    Filesystem          Size    Used   Avail Capacity  Mounted on
    usr/home/joe        1.3G    128k    1.3G     0%    /usr/home/joe

O snapshot clonado agora é tratado como um conjunto de dados comum. Ele contém todos os dados do snapshot original mais os arquivos que foram adicionados a ele como o `loader.conf`. Os clones podem ser usados ​​em diferentes cenários para fornecer recursos úteis aos usuários do ZFS. Por exemplo, os jails podem ser disponibilizados como snapshots contendo diferentes conjuntos de aplicativos instalados. Os usuários podem clonar esses snapshots e adicionar seus próprios aplicativos como acharem melhor. Uma vez satisfeitos com as alterações, os clones podem ser promovidos a conjuntos de dados completos e fornecidos aos usuários finais para que trabalhem como se estivessem com um conjunto de dados real. Fornecer estes jails economiza tempo e sobrecarga administrativa.

### 19.4.7. Replicação

Manter os dados em um único pool e em um único local o expõe a riscos como roubo e desastres naturais ou humanos. Fazer backups regulares de todo o pool é vital. O ZFS fornece um recurso de serialização integrado que pode enviar uma representação de fluxo dos dados para a saída padrão. Usando essa técnica, é possível não apenas armazenar os dados em outro pool conectado ao sistema local, mas também enviá-los por uma rede para outro sistema. Os snapshots são a base para essa replicação (consulte a seção sobre snapshots ZFS). Os comandos usados ​​para replicar dados são `zfs send` e `zfs receive`.

Estes exemplos demonstram a replicação do ZFS com estes dois pools:

    # zpool list
    NAME    SIZE  ALLOC   FREE   CKPOINT  EXPANDSZ   FRAG   CAP  DEDUP  HEALTH  ALTROOT
    backup  960M    77K   896M         -         -     0%    0%  1.00x  ONLINE  -
    mypool  984M  43.7M   940M         -         -     0%    4%  1.00x  ONLINE  -

O pool chamado `mypool` é o pool principal no qual os dados são gravados e lidos regularmente. Um segundo pool, `backup` é usado como standby, caso o pool principal fique indisponível. Observe que esse failover não é feito automaticamente pelo ZFS, mas deve ser feito manualmente por um administrador do sistema, quando necessário. Um snapshot é usado para fornecer uma versão consistente do sistema de arquivos a ser replicado. Depois que um snapshot de `mypool` tiver sido criado, ele poderá ser copiado para o pool `backup`. Apenas snapshots podem ser replicados. As alterações feitas desde o snapshot mais recente não serão incluídas.

    # zfs snapshot mypool@backup1
    # zfs list -t snapshot
    NAME                    USED  AVAIL  REFER  MOUNTPOINT
    mypool@backup1             0      -  43.6M  -

Agora que existe um snapshot, o `zfs send` pode ser usado para criar um fluxo representando o conteúdo do snapshot. Esse fluxo pode ser armazenado como um arquivo ou recebido por outro pool. O fluxo é gravado na saída padrão, mas deve ser redirecionado para um arquivo ou canal ou um erro será produzido:

    # zfs send mypool@backup1
    Error: Stream can not be written to a terminal.
    You must redirect standard output.

Para fazer backup de um conjunto de dados com o `zfs send`, redirecione para um arquivo localizado no pool de backup montado. Assegure-se de que o pool tenha espaço livre suficiente para acomodar o tamanho do snapshot que está sendo enviado, o que significa todos os dados contidos no snapshot, não apenas as mudanças do snapshot anterior.

    # zfs send mypool@backup1 > /backup/backup1
    # zpool list
    NAME    SIZE  ALLOC   FREE   CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
    backup  960M  63.7M   896M         -         -     0%     6%  1.00x  ONLINE  -
    mypool  984M  43.7M   940M         -         -     0%     4%  1.00x  ONLINE  -

O `zfs send` transferiu todos os dados do snapshot chamado `backup1` para o pool chamado `backup`. Criar e enviar esses snapshots pode ser feito automaticamente com uma tarefa agendada do cron(8).

Em vez de armazenar os backups como arquivos compactados, o ZFS pode recebê-los como um sistema de arquivos ativo, permitindo que os dados de backup sejam acessados ​​diretamente. Para obter os dados reais contidos nesses fluxos, o `zfs receive` é usado para transformar os fluxos novamente em arquivos e diretórios. O exemplo a seguir combina o `zfs send` e o `zfs receive` usando um canal para copiar os dados de um pool para outro. Os dados podem ser usados ​​diretamente no pool de recebimento após a conclusão da transferência. Um conjunto de dados só pode ser replicado para um conjunto de dados vazio.

    # zfs snapshot mypool@replica1
    # zfs send -v mypool@replica1 | zfs receive backup/mypool
    send from @ to mypool@replica1 estimated size is 50.1M
    total estimated size is 50.1M
    TIME        SENT   SNAPSHOT

    # zpool list
    NAME    SIZE  ALLOC   FREE   CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
    backup  960M  63.7M   896M         -         -     0%     6%  1.00x  ONLINE  -
    mypool  984M  43.7M   940M         -         -     0%     4%  1.00x  ONLINE  -

#### 19.4.7.1. Backups Incrementais

O `zfs send` também pode determinar a diferença entre dois snapshots e enviar apenas as diferenças entre os dois. Isso economiza espaço em disco e tempo de transferência. Por exemplo:

    # zfs snapshot mypool@replica2
    # zfs list -t snapshot
    NAME                    USED  AVAIL  REFER  MOUNTPOINT
    mypool@replica1         5.72M      -  43.6M  -
    mypool@replica2             0      -  44.1M  -
    # zpool list
    NAME    SIZE  ALLOC   FREE   CKPOINT  EXPANDSZ   FRAG   CAP  DEDUP  HEALTH  ALTROOT
    backup  960M  61.7M   898M         -         -     0%    6%  1.00x  ONLINE  -
    mypool  960M  50.2M   910M         -         -     0%    5%  1.00x  ONLINE  -

Um segundo snapshot chamado `replica2` foi criado. Este segundo snapshot contém apenas as alterações feitas no sistema de arquivos entre o snapshot atual e o anterior, `replica1`. O uso do `zfs send -i` e a indicação do par de snapshots gera um fluxo de réplica incremental contendo apenas os dados que foram alterados. Isso só será bem-sucedido se o snapshot inicial já existir no lado do recebimento.

    # zfs send -v -i mypool@replica1 mypool@replica2 | zfs receive /backup/mypool
    send from @replica1 to mypool@replica2 estimated size is 5.02M
    total estimated size is 5.02M
    TIME        SENT   SNAPSHOT

    # zpool list
    NAME    SIZE  ALLOC   FREE   CKPOINT  EXPANDSZ   FRAG  CAP  DEDUP  HEALTH  ALTROOT
    backup  960M  80.8M   879M         -         -     0%   8%  1.00x  ONLINE  -
    mypool  960M  50.2M   910M         -         -     0%   5%  1.00x  ONLINE  -

    # zfs list
    NAME                         USED  AVAIL  REFER  MOUNTPOINT
    backup                      55.4M   240G   152K  /backup
    backup/mypool               55.3M   240G  55.2M  /backup/mypool
    mypool                      55.6M  11.6G  55.0M  /mypool

    # zfs list -t snapshot
    NAME                                         USED  AVAIL  REFER  MOUNTPOINT
    backup/mypool@replica1                       104K      -  50.2M  -
    backup/mypool@replica2                          0      -  55.2M  -
    mypool@replica1                             29.9K      -  50.0M  -
    mypool@replica2                                 0      -  55.0M  -

O fluxo incremental foi transferido com sucesso. Apenas os dados que foram alterados foram replicados, em vez da totalidade da `replica1`. Somente as diferenças foram enviadas, o que levou muito menos tempo para transferir e economizou espaço em disco por não copiar o pool completo novamente. Isso é útil quando se precisa confiar em redes lentas ou quando os custos por byte transferido devem ser considerados.

Um novo sistema de arquivos, `backup/mypool`, está disponível com todos os arquivos e dados do pool `mypool`. Se `-P` for especificado, as propriedades do dataset serão copiadas, incluindo configurações de compactação, cotas e pontos de montagem. Quando `-R` é especificado, todos os conjuntos de dados filho do dataset indicado serão copiados, juntamente com todas as suas propriedades. O envio e o recebimento podem ser automatizados para que backups regulares sejam criados no segundo pool.

#### 19.4.7.2. Envio de backups criptografados pelo SSH

O envio de fluxos pela rede é uma boa maneira de manter um backup remoto, mas apresenta uma desvantagem. Os dados enviados pelo link de rede não são criptografados, permitindo que qualquer pessoa intercepte e transforme os fluxos de volta em dados sem o conhecimento do usuário remetente. Isso é indesejável, especialmente ao enviar os fluxos pela Internet para um host remoto. O SSH pode ser usado para criptografar com segurança os dados enviados por uma conexão de rede. Como o ZFS requer apenas que o fluxo seja redirecionado da saída padrão, é relativamente fácil transmiti-lo através do SSH. Para manter o conteúdo do sistema de arquivos criptografado em trânsito e no sistema remoto, considere o uso do PEFS.

Algumas configurações e precauções de segurança devem ser concluídas primeiro. Apenas as etapas necessárias para a operação do `zfs send` são mostradas aqui. Para mais informações sobre o SSH, consulte Seção 13.8, “OpenSSH”.

Essa configuração é necessária:

- Acesso SSH sem senha entre o host de envio e recebimento usando chaves SSH

- Normalmente, os privilégios do usuário `root` são necessários para enviar e receber fluxos. Isso requer o login no sistema de recebimento como `root`. No entanto, o login como `root` vem desabilitado por padrão por motivos de segurança. O sistema ZFS Delegation pode ser usado para permitir que um usuário não `root` em cada sistema execute as respectivas operações de envio e recebimento.

- No sistema de envio:

      # zfs allow -u someuser send,snapshot mypool

- Para montar o pool, o usuário não privilegiado deve ser o dono do diretório e os usuários regulares devem poder montar sistemas de arquivos. No sistema de recebimento:

      # sysctl vfs.usermount=1
      vfs.usermount: 0 -> 1
      # sysrc -f /etc/sysctl.conf vfs.usermount=1
      # zfs create recvpool/backup
      # zfs allow -u someuser create,mount,receive recvpool/backup
      # chown someuser /recvpool/backup

O usuário sem privilégios agora tem a capacidade de receber e montar conjuntos de dados, e o conjunto de dados `home` pode ser replicado para o sistema remoto:

    % zfs snapshot -r mypool/home@monday
    % zfs send -R mypool/home@monday | ssh someuser@backuphost zfs recv -dvu recvpool/backup

Um snapshot recursivo chamado `monday` é composto do conjunto de dados do sistema de arquivos `home` que reside no pool `mypool`. Em seguida, ele é enviado com o `zfs send -R` para incluir o conjunto de dados, todos os conjuntos de dados filho, snapshots, clones e configurações no fluxo. A saída é canalizada para o `zfs receive` em espera no host remoto `backuphost` através do SSH. Recomenda-se a utilização de um nome de domínio totalmente qualificado ou do endereço IP. A máquina receptora grava os dados no conjunto de dados `backup` no pool `recvpool`. Adicionar `-d` ao `zfs recv` sobrescreve o nome do pool no lado de recebimento com o nome do snapshot. A opção `-u` faz com que os sistemas de arquivos não sejam montados no lado do recebimento. Quando `-v` é incluído, mais detalhes sobre a transferência são mostrados, incluindo o tempo decorrido e a quantidade de dados transferidos.

### 19.4.8. Cotas para Datasets, Usuários e Grupos

As cotas para dataset são usadas para restringir a quantidade de espaço que pode ser consumida por um determinado conjunto de dados. As cotas de referência funcionam basicamente da mesma maneira, mas contam apenas o espaço usado pelo próprio conjunto de dados, excluindo snapshots e conjuntos de dados filho. Da mesma forma, as cotas para usuário e para grupo podem ser usadas para impedir que usuários ou grupos usem todo o espaço do pool ou do conjunto de dados.

Para impor uma cota de dataser de 10 GB para o `storage/home/bob`:

    # zfs set quota=10G storage/home/bob

Para impor uma cota de referência de 10 GB para `storage/home/bob`:

    # zfs set refquota=10G storage/home/bob

Para remover uma cota de 10 GB do `storage/home/bob`:

    # zfs set quota=none storage/home/bob

O formato geral é `userquota@`user`=`size`` e o nome do usuário deve estar em um destes formatos:

- nome compatível com o POSIX, como `joe`.

- ID numérico POSIX, como `789`.

- nome SID, como `joe.bloggs@example.com`.

- ID numérico SID , como `S-1-123-456-789`.

Por exemplo, para impor uma cota de usuário de 50 GB para o usuário chamado `joe`:

    # zfs set userquota@joe=50G

Para remover qualquer cota:

    # zfs set userquota@joe=none

### Nota:

As propriedades da cota do usuário não são exibidas pelo `zfs get all`. Os usuários que não são o `root` só podem ver suas próprias cotas, a menos que tenham recebido o privilégio `userquota`. Os usuários com esse privilégio podem visualizar e definir a cota de todos.

O formato geral para definir uma cota de grupo é: `groupquota@`group`=`size``.

Para definir a cota do grupo `firstgroup` para 50 GB, use:

    # zfs set groupquota@firstgroup=50G

Para remover a cota do grupo `firstgroup` ou para certificar-se de que uma não está definida, use:

    # zfs set groupquota@firstgroup=none

Assim como a propriedade de cota do usuário, os usuários que não são `root` só podem ver as cotas associadas aos grupos aos quais eles pertencem. No entanto, o `root` ou um usuário com o privilégio `groupquota` pode visualizar e definir todas as cotas para todos os grupos.

Para exibir a quantidade de espaço utilizada por cada usuário em um sistema de arquivos ou snapshot junto com quaisquer cotas, use `zfs userspace`. Para informações de grupo, use `zfs groupspace`. Para obter maiores informações sobre opções suportadas ou sobre como exibir apenas opções específicas, consulte zfs(1).

Usuários com privilégios suficientes, e o `root`, podem listar a cota para `storage/home/bob` usando:

    # zfs get quota storage/home/bob

### 19.4.9. Reservas

As reservas garantem uma quantidade mínima de espaço sempre disponível em um conjunto de dados. O espaço reservado não estará disponível para nenhum outro conjunto de dados. Esse recurso pode ser especialmente útil para garantir que haja espaço livre disponível para um conjunto de dados ou arquivos de log importantes.

O formato geral da propriedade `reservation` é `reservation=`size``, portanto, para definir uma reserva de 10 GB em `storage/home/bob`, use:

    # zfs set reservation=10G storage/home/bob

Para cancelar qualquer reserva:

    # zfs set reservation=none storage/home/bob

O mesmo princípio pode ser aplicado à propriedade `refreservation` para definir uma Reserva de Referência, com o formato geral `refreservation=`size``.

Este comando mostra todas as reservas ou atualizações existentes no`storage/home/bob`:

    # zfs get reservation storage/home/bob
    # zfs get refreservation storage/home/bob

### 19.4.10. Compressão

O ZFS fornece compactação transparente. A compactação de dados no nível do bloco a medida que ele é escrito, não apenas economiza espaço, mas também pode aumentar a performance do disco. Se os dados forem compactados em 25%, mas os dados compactados forem gravados no disco na mesma taxa da versão descompactada, resulta em uma velocidade efetiva de gravação de 125%. A compactação também pode ser uma ótima alternativa para Deduplicação porque não requer memória adicional.

O ZFS oferece vários algoritmos de compactação diferentes, cada um com diferentes compensações. Com a introdução da compactação LZ4 no ZFS v5000, é possível ativar a compactação para todo o pool sem o trade-off de desempenho de outros algoritmos. A maior vantagem do LZ4 é o recurso early abort. Se o LZ4 não atingir pelo menos 12,5% de compactação na primeira parte dos dados, o bloco será gravado descompactado para evitar o desperdício de ciclos da CPU que tentam compactar dados já compactados ou não compactáveis. Para obter detalhes sobre os diferentes algoritmos de compactação disponíveis no ZFS, consulte a entrada Compactação na seção de terminologia.

O administrador pode monitorar a eficácia da compactação usando várias propriedades do conjunto de dados.

    # zfs get used,compressratio,compression,logicalused mypool/compressed_dataset
    NAME        PROPERTY          VALUE     SOURCE
    mypool/compressed_dataset  used              449G      -
    mypool/compressed_dataset  compressratio     1.11x     -
    mypool/compressed_dataset  compression       lz4       local
    mypool/compressed_dataset  logicalused       496G      -

O conjunto de dados está usando atualmente 449 GB de espaço (a propriedade used). Sem compressão, seriam necessários 496 GB de espaço (a propriedade `logicalused`). Isso resulta na taxa de compactação de 1,11: 1.

A compactação pode ter um efeito colateral inesperado quando combinada com cotas de usuário. As cotas de usuários restringem a quantidade de espaço que um usuário pode consumir em um conjunto de dados, mas as medidas são baseadas em quanto espaço é usado após a compactação. Portanto, se um usuário tiver uma cota de 10 GB e gravar 10 GB de dados compactáveis, eles ainda poderão armazenar dados adicionais. Se, posteriormente, atualizarem um arquivo, digamos um banco de dados, com dados mais ou menos compactáveis, a quantidade de espaço disponível para eles será alterada. Isso pode resultar na situação ímpar em que um usuário não aumentou a quantidade real de dados (a propriedade `logicalused`), mas a alteração na compactação fez com que eles atingissem seu limite de cota.

A compactação pode ter uma interação inesperada semelhante com backups. Muitas vezes, as cotas são usadas para limitar a quantidade de dados que podem ser armazenados para garantir que haja espaço de backup suficiente disponível. No entanto, uma vez que as cotas não consideram a compactação, mais dados podem ser gravados do que caberia com os backups descompactados.

### 19.4.11. Desduplicação

Quando ativado, a deduplicação usa o checksum de cada bloco para detectar blocos duplicados. Quando um novo bloco é uma duplicata de um bloco existente, o ZFS grava uma referência adicional aos dados existentes, em vez de todo o bloco duplicado. Uma enorme economia de espaço é possível se os dados contiverem muitos arquivos duplicados ou informações repetidas. Esteja avisado: a desduplicação requer uma quantidade extremamente grande de memória, e a maior parte da economia de espaço pode ser obtida sem o custo extra, permitindo a compactação.

Para ativar a deduplicação, defina a propriedade `dedup` no pool de destino:

    # zfs set dedup=on pool

Somente novos dados sendo gravados no pool serão desduplicados. Os dados que já foram gravados no pool não serão desduplicados simplesmente ativando essa opção. Um pool com uma propriedade de desduplicação ativada recentemente será semelhante a este exemplo:

    # zpool list
    NAME  SIZE ALLOC  FREE   CKPOINT  EXPANDSZ   FRAG   CAP   DEDUP   HEALTH   ALTROOT
    pool 2.84G 2.19M 2.83G         -         -     0%    0%   1.00x   ONLINE   -

A coluna `DEDUP` mostra a taxa real de deduplicação para o pool. Um valor de `1.00x` mostra que os dados ainda não foram desduplicados. No próximo exemplo, a árvore de ports é copiada três vezes em diretórios diferentes no pool desduplicado criado acima.

    # for d in dir1 dir2 dir3; do
    > mkdir $d && cp -R /usr/ports $d &
    > done

Dados redundantes são detectados e desduplicados:

    # zpool list
    NAME SIZE  ALLOC  FREE   CKPOINT  EXPANDSZ   FRAG  CAP   DEDUP   HEALTH   ALTROOT
    pool 2.84G 20.9M 2.82G         -         -     0%   0%   3.00x   ONLINE   -

A coluna `DEDUP` mostra um fator de `3.00x`. Várias cópias dos dados da árvore de ports foram detectadas e desduplicadas, usando apenas um terço do espaço. O potencial de economia de espaço pode ser enorme, mas com o custo de ter memória suficiente para rastrear os blocos desduplicados.

A desduplicação nem sempre é benéfica, especialmente quando os dados em um pool não são redundantes. O ZFS pode mostrar uma possível economia de espaço ao simular a desduplicação em um pool existente:

    # zdb -S pool
    Simulated DDT histogram:

    bucket              allocated                       referenced
    ______   ______________________________   ______________________________
    refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
    ------   ------   -----   -----   -----   ------   -----   -----   -----
         1    2.58M    289G    264G    264G    2.58M    289G    264G    264G
         2     206K   12.6G   10.4G   10.4G     430K   26.4G   21.6G   21.6G
         4    37.6K    692M    276M    276M     170K   3.04G   1.26G   1.26G
         8    2.18K   45.2M   19.4M   19.4M    20.0K    425M    176M    176M
        16      174   2.83M   1.20M   1.20M    3.33K   48.4M   20.4M   20.4M
        32       40   2.17M    222K    222K    1.70K   97.2M   9.91M   9.91M
        64        9     56K   10.5K   10.5K      865   4.96M    948K    948K
       128        2   9.50K      2K      2K      419   2.11M    438K    438K
       256        5   61.5K     12K     12K    1.90K   23.0M   4.47M   4.47M
        1K        2      1K      1K      1K    2.98K   1.49M   1.49M   1.49M
     Total    2.82M    303G    275G    275G    3.20M    319G    287G    287G

    dedup = 1.05, compress = 1.11, copies = 1.00, dedup * compress / copies = 1.16

Depois que o `zdb -S` termina de analisar o pool, ele mostra a taxa de redução de espaço que seria obtida ativando a deduplicação. Nesse caso, `1.16` é uma taxa de economia de espaço muito baixa e que poderia ser obtida apenas com a compactação. A ativação da deduplicação neste pool não salvaria uma quantidade significativa de espaço e não vale a quantidade de memória necessária para ativar a deduplicação. Usando a fórmula ratio = dedup * compress / copies, os administradores do sistema podem planejar a alocação de armazenamento, decidindo se a carga de trabalho conterá blocos duplicados suficientes para justificar os requisitos de memória. Se os dados forem razoavelmente compactáveis, a economia de espaço poderá ser muito boa. Recomenda-se ativar a compactação primeiro pois ela também pode aumentar significativamente a performance do sistema. Ative a deduplicação somente nos casos em que a economia adicional será considerável e se houver memória suficiente para o DDT.

### 19.4.12. ZFS e Jails

O `zfs jail` e a propriedade `jailed` correspondente são usadas para delegar um conjunto de dados ZFS para uma Jail. O `zfs jail `jailid`` anexa um dataset à jail especificada, e o `zfs unjail` o desanexa. Para que o conjunto de dados seja controlado de dentro de um jail, a propriedade `jailed` deve ser configurada. Depois que um conjunto de dados é anexado a um jail, ele não pode mais ser montado no host porque ele poderá ter pontos de montagem que comprometam a segurança do host.

Anterior | Acima | Próxima
19.3. Administração `zpool` | Principal | 19.5. Administração Delegada

All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/

Questions that are not answered by the documentation may be sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.