Porque é que um disco de cópia de segurança USB rodado passa a ter um caminho de montagem com um sufixo depois de reiniciar?

Um disco USB de cópia de segurança rodado pode obter um caminho de montagem com um sufixo quando o diretório preferido baseado na etiqueta já está ocupado, duplicado ou atribuído por outro montador automático.

A rotação de cópias de segurança utiliza frequentemente vários discos semelhantes, e os administradores podem clonar sistemas de ficheiros ou reutilizar a mesma etiqueta de volume por conveniência. Após um reinício, a ordem de deteção, a montagem automática do ambiente de trabalho, diretórios de montagem obsoletos, etiquetas duplicadas ou uma entrada fstab concorrente podem fazer com que um disco apareça num caminho como BACKUP_1 em vez de BACKUP. O disco pode estar saudável, enquanto a tarefa de cópia de segurança passa a visar o diretório errado. Verifique a identidade antes de mover ficheiros ou editar caminhos.

Identificar o sistema de ficheiros por trás do caminho inesperado

Registe o dispositivo real, o UUID do sistema de ficheiros, a etiqueta, o número de série ou caminho by-id, a origem da montagem, o destino, o tipo de sistema de ficheiros e as opções de todos os discos de rotação ligados.

O comando Linux findmnt associa um destino à sua origem ativa, evitando que um nome de pasta enganador seja confundido com o disco de cópia de segurança pretendido.

Se o diretório com sufixo pertencer ao UUID correto, o problema está na atribuição do caminho. Se pertencer a outro disco, pare a cópia de segurança antes que esta escreva no conjunto de rotação errado.

Verificar a existência de etiquetas ou UUID duplicados

Compare o UUID, a etiqueta, o PARTUUID, o número de série e os nomes by-id em todos os discos rodados, incluindo discos atualmente offline, caso existam registos.

A ArchWiki explica que as etiquetas são mais fáceis de duplicar do que os UUID, tornando arriscada a montagem automática baseada apenas em etiquetas quando vários discos de cópia de segurança partilham intencionalmente um nome amigável.

A clonagem de um sistema de ficheiros também pode clonar o respetivo UUID. Atribua uma identidade única ao sistema de ficheiros antes de depender da rotação não supervisionada e documente que disco físico corresponde a cada ID.

Compreender por que motivo os montadores automáticos adicionam um sufixo

Verifique se uma sessão de ambiente de trabalho, um serviço NAS, um auxiliar UDisks ou um gestor de suportes amovíveis montou o disco antes de o fstab ou o serviço de cópia de segurança atuar.

O Filesystem Hierarchy Standard permite que sejam anexados algarismos aos diretórios de montagem de suportes amovíveis quando mais de um dispositivo necessita de um local de montagem semelhante.

A política exata do sufixo varia consoante o montador automático, mas o princípio de diagnóstico é o mesmo: o caminho preferido estava indisponível ou era ambíguo quando o dispositivo foi ligado.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Verificar se o diretório de montagem preferido já estava ocupado

Inspecione o diretório esperado antes de ligar o disco. Determine se contém outra montagem, ficheiros dispersos escritos enquanto o disco estava ausente, uma montagem bind ou um diretório de trabalho obsoleto de um processo.

As orientações da Oracle para suportes amovíveis indicam que as etiquetas dos suportes são utilizadas para atribuir nomes aos caminhos de montagem, o que cria uma colisão quando vários objetos de suporte apresentam o mesmo caminho derivado da etiqueta.

Não elimine um diretório ocupado sem verificar primeiro se contém cópias de segurança escritas acidentalmente no sistema de ficheiros raiz. Mova os dados dispersos verificados através de um processo de recuperação controlado.

Definir um ponto de montagem fixo no fstab para cada disco de rotação

Escolha uma política estável: cada disco físico recebe o seu próprio diretório fixo ou um script de rotação monta o UUID atualmente selecionado num único caminho de cópia de segurança controlado, depois de verificar a identidade.

A Red Hat documenta a montagem persistente através do fstab com um UUID e um ponto de montagem fixo, eliminando a ordem de deteção e as colisões entre etiquetas amigáveis do caminho não supervisionado.

Não crie várias entradas ativas no fstab que concorram pelo mesmo diretório de destino. Um fluxo de rotação deve confirmar que o disco anterior está desmontado antes de ligar o seguinte.

Fazer com que o arranque da cópia de segurança dependa da montagem verificada

Verifique se o agendador é iniciado antes de a deteção e a montagem USB estarem concluídas. Adicione uma verificação preliminar do UUID, do ponto de montagem, do estado de escrita e do ficheiro marcador esperado.

A documentação Debian sobre montagens systemd explica que as entradas do fstab tornam-se dependências de montagem do systemd, permitindo que os serviços de cópia de segurança aguardem por uma montagem específica em vez de um diretório arbitrário.

Uma verificação que confirme apenas a existência do diretório é insuficiente, pois o diretório simples existe mesmo quando o disco está ausente. Valide a identidade do sistema de ficheiros montado.

Testar toda a rotação após reinícios e trocas de discos

Para cada disco, faça uma desmontagem limpa, desligue-o, reinicie, volte a ligá-lo, valide a identidade, efetue uma escrita descartável, faça um ensaio da cópia de segurança e verifique a leitura posterior. Registe o caminho e o UUID esperados.

O artigo da ZimaSpace sobre montagens por UUID e caminhos estáveis para aplicações aborda o conceito mais amplo de conceção com caminhos fixos; este artigo centra-se nas colisões criadas pela rotação de vários discos de cópia de segurança amovíveis.

O problema está resolvido quando cada disco de rotação corresponde ao caminho documentado após testes repetidos de reinício e troca, e a cópia de segurança se recusa a ser executada quando o UUID esperado está ausente ou montado noutro local.