Como configurar o Btrfs Send e Receive para cópias de segurança incrementais externas

Eva Wong

IceWhale author

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

How to Configure Btrfs Send and Receive for Incremental Off-Site Backups - Zima Store Online

O envio e a receção Btrfs podem transformar instantâneos de subvolumes só de leitura numa cadeia eficiente de replicação externa. A primeira transferência envia um instantâneo completo. As transferências seguintes utilizam um instantâneo previamente replicado como elemento principal, pelo que apenas as alterações necessárias para reconstruir o novo instantâneo atravessam a rede.

No ZimaOS, confirme primeiro se a origem e o destino externo são realmente sistemas de ficheiros Btrfs e se o acesso SSH está disponível. O guia de formatos de disco da ZimaSpace indica suporte de leitura/escrita para BTRFS, e o guia de SSH do ZimaOS mostra como ativar o acesso ao terminal a partir do Modo de programador.

Compreender a cadeia de cópias de segurança antes de começar

O envio e a receção Btrfs são replicação de subvolumes, não um comando genérico para copiar diretórios. A origem tem de ser um subvolume Btrfs, e todos os instantâneos utilizados por btrfs send tem de ser só de leitura. Uma montagem só de leitura não substitui um instantâneo de subvolume só de leitura.

A documentação oficial do btrfs send descreve dois modos. Um envio completo contém o instantâneo completo. Um envio incremental utiliza -p ou -c com instantâneos disponíveis no mesmo estado no emissor e no recetor.

Para uma cadeia externa simples, utilize um elemento principal explícito com -p:

snapshot-A  --full send-->  instantâneo externo-A
snapshot-B  --send -p A-->  instantâneo externo-B
snapshot-C  --send -p B-->  instantâneo externo-C

Não elimine nem modifique o elemento principal atual até a próxima transferência incremental estar concluída e verificada.

Verificar se a origem é um subvolume Btrfs

Substitua os caminhos de exemplo pelos pontos de montagem reais do seu sistema. O diretório dos instantâneos deve ficar fora do subvolume de origem ativo, para que os instantâneos de cópia de segurança não fiquem aninhados nos dados protegidos.

findmnt -no FSTYPE --target /mnt/pool/data
sudo btrfs subvolume show /mnt/pool/data
sudo btrfs version

O primeiro comando deve apresentar btrfs. O segundo deve identificar corretamente /mnt/pool/data como subvolume. Se for apenas um diretório normal, pare aqui: btrfs send não pode enviar um diretório arbitrário.

Execute a mesma verificação do sistema de ficheiros no sistema externo, para o local de receção. btrfs receive tem de criar o seu subvolume replicado num sistema de ficheiros Btrfs.

Preparar o SSH antes de transmitir dados de cópia de segurança

Um fluxo de transmissão externo é constituído por dados binários do sistema de ficheiros. O SSH é um transporte prático porque fornece autenticação e encriptação durante o trânsito. Se estiver a utilizar o ZimaOS em qualquer um dos pontos terminais, ative primeiro o SSH e teste um início de sessão normal antes de tentar um fluxo Btrfs.

ssh backup@backup.example.net

Para tarefas não assistidas, utilize autenticação SSH baseada em chaves. A conta remota também tem de conseguir executar btrfs receive de forma não interativa. Não permita que um sudo pedido de palavra-passe lido a partir da mesma entrada padrão que transporta o fluxo Btrfs. Uma regra de privilégios limitada à operação de receção necessária é mais segura do que um acesso root amplo sem palavra-passe.

Crie o diretório de destino durante uma sessão administrativa interativa:

ssh -t backup@backup.example.net \
  'sudo mkdir -p /mnt/backup/btrfs-recv'

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

Criar o primeiro instantâneo só de leitura

Crie um instantâneo fixo e só de leitura do subvolume de origem ativo. A -r esta opção é importante porque a transmissão incremental do Btrfs depende de instantâneos que não podem ser alterados durante a operação de transmissão.

sudo mkdir -p /mnt/pool/.snapshots

sudo btrfs subvolume snapshot -r \
  /mnt/pool/data \
  /mnt/pool/.snapshots/data-20260831-1000

Confirme a propriedade antes de enviar:

sudo btrfs property get \
  /mnt/pool/.snapshots/data-20260831-1000 ro

O resultado esperado é ro=true.

Enviar o primeiro instantâneo completo para fora do local

A primeira transferência não tem progenitor, por isso é uma transmissão completa. Numa shell compatível com Bash, ative pipefail torna visível à shell chamadora uma falha em qualquer um dos lados do pipeline.

set -o pipefail

sudo btrfs send \
  /mnt/pool/.snapshots/data-20260831-1000 \
  | ssh backup@backup.example.net \
  'sudo -n btrfs receive /mnt/backup/btrfs-recv'

Se sudo -n falhar no anfitrião remoto, corrija a configuração de privilégios remotos antes de tentar novamente. Não o substitua por um pedido de palavra-passe dentro do pipeline de transmissão.

A documentação oficial do btrfs receive indica que um subvolume recebido passa a ser só de leitura. Também avisa que os utilizadores não devem modificar o caminho de receção enquanto um fluxo estiver a ser aplicado.

Verificar o instantâneo recebido antes de o utilizar como progenitor

Não assuma que o fim de uma sessão SSH significa que a cadeia de cópias de segurança está íntegra. Inspecione ambos os instantâneos:

sudo btrfs subvolume show \
  /mnt/pool/.snapshots/data-20260831-1000

ssh backup@backup.example.net \
  'sudo -n btrfs subvolume show \
  /mnt/backup/btrfs-recv/data-20260831-1000'

No emissor, anote o instantâneo UUIDNo recetor, o subvolume replicado deverá apresentar esse identificador de origem como seu UUID recebidoConfirme também que o subvolume recebido é só de leitura.

Só depois desta verificação deverá data-20260831-1000 tornar-se o progenitor do próximo backup incremental.

Crie e envie o próximo instantâneo incremental

Depois de os dados ativos serem alterados, crie um novo instantâneo só de leitura:

sudo btrfs subvolume snapshot -r \
  /mnt/pool/data \
  /mnt/pool/.snapshots/data-20260901-0200

Em seguida, envie apenas o delta do instantâneo anterior:

set -o pipefail

sudo btrfs send \
  -p /mnt/pool/.snapshots/data-20260831-1000 \
  /mnt/pool/.snapshots/data-20260901-0200 \
  | ssh backup@backup.example.net \
  'sudo -n btrfs receive /mnt/backup/btrfs-recv'

Isto funciona porque o instantâneo progenitor do primeiro envio ainda existe, de forma correspondente, em ambos os sistemas. Depois de o novo instantâneo ser recebido e verificado com sucesso, data-20260901-0200 pode tornar-se o progenitor da execução seguinte.

Mantenha os instantâneos progenitores idênticos

A forma mais comum de quebrar uma cadeia incremental é alterar o estado de só de leitura ou o conteúdo de um instantâneo que esteja a ser utilizado como progenitor. O Btrfs regista os instantâneos recebidos com um UUID recebido especificamente para que o emissor e o recetor possam identificar o histórico correspondente.

As orientações oficiais do Btrfs sobre flags dos subvolumes e UUID recebidos alertam para o facto de que alterar um instantâneo recebido de só de leitura para leitura e escrita quebra os pressupostos utilizados pelo envio incremental.

Por esse motivo, não torne gravável o instantâneo recebido externamente apenas para navegar, restaurar ou editar ficheiros. Se precisar de uma cópia de recuperação gravável, crie um instantâneo separado a partir do instantâneo recebido protegido:

sudo btrfs subvolume snapshot \
  /mnt/backup/btrfs-recv/data-20260901-0200 \
  /mnt/restore/data-20260901-0200

O novo instantâneo de recuperação é gravável por predefinição, enquanto o instantâneo recebido original permanece intacto para futuros envios incrementais.

Utilize uma regra segura de retenção de instantâneos

Não precisa de manter todos os instantâneos antigos para sempre, mas tem de manter, em ambos os sistemas, o progenitor necessário para o próximo envio. Uma regra de rotação simples é:

Crie o novo instantâneo de origem só de leitura.
Envie-o utilizando o instantâneo anterior recebido com sucesso como -p.
Verifique o novo instantâneo recebido externamente.
Promova o novo instantâneo para ser o próximo progenitor.
Só depois remova os pontos de recuperação mais antigos de acordo com a sua política de retenção.

Manter vários instantâneos históricos pode fornecer pontos de recuperação úteis, mas lembre-se de que um instantâneo no mesmo sistema de ficheiros não é uma cópia de segurança independente. A réplica externa é valiosa porque coloca outra cópia num sistema e local separados. O guia de cópias de segurança 3-2-1 da ZimaSpace explica por que motivo uma cópia externa protege contra falhas que a redundância local não consegue abranger.

Lidar separadamente com subvolumes Btrfs aninhados

Os instantâneos Btrfs não são recursivos entre subvolumes aninhados. Se /mnt/pool/data contém outro subvolume, o instantâneo principal contém um stub de subvolume em vez de um instantâneo completo dos dados aninhados.

Liste os subvolumes antes de finalizar o plano de cópia de segurança:

sudo btrfs subvolume list /mnt/pool

Se existirem dados de aplicações importantes em subvolumes aninhados, crie e replique uma cadeia separada de instantâneos só de leitura para cada um.

Saiba quando utilizar -p e quando utilizar -c

Para um histórico de cópias de segurança linear, -p é a opção mais simples e fácil de auditar. A opção -c A opção pode adicionar uma ou mais origens de clonagem que permitem ao Btrfs reutilizar extensões correspondentes de instantâneos adicionais, mas essas origens de clonagem também têm de existir exatamente no mesmo estado em ambas as extremidades.

Se não conseguir provar que uma origem de clonagem não foi alterada e está presente em ambos os sistemas, não a utilize. Uma cadeia simples com um único principal é normalmente mais segura para uma tarefa de cópia de segurança fora do local.

Opcional: utilizar o protocolo 2 para extensões comprimidas

Em versões suficientemente recentes do Linux e do btrfs-progs, o protocolo de envio 2 do Btrfs pode transmitir extensões comprimidas de forma mais eficiente com --compressed-data. A documentação oficial do envio indica que o protocolo 2 requer o btrfs-progs 6.0 ou posterior em ambos os emissores e recetores, e o Linux 6.0 ou posterior no emissor.

sudo btrfs send \
  --proto 2 \
  --compressed-data \
  -p /mnt/pool/.snapshots/data-20260831-1000 \
  /mnt/pool/.snapshots/data-20260901-0200 \
  | ssh backup@backup.example.net \
  'sudo -n btrfs receive /mnt/backup/btrfs-recv'

Não ative esta opção apenas porque ela existe. Verifique primeiro as versões em ambos os pontos finais e utilize o protocolo predefinido quando a compatibilidade for mais importante do que a otimização.

Resolução de problemas comuns em falhas de envio e receção incrementais

O comando de envio indica que o instantâneo não é só de leitura

Recrie o instantâneo com btrfs subvolume snapshot -r. Montar simplesmente um instantâneo gravável através de uma montagem só de leitura não satisfaz o requisito de envio.

O envio incremental não consegue encontrar nem utilizar o principal

Verifique se o instantâneo principal exato ainda existe no emissor e se o instantâneo recebido correspondente ainda existe no recetor. Se algum dos principais tiver sido eliminado, alterado ou tornado gravável, restaure um principal correspondente, se tiver um. Caso contrário, crie um novo instantâneo só de leitura e inicie uma nova propagação completa.

o btrfs receive indica que o subvolume de destino já existe

btrfs receive não substituirá um subvolume existente com o mesmo nome recebido. Inspecione primeiro o subvolume existente. Se for uma receção falhada ou incompleta e tiver confirmado que é seguro removê-la, elimine esse subvolume incompleto antes de tentar novamente a mesma transferência.

O principal de receção foi modificado depois de ser recebido

Não utilize esse instantâneo modificado como base de um novo fluxo incremental. Se não existir um principal de receção correspondente e inalterado, inicie uma nova cadeia de cópia de segurança completa.

Faltam ficheiros dentro de um diretório aninhado no instantâneo

Verifique se esse diretório é, por si só, um subvolume Btrfs. Os subvolumes aninhados não são incluídos recursivamente no instantâneo principal e precisam da sua própria cadeia de envio/receção.

A ligação WAN ou SSH cai durante uma transferência

Considere a receção falhada, a menos que seja concluída com sucesso e o subvolume resultante seja verificado corretamente. A interface documentada de comandos de envio/receção do Btrfs não fornece uma opção para retomar o fluxo. Para ligações de longa distância pouco fiáveis, considere escrever o fluxo de envio num ficheiro de preparação, transferir esse ficheiro com um transporte retomável e, em seguida, fornecer o ficheiro fidedigno concluído a btrfs receive.

Proteja o lado da receção contra fluxos não fidedignos

A receção do Btrfs aplica operações do sistema de ficheiros provenientes do fluxo recebido. A documentação oficial da receção recomenda não aceitar fluxos de envio de fontes não fidedignas e proteger o caminho de receção contra escritas simultâneas enquanto um fluxo está a ser aplicado.

Utilize verificação do anfitrião SSH, autenticação baseada em chaves, uma conta de cópias de segurança dedicada e os privilégios mais restritos possíveis. Mantenha o diretório de receção fora dos caminhos normais de escrita dos utilizadores enquanto uma cópia de segurança estiver a decorrer.

Utilize esta lista de verificação em cada execução incremental

Confirme que ambas as extremidades são Btrfs.
Crie o novo instantâneo da origem com -r.
Mantenha o principal anterior concluído com sucesso inalterado em ambos os sistemas.
Envie com btrfs send -p OLD NEW.
Receba através de uma ligação SSH autenticada e encriptada.
Verifique o sucesso e compare o UUID da origem com o UUID Received do recetor.
Mantenha o instantâneo de cópia recebido como só de leitura.
Crie um instantâneo gravável separado quando precisar de restaurar ou testar dados.
Rode os instantâneos antigos apenas depois de verificar o novo principal.
Faça cópias de segurança de subvolumes aninhados com cadeias separadas.

Quando uma cópia inicial completa e uma execução incremental forem concluídas manualmente com sucesso, automatize a mesma sequência com registo e verificações explícitas do estado de saída. O importante não é o agendador: é preservar um instantâneo principal inalterado e verificado em ambas as extremidades de cada passo incremental.