A utilização de UUID do sistema de ficheiros impede que os caminhos das aplicações se alterem após o reinício?

As montagens de sistemas de ficheiros por UUID impedem que um nome de dispositivo alterado leve uma aplicação ao disco errado, mas, por si só, não garantem que o sistema de ficheiros seja montado no caminho esperado antes de a aplicação arrancar.

Uma configuração fiável combina uma identidade única do sistema de ficheiros, um ponto de montagem fixo, opções de montagem validadas, dependências dos serviços e uma configuração da aplicação que faça referência ao caminho estável no anfitrião. O UUID resolve uma camada desta cadeia.

Que problema resolve realmente uma montagem por UUID?

Os nomes de dispositivos Linux, como /dev/sdb1, dependem da ordem de deteção. Um UUID identifica o próprio sistema de ficheiros, permitindo ao sistema localizá-lo mesmo quando o kernel lhe atribui outro nome temporário de dispositivo.

Uma entrada em /etc/fstab associa então essa identidade a um diretório escolhido, como /srv/media. As aplicações podem utilizar esse diretório de forma consistente, mesmo que o nome do dispositivo subjacente mude.

Isto protege contra alterações na ordem dos dispositivos. Um guia detalhado sobre a montagem de discos com fstab explica porque é que a seleção do UUID é apenas uma parte da configuração; a reformatação, os UUID duplicados, os discos em falta e os destinos de montagem incorretos ainda podem causar problemas.

Que partes do caminho de uma aplicação ainda podem falhar?

A tabela explica porque é que uma aplicação pode continuar a indicar a falta de ficheiros, mesmo quando o UUID correto está presente. Siga o percurso desde a identidade do sistema de ficheiros, passando por cada montagem e mapeamento, até à localização exata guardada pela aplicação.

Como deve ser configurada a montagem por UUID?

Escolha um diretório de montagem pertencente ao sistema, que não mude com a sessão de início de sessão. Confirme o UUID e o tipo de sistema de ficheiros, faça uma cópia de segurança da configuração e adicione uma entrada testada.

UUID=8f12-example  /srv/appdata  ext4  defaults,nofail  0  2

Use nofail apenas quando for seguro continuar o arranque sem o disco. No caso de dados essenciais para a aplicação, continuar sem avisar pode ser mais perigoso do que uma falha visível do arranque ou do serviço.

Depois de editar, teste a configuração, inspecione a origem montada e confirme as permissões usando a mesma conta que executa a aplicação. Uma montagem bem-sucedida com privilégios de raiz não impede falhas de permissões da conta do serviço.

Como impedir que a aplicação arranque demasiado cedo?

Faça com que o serviço dependa da montagem, em vez de confiar no tempo médio de arranque. Uma explicação da ordem de montagem e das montagens automáticas do systemd mostra porque é que as dependências explícitas são importantes; o mesmo princípio explica porque é que a ordem de arranque causa falhas nas aplicações do servidor doméstico.

As pilhas de contentores só devem arrancar depois de o caminho do anfitrião conter o sistema de ficheiros montado esperado. Caso contrário, o ambiente de execução poderá montar como vínculo no contentor um diretório vazio do sistema de ficheiros raiz, e a aplicação poderá inicializar aí uma segunda biblioteca.

Adicione uma verificação prévia ao arranque para confirmar a existência de um ficheiro marcador conhecido, o UUID esperado ou o tipo de sistema de ficheiros. Isto transforma um arranque silencioso no caminho errado numa falha clara e recuperável.

O que acontece quando a montagem UUID falha?

O diretório de montagem continua a existir como um diretório normal no sistema de ficheiros principal. Uma aplicação pode escrever nesse diretório, e uma partição de sistema cheia pode afetar as aplicações NAS, mesmo que o disco de dados tenha espaço livre.

Quando o sistema de ficheiros real for montado mais tarde, esses ficheiros perdidos ficam ocultos por baixo dele. Continuam a ocupar espaço no volume raiz e reaparecem quando o sistema de ficheiros de dados é desmontado.

• Pare a aplicação antes de inspecionar a montagem.
• Confirme a origem com findmnt, em vez de se basear apenas no conteúdo dos diretórios.
• Verifique os registos de arranque e das unidades de montagem para detetar tempos limite ou erros do sistema de ficheiros.
• Inspecione o diretório de montagem vazio apenas enquanto o sistema de ficheiros estiver desmontado em segurança.
• Mova os dados dispersos apenas depois de os comparar com o conjunto de dados real da aplicação.

Não una duas bases de dados de aplicações às cegas. Determine qual das instâncias recebeu gravações e utilize o processo de recuperação ou importação suportado pela aplicação.

Os contentores precisam de UUID na sua configuração?

Normalmente, não. O anfitrião deve montar o sistema de ficheiros por UUID num caminho estável, e a configuração do contentor deve associar esse caminho do anfitrião a um caminho estável no contentor.

Por exemplo, o anfitrião pode montar em /srv/media, enquanto o contentor recebe o caminho como /media. A aplicação guarda /media, e o anfitrião continua responsável pela identidade persistente do dispositivo.

Esta separação mantém os detalhes do hardware fora do contentor. Ainda assim, documente ambos os lados do mapeamento, porque a alteração de qualquer um dos caminhos pode fazer com que uma biblioteca existente pareça vazia.

O que é um teste fiável após o reinício?

1. Confirme que o UUID esperado está presente e é único.
2. Confirme que está montado no caminho de anfitrião configurado.
3. Verifique o estado de leitura e escrita, a propriedade e a capacidade disponível.
4. Verifique se o serviço arrancou depois da montagem.
5. Inspecione os caminhos de origem e destino do contentor ou da montagem vinculada.
6. Abra um ficheiro conhecido e crie, através da aplicação, um objeto de teste descartável.
7. Configure alertas para futuras falhas de montagem ou de verificações pré-arranque.

Repita este teste após alterações ao kernel, ao armazenamento, ao tempo de execução de contentores ou ao sistema de ficheiros. A persistência é uma propriedade operacional que deve ser monitorizada, não uma suposição de configuração feita uma única vez.

FAQ

Um UUID do sistema de ficheiros pode mudar?

Sim. A reformatação cria um novo sistema de ficheiros e, geralmente, um novo UUID. As ferramentas de administração também o podem alterar, e a clonagem pode criar duplicados.

Um rótulo do sistema de ficheiros é tão seguro como um UUID?

Os rótulos são mais fáceis de ler, mas também mais fáceis de duplicar ou alterar. Em geral, os UUID são mais seguros para montagens não supervisionadas, desde que a sua unicidade tenha sido verificada.

Porque é que a aplicação criou uma nova biblioteca vazia depois do reinício?

A aplicação provavelmente arrancou quando o sistema de ficheiros real estava ausente e inicializou os dados no diretório de montagem vazio ou noutro caminho alternativo.

Os pontos de montagem por UUID evitam alterações inesperadas nos nomes dos dispositivos, mas, para garantir caminhos de aplicação resilientes, toda a cadeia de dependências tem de ser explícita, testável e monitorizada.