backup do pool ZFS usando o rsync

Question

Atualmente tenho uma caixa FreeNAS para armazenar meus arquivos pessoais. Eu gostaria de ter um backup fora do site, mas não estou disposto a gastar o dinheiro para um segundo computador capaz de executar o ZFS corretamente. Portanto, eu planejava fazer backups remotos usando rsync .

Gostaria que todos os arquivos do backup fossem consistentes, o que achei que poderia fazer tirando primeiro um instantâneo recursivo e depois transferindo-o usando rsync . Acontece, no entanto, que um instantâneo separado é tomado para cada conjunto de dados.

Agora estou pensando se há alguma maneira de visualizar um instantâneo recursivo, incluindo todos os conjuntos de dados, ou se há alguma outra maneira recomendada para rsync um todo zpool . Eu não acho que simplesmente criar links simbólicos para as pastas .zfs nos conjuntos de dados funcionará como eu gostaria que rsync mantivesse quaisquer links simbólicos que estão presentes nos próprios conjuntos de dados.

Editar

Com base nos comentários que recebi, acho que alguns detalhes sobre a minha configuração desejada estão em vigor. Eu estou olhando para ter um NAS em casa que eu possa confortavelmente colocar dados, sabendo que é improvável que eu vá perdê-lo. Para mim, isso significa ter várias cópias no local, várias cópias fora do local, uma cópia off-line no caso de as coisas ficarem realmente ruins, instantâneos periódicos dos dados em caso de exclusão acidental e um meio de evitar erros de dados (por exemplo, bit rot). Quanto menos provável a ocorrência do evento, mais relaxado eu fico em não ter várias cópias dos dados após uma catástrofe e menos eu me preocupo com os instantâneos. Além disso, eu me preocupo mais com dados antigos do que com novos dados, já que geralmente tenho uma cópia em outro dispositivo. Finalmente, devo observar que a maioria dos arquivos não é atualizada com muita frequência. A maioria das transferências será de novos arquivos.

Minha configuração anterior era um conjunto de dois Raspberry Pi com discos rígidos externos de 4TB conectados. Eu perdi a confiança nesta estratégia, mas tive o hardware prontamente disponível. Depois de algumas pesquisas, parecia que a única maneira de evitar que os erros se infiltrassem ao longo do tempo era usar um sistema de verificação de arquivos como o ZFS, combinado com componentes de nível de servidor, como a RAM ECC e um no-break. Para minha cópia local, eu segui esse caminho. Eu uso discos de 2x4TB no espelho e faço instantâneos regulares aqui.

Esta máquina deve cobrir todos os casos, exceto os backups off-site e off-line. Como provavelmente não precisarei desses backups, não estou disposto a investir muito nisso. Eu, portanto, imaginei que poderia ir com os Raspberry Pi's e discos externos que eu já tinha por aí. Eu poderia fazer com que um dos discos esteja sempre offline, enquanto o outro esteja recebendo os backups. Alterar os discos em intervalos regulares permitiria que eu fizesse um backup off-line dos meus dados mais antigos.

A rota direta seria usar zfs send e receive em dois pools, um em cada disco. O Raspberry Pi, combinado com a conexão USB ao disco rígido, não forneceria, no entanto, zfs (ou qualquer sistema de arquivos) um ambiente muito confiável para operar. Portanto, estou esperando que erros ocorram regularmente nesta configuração. . Como só usarei um disco, zfs não teria nenhum meio confiável para se recuperar de falhas.

Essa é a razão pela qual eu gostaria de ir com ext3 ou ext4 combinado com rsync . Claro, alguns bits ruins podem ser gravados no disco. No caso de metadados, existem ferramentas para corrigir a maioria desses problemas. No caso de blocos de dados, isso resultaria na perda de um único arquivo. Além disso, o arquivo poderia ser recuperado usando rsync -c , pois encontraria uma soma de verificação incorreta e transferiria o arquivo novamente da cópia em bom estado na máquina local. Dado o hardware menos que ideal, esta parece ser a melhor solução possível.

Esse é o meu raciocínio para usar rsync , o que me levou à questão original de como rsync a recusive zfs snapshot . Se eu não resolvi nenhum dos seus conselhos, por favor, deixe-me saber como estou realmente aberto a alternativas. Eu só não vejo como eles fornecem alguma vantagem para mim.

    

Answer 1

Você parece bem definido usando rsync e um RaspberryPi, então aqui está outra resposta com um pouco de informações sobre o cérebro que, esperamos, o ajudará a chegar a uma solução.

Now I'm wondering if there is any way to view a recursive snapshot, including all the datasets, or whether there is some other recommended way to rsync an entire zpool.

Não que eu saiba ... espero que as recomendações sejam da mesma forma que a minha outra resposta.

Se você estivesse satisfeito em simplesmente executar rsync no pool do ZFS montado, poderá excluir os diretórios .zfs (se estiverem visíveis para você) usando rsync --exclude='/.zfs/' ou definir a propriedade snapdir=hidden .

Isso causa problemas, já que cada conjunto de dados pode ser montado em qualquer lugar, e você provavelmente não vai querer perder nenhum ...

Você desejará gerenciar snapshots e criar um novo snapshot para " agora ", fazer o backup e provavelmente excluí-lo depois. Adotar essa abordagem (em vez de apenas usar os sistemas de arquivos montados " ao vivo ") fornecerá um backup consistente de um ponto no tempo. Ele também garantirá que você não faça backup de nenhuma hierarquia estranha ou perca nenhum sistema de arquivos que possa ser montado em outro lugar.

$ SNAPSHOT_NAME="rsync_$(date +%s)"
$ zfs snapshot -r ${ROOT}@${SNAPSHOT_NAME}
$ # do the backup...
$ zfs destroy -r ${ROOT}@${SNAPSHOT_NAME}

Em seguida, você precisará obter uma lista completa de conjuntos de dados dos quais deseja fazer backup executando zfs list -Hrt filesystem -o name ${ROOT} . Por exemplo, eu gostaria de fazer backup da minha árvore users , abaixo está um exemplo:

$ zfs list -Hrt filesystem -o name ell/users
ell/users
ell/users/attie
ell/users/attie/archive
ell/users/attie/dropbox
ell/users/attie/email
ell/users/attie/filing_cabinet
ell/users/attie/home
ell/users/attie/photos
ell/users/attie/junk
ell/users/nobody
ell/users/nobody/downloads
ell/users/nobody/home
ell/users/nobody/photos
ell/users/nobody/scans

Isto lhe dá uma lista recursiva dos sistemas de arquivos nos quais você está interessado ...

No entanto, você pode pular determinados conjuntos de dados e eu recomendo usar uma propriedade para isso - por exemplo, rsync:sync=true impediria a sincronização do conjunto de dados. Esta é a mesma abordagem que eu recentemente adicionado ao syncoid .

Os campos abaixo são separados por um caractere de tabulação.

$ zfs list -Hrt filesystem -o name,rsync:sync ell/users
ell/users   -
ell/users/attie -
ell/users/attie/archive -
ell/users/attie/dropbox -
ell/users/attie/email   -
ell/users/attie/filing_cabinet  -
ell/users/attie/home    -
ell/users/attie/photos  -
ell/users/attie/junk    false
ell/users/nobody    -
ell/users/nobody/downloads  -
ell/users/nobody/home   -
ell/users/nobody/photos -
ell/users/nobody/scans  -

Você também precisa entender que (como apontado acima) porque os conjuntos de dados do ZFS podem ser montados em qualquer lugar , não é realmente correto pensar neles como eles são apresentados no VFS ... Eles são entidades separadas e você deve tratá-las como tal.

Para conseguir isso, vamos nivelar os nomes dos sistemas de arquivos substituindo qualquer barra / por três underscores ___ (ou algum outro delimitador que normalmente não apareça no nome de um sistema de arquivos).

$ filesystem="ell/users/attie/archive"
$ echo "${filesystem//\//___}"
ell___users___attie___archive

Tudo isso pode ser reunido em um script simples ... algo assim:

OBSERVAÇÃO: Eu apenas testei isso brevemente ... e deve haver mais tratamento de erros.

#!/bin/bash -eu

ROOT="${ZFS_ROOT}"
SNAPSHOT_NAME="rsync_$(date +%s)"
TMP_MNT="$(mktemp -d)"

RSYNC_TARGET="${REMOTE_USER}@${REMOTE_HOST}:${REMOTE_PATH}"

# take the sanpshots
zfs snapshot -r "${ROOT}"@"${SNAPSHOT_NAME}"

# push the changes... mounting each snapshot as we go
zfs list -Hrt filesystem -o name,rsync:sync "${ROOT}" \
    | while read filesystem sync; do
        [ "${sync}" != "false" ] && continue
        echo "Processing ${filesystem}..."

        # make a safe target for us to use... flattening out the ZFS hierarchy
        rsync_target="${RSYNC_TARGET}/${filesystem//\//___}"

        # mount, rsync umount
        mount -t zfs -o ro "${filesystem}"@"${SNAPSHOT_NAME}" "${TMP_MNT}"
        rsync -avP --exclude="/.zfs/" "${TMP_MNT}/" "${rsync_target}"
        umount "${TMP_MNT}"
    done

# destroy the snapshots
zfs destroy -r "${ROOT}"@"${SNAPSHOT_NAME}"

# double check it's not mounted, and get rid of it
umount "${TMP_MNT}" 2>/dev/null || true
rm -rf "${TMP_MNT}"

    

Answer 2

Eu recomendo usar zfs send e zfs receive over rsync - ele será significativamente mais rápido e terá outros benefícios importantes (por exemplo: não falta de alterações, criptografia sem a necessidade das chaves).

Existem serviços de armazenamento que fornecerão a você a capacidade de enviar conjuntos de dados para eles (semelhante ao uso de um serviço que suporta rsync ).

Existe até uma boa ferramenta - syncoid (parte do projeto sanoid ) - que eu recomendo. Ele gerencia instantâneos e permite operações de pull ou .

Esta palestra discute as diferenças entre zfs send/recv e rsync .

Como acompanhamento, acabei de migrar do Obnam (que agora está aposentado) e decidi pelo ZFS com instantâneos. Eu também passei pelo processo de investigar serviços de armazenamento externo e (pela quantidade de armazenamento que eu preciso) concluí que construir e hospedar uma máquina em um local remoto funcionará mais barato do que usar um serviço de armazenamento dedicado antes a marca de ~ 1 ano ... embora, claro, tome sua própria decisão.

Para resolver algumas das suas declarações:

I'm not willing to spend the money for a second computer capable of running ZFS properly.

Vale a pena notar que o ZFS não tem que usar ECC RAM , e que você pode facilmente executa o ZFS em um único disco - é um backup externo, então isso pode ser aceitável para você.

For me building my own machine was about the same price as cloud storage.

Como observei acima, executei alguns cálculos e concluí que a criação de uma máquina externa barata resultaria menos dispendiosa do que pagar por um ano de " armazenamento em nuvem " de um provedor de serviços. Então eu paguei adiantado construindo essas máquinas, e dentro de um ano eu vou começar a ver a poupança. " armazenamento em nuvem " não é algo que você compra - você precisa continuar pagando por isso.

Também há outros benefícios - posso oferecer serviços e backups fora do local para a pessoa que hospeda minha máquina ... algo que, nesse caso, eles não possuíam.

    

Answer 3

Concordo com outras respostas que, em geral, é melhor usar zfs send .

No entanto, se você estiver determinado a usar rsync , e tudo o que você deseja é um instantâneo consistente de todo o pool, você pode fazer isso usando recursive zfs snapshot . Embora os instantâneos apareçam separadamente na saída de zfs list para cada conjunto de dados / volume afetado, eles são obtidos em um ponto consistente no tempo (ou seja, eles são "atômicos" - todos têm o mesmo txg , na linguagem interna do ZFS).