Uma mensagem do Duplicati a indicar que falta um .dblock.zip.aes a ausência de um ficheiro .dblock parece indicar corrupção da cópia de segurança, mas o tópico original mostra por que motivo a reparação destrutiva não deve ser a primeira reação. O destino da cópia de segurança existia no anfitrião ZimaOS e estava visível através do Samba, mas o contentor do Duplicati não conseguia realmente ver esse HDD através dos mapeamentos de volumes do Docker.
Depois de o utilizador mapear o HDD real do anfitrião para o contentor e selecionar o novo destino do lado do contentor, respondeu que parecia estar a funcionar. Assim, a origem terminou com uma solução confirmada de mapeamento de caminhos do Docker, e não com uma eliminação confirmada de uma cópia de segurança danificada.
O Erro Inicial Parecia Indicar um Repositório Duplicati Danificado
O Duplicati comunicou que a Reparação tinha falhado porque faltava um ficheiro encriptado específico no destino de armazenamento da cópia de segurança dblock ficheiro. A mensagem apresentava duas opções de recuperação: reconstruir ficheiros de blocos em falta a partir dos dados de origem locais ou eliminar entradas de cópia de segurança que já não podiam ser restauradas.
Essas opções são funcionalidades reais do Duplicati, mas só fazem sentido depois de verificar que o destino da cópia de segurança que está a ser inspecionado é o destino correto e completo.
O Utilizador Estava a Fazer Cópias de Segurança de Um Disco Local para Outro
A disposição pretendida era:
- dados de origem num SSD local;
- destino de cópia de segurança num HDD separado;
- O Duplicati foi instalado a partir da App Store do ZimaOS e, por isso, estava a ser executado no Docker.
O utilizador selecionou caminhos através do seletor de pastas da aplicação e presumiu que isso significava que o contentor podia ver o mesmo armazenamento do anfitrião.
Um Caminho do Anfitrião no ZimaOS e um Caminho do Contentor no Duplicati Não São a Mesma Coisa
Uma aplicação Docker só vê as pastas do anfitrião que tenham sido montadas no contentor. O ZimaOS pode aceder a um disco através de Ficheiros ou do Samba, enquanto o Duplicati não vê nada se esse disco estiver ausente da configuração de volumes da aplicação.
É por isso que um teste de ligação, por si só, pode induzir em erro: o tipo de destino pode ser válido, embora o conteúdo da pasta pretendida não esteja realmente visível no espaço de nomes do contentor.
O Teste com um Ficheiro Temporário Revelou o Problema Real
O utilizador criou um temp.txt ficheiro na pasta de destino. Este estava visível através do Samba, mas não no navegador de ficheiros do Duplicati. Isso era uma forte indicação de que o Duplicati não estava a ver o conteúdo real do HDD do anfitrião.
Nesse momento, o interveniente da comunidade mudou explicitamente de abordagem e recomendou não executar ainda a limpeza ou a reconstrução.
A Solução Funcional Foi Mapear o HDD para o Contentor
O interveniente instruiu o utilizador a abrir as definições da aplicação ZimaOS, adicionar o HDD como volume do anfitrião, mapeando-o para um caminho simples do contentor, como /backup, reinicie o contentor e, em seguida, escolha um destino dentro desse caminho do contentor.
O autor original respondeu: «Parece que agora funciona.»
Isso confirmou que o mapeamento do volume era a solução prática.
As Unidades de Origem Adicionais Precisam dos Seus Próprios Mapeamentos
O utilizador perguntou então se uma tarefa do Duplicati poderia conter várias pastas de origem. A resposta da comunidade foi sim, desde que todos os caminhos de origem também estejam visíveis dentro do contentor.
Se um segundo disco não estiver exposto através dos volumes Docker da aplicação, não aparecerá corretamente no Duplicati, independentemente da validade do caminho do anfitrião.
Utilize o Mapeamento Atual de Volumes das Aplicações do ZimaOS em Vez de Adivinhar Caminhos Brutos
O ZimaOS atualiza os caminhos do anfitrião e do contentor nas definições da aplicação e documenta a forma como o armazenamento persistente é mapeado para aplicações Docker.
Utilize o modelo atual de caminhos Docker do ZimaOS ao adicionar origens ou destinos de cópia de segurança.
Quando a Reparação do Duplicati é Adequada
A documentação atual da linha de comandos do Duplicati indica que a reparação pode reconstruir a base de dados local a partir do armazenamento remoto ou tentar reconstruir dados remotos em falta quando o conteúdo local necessário da origem ainda estiver disponível.
A opção avançada --rebuild-missing-dblock-files a opção tenta especificamente recriar ficheiros de blocos em falta a partir dos dados locais da origem, mas o Duplicati avisa que os dados podem ter sido alterados e que a recuperação pode ser incompleta ou demorada.
purge-broken-files É Destrutivo para o Histórico de Restauros
A documentação atual do Duplicati indica purge-broken-files remove ficheiros de versões de cópia de segurança que já não podem ser restauradas, para que o conjunto de cópias de segurança possa continuar. Só deve ser utilizado quando os dados remotos em falta não puderem ser recuperados.
Antes de efetuar a purga, consulte os comandos de recuperação atuais do Duplicati e as respetivas consequências. Uma simulação ou uma listagem de ficheiros danificados é mais segura do que eliminar cegamente o histórico das cópias de segurança.
A Mensagem de Erro Era Real, mas o Destino Subjacente Estava Errado
O Duplicati estava a indicar corretamente que a vista do repositório que conseguia ver não continha os ficheiros esperados. O fator enganador foi presumir que essa vista do repositório representava o HDD real. O mapeamento dos caminhos do Docker tinha apontado a aplicação para uma vista incompleta ou diferente do sistema de ficheiros.
FAQ sobre dblocks do Duplicati
Foi comprovado que o repositório de cópias de segurança da origem estava corrompido?
Não. O caso da origem foi resolvido depois de corrigir o mapeamento do volume do Docker.
A purga de ficheiros danificados deve ser o primeiro passo?
Não. Verifique se o destino completo correto está montado e visível antes de qualquer reparação destrutiva.
Pode uma tarefa do Duplicati fazer cópias de segurança de várias unidades do ZimaOS?
Sim, mas cada unidade de origem tem de ser mapeada para o contentor do Duplicati.
