Por que é que uma cópia espelho Rsync copia exclusões acidentais para o backup?

Um espelho rsync copia eliminações acidentais porque um espelho é projetado para fazer o destino corresponder à origem atual. Quando o trabalho usa --delete ou uma opção de eliminação relacionada, um ficheiro em falta no NAS doméstico é tratado como um ficheiro extra no destino de backup e é removido durante a sincronização. Esse comportamento é correto para um espelho, mas é inseguro como único histórico de recuperação.

O rsync segue uma regra de espelho, não preserva todas as versões passadas

Sem uma opção de eliminação, o rsync normalmente copia ficheiros novos e alterados, mas mantém os ficheiros apenas do destino no lugar. Com --delete, o destino é reconciliado com a origem. Uma explicação concisa da flag afirma que apagar um ficheiro da origem também o remove do destino para que o destino permaneça um verdadeiro espelho.

Para um NAS doméstico ZimaSpace, isto significa uma foto de família apagada, pasta de mídia renomeada, configuração de contentor removida, ou montagem temporariamente em falta que pode ser refletida no espelho USB ou remoto na próxima execução agendada.

A eliminação começa com um caminho da origem em falta

O rsync não sabe se um ficheiro desapareceu porque o apagou intencionalmente, uma aplicação o limpou, um utilizador cometeu um erro, ransomware alterou a árvore, ou um conjunto de dados da origem falhou na montagem. Compara a árvore visível da origem com a do destino. Se um objeto existir apenas no lado do destino e a eliminação estiver ativada, torna-se candidato à eliminação.

O momento da eliminação altera quando os ficheiros são removidos, não se são removidos.

As opções relacionadas controlam a fase da transferência. --delete-before remove ficheiros apenas do destino antes de copiar, --delete-during apaga enquanto os diretórios são processados, e --delete-after espera até as transferências terminarem. Elas afetam o comportamento do espaço livre e a exposição a falhas, mas não transformam o espelho numa cópia de segurança versionada.

Use o tempo deliberadamente. Apagar antes da transferência pode libertar capacidade, mas remove o estado anterior do espelho mais cedo. Apagar depois da transferência preserva o conteúdo antigo do destino por mais tempo, mas o resultado final ainda corresponde à origem se o trabalho for concluído.

Uma montagem em falta pode parecer uma eliminação em massa

Um dos casos mais perigosos em servidores domésticos ocorre quando o caminho de origem agendado ainda existe como um diretório vazio após a falha na montagem do pool de armazenamento real. O rsync pode então comparar uma origem vazia com um destino populado. Uma salvaguarda proposta é executar uma verificação seca e contar as eliminações planeadas antes de permitir a sincronização real.

Num NAS doméstico, faça o trabalho falhar se a montagem da origem esperada, UUID do sistema de ficheiros, diretório marcador ou contagem mínima de ficheiros estiverem em falta. Não permita que a existência de um caminho vazio conte como uma origem saudável.

Pause o trabalho antes de tentar recuperar um ficheiro eliminado

1. Desative imediatamente a tarefa rsync agendada.
2. Não execute o comando novamente para “ver se se resolve sozinho.”
3. Verifique snapshots, contentores de reciclagem, repositórios de backup versionados e a segunda cópia offline.
4. Se o espelho ainda contiver o ficheiro, copie-o para um caminho de quarentena fora do destino rsync antes da próxima execução.
5. Confirme se a eliminação da origem foi intencional antes de a restaurar na partilha ativa.

O artigo da ZimaSpace sobre manter fotos de família em múltiplas cópias independentes é relevante aqui: um espelho sincronizado deve ser uma camada, não o único local onde um ficheiro mais antigo pode sobreviver.

Pré-visualize o conjunto exato de eliminações

Execute o mesmo comando com --dry-run, itemização detalhada e relatório de eliminações. Reveja os caminhos de origem e destino, barras finais, exclusões, estado da montagem e o número de eliminações planeadas. Um artigo recente sobre segurança do rsync enfatiza que um espelho pode reproduzir eliminações acidentais ou danos por ransomware e, por isso, necessita de uma camada de histórico separada.

rsync -a --delete --dry-run --itemize-changes   /srv/storage/family/ /mnt/usb-mirror/family/

Trate uma contagem de eliminações inesperadamente alta como uma verificação prévia falhada. Pare e verifique se o conjunto de dados NAS pretendido está montado e se o comando não está direcionado para um diretório pai ou para o disco removível errado.

Mover ficheiros de destino eliminados para uma área de recuperação

Se precisar de um espelho mas também quiser uma janela curta de recuperação, combine a eliminação com um diretório de backup ou camada de snapshot. O Rsync pode mover ficheiros substituídos ou eliminados do destino para um diretório de recuperação datado em vez de os destruir imediatamente. A orientação da comunidade para reter dados eliminados pelo rsync recomenda manter ficheiros eliminados numa localização separada com a sua própria política de limpeza.

rsync -a --delete   --backup   --backup-dir="/mnt/usb-mirror/deleted/$(date +%F)"   /srv/storage/family/ /mnt/usb-mirror/current/

Teste o comando primeiro com dados não críticos. O diretório de recuperação deve estar fora da subárvore espelhada, ou uma execução futura pode tratá-lo como parte da origem ou eliminá-lo pela mesma política.

Use Snapshots Versionados Quando os Estados Passados Importam

Um espelho atual responde “como é que a origem está agora?” Um backup responde “como era a origem antes do erro?” Se precisar de ambos, mantenha o espelho para acesso rápido e adicione snapshots do sistema de ficheiros, diretórios de snapshot com hard-link, uma ferramenta de backup versionada ou um segundo disco offline.

Um relato de eliminação acidental com rsync descreve claramente a fraqueza subjacente: um fluxo de trabalho rsync feito à mão precisa de salvaguardas explícitas para rotação e eliminação. Não confie num único destino mutável para fornecer sincronização exata e histórico a longo prazo.

Perguntas Frequentes

Se eu remover --delete, o espelho torna-se um backup?

Não por si só. Os ficheiros exclusivos do destino permanecerão, mas os ficheiros sobrescritos podem perder o seu conteúdo anterior, e não existe um ponto de restauração limpo para uma data específica. Adicione snapshots ou um repositório de backup versionado.

Qual a opção de temporização de eliminação mais segura?

--delete-after adianta as eliminações até as transferências terminarem, o que preserva o estado antigo do destino por mais tempo durante a execução. Ainda assim elimina ficheiros exclusivos do destino no final, por isso verificações prévias e histórico de versões continuam a ser necessários.

Como posso parar uma eliminação em massa inesperada?

Desative o agendamento, execute uma simulação com saída de eliminação, verifique a montagem e o caminho da origem, e defina um limite de contagem de eliminações ou verificação de ficheiro marcador. Não execute novamente o comando em direto até compreender a lista proposta de eliminações.

Conclusão Final

O Rsync reflete eliminações acidentais porque as opções de eliminação fazem com que o destino do backup corresponda à origem NAS visível. Proteja o fluxo de trabalho do servidor doméstico ZimaSpace verificando montagens, pré-visualizando eliminações, colocando ficheiros removidos em quarentena e mantendo pontos de recuperação versionados ou offline. Um espelho pode ser útil, mas um espelho exato sem histórico não é proteção suficiente contra erros humanos.