Uma restauração de um volume Docker pode recriar todos os bytes dos ficheiros e, ainda assim, eliminar os atributos estendidos quando o formato da cópia de segurança, as opções, os privilégios ou o destino não os conseguem preservar.
Os atributos estendidos são pares de metadados nome-valor armazenados fora do conteúdo normal dos ficheiros, da propriedade, dos bits de permissões e dos carimbos de data e hora. Podem conter dados de ACL, etiquetas SELinux, capacidades do Linux, marcadores de aplicações ou metadados do Samba. Uma cópia de segurança simples de um volume baseada em tar pode restaurar um diretório aparentemente completo, enquanto as aplicações se comportam de forma diferente porque o arquivo não registou os xattrs ou o processo de restauração não conseguiu escrever num espaço de nomes protegido.
Faça um inventário dos atributos da origem antes de repetir a restauração
Selecione ficheiros representativos e registe os respetivos hashes, proprietário, permissões, ACL e todos os nomes e valores dos atributos estendidos. Inclua os ficheiros que falham na aplicação após a restauração.
O modelo xattr do Linux separa os espaços de nomes user, system, security e trusted, cada um com requisitos de acesso e privilégios diferentes.
Se a origem não tiver xattrs, a restauração não os perdeu. Se desaparecer apenas um espaço de nomes, concentre-se nos privilégios, na política de segurança ou no suporte do destino, e não na camada de conteúdo dos ficheiros do arquivo.
Verifique o que o comando de cópia de segurança do Docker arquivou realmente
Guarde a imagem exata, o comando, o diretório de trabalho, o formato do arquivo, o utilizador, a origem montada e o destino da cópia de segurança montado utilizados pelo contentor de cópia de segurança.
O exemplo de cópia de segurança de volumes do Docker utiliza tar dentro de um contentor auxiliar, mas a preservação dos metadados continua a depender da implementação do tar e das opções selecionadas.
Um ficheiro de arquivo criado com sucesso prova que as entradas dos diretórios e os dados foram lidos, mas não que todos os espaços de nomes xattr foram incluídos. Inspecione o arquivo com a mesma ferramenta utilizada para o criar.
Ative os atributos estendidos durante a criação e extração do arquivo
Compare as opções do tar utilizadas na cópia de segurança e na restauração. Confirme que os xattrs foram ativados em ambas as direções e que os padrões de inclusão ou exclusão não removeram os espaços de nomes necessários.
O GNU tar indica que --xattrs armazena e restaura atributos estendidos.
Adicionar a opção apenas durante a extração não pode recuperar atributos que nunca foram armazenados. Crie um novo arquivo pequeno a partir de um ficheiro de origem com um xattr de teste conhecido e inspecione-o antes de alterar as cópias de segurança de produção.
Utilize as opções corretas de metadados do Rsync para cópias de segurança baseadas em ficheiros
Se a cópia de segurança do volume utilizar Rsync, inspecione as opções de arquivo, ACL, xattr, ID numérico, fake-super e privilégios tanto no emissor como no recetor.
O manual oficial do Rsync documenta -X para a preservação de atributos estendidos e descreve o armazenamento fake-super quando os metadados privilegiados não podem ser aplicados diretamente.
A opção de arquivo comum -a não inclui automaticamente todos os requisitos de ACL e xattr. Teste o comando exato nos sistemas de ficheiros reais da origem e do destino.
Verifique o suporte do sistema de ficheiros e da montagem no destino
Crie um ficheiro descartável diretamente no volume restaurado e tente definir, listar e remover um xattr de utilizador. Repita o processo através do anfitrião e através do contentor de cópia de segurança.
Utilize um utilitário de listagem de atributos tanto no anfitrião como no contentor de restauração para provar se o destino aceita e devolve xattrs, independentemente do arquivo de cópia de segurança.
Se a criação direta de xattrs falhar, verifique o tipo de sistema de ficheiros, as opções de montagem, o protocolo de rede, o controlador do volume e o suporte do equipamento de armazenamento. Nenhuma opção de arquivo pode restaurar metadados que o destino não consiga representar.
Verifique os privilégios para os espaços de nomes security e trusted
Registe o utilizador do contentor de restauração, as capacidades, o espaço de nomes de utilizadores, o modo rootless, a política SELinux e se o caminho do volume está montado como bind mount a partir do anfitrião.
A Red Hat documenta que as etiquetas SELinux podem necessitar de uma restauração de acordo com a política depois de os ficheiros serem copiados ou recriados.
Não conceda permanentemente privilégios amplos sobre o anfitrião a um contentor de cópia de segurança. Utilize um ambiente de restauração controlado ou restaure primeiro os dados normais e volte a aplicar as etiquetas geridas pela política com ferramentas suportadas.
Separe ACLs, capacidades e xattrs específicos das aplicações
Compare separadamente as entradas de ACL POSIX, as capacidades de ficheiros do Linux, as etiquetas SELinux, os xattrs de utilizador e os metadados do Samba ou do macOS. Podem falhar por motivos diferentes.
O módulo xattr_tdb do Samba pode armazenar os xattrs separadamente do sistema de ficheiros subjacente.
Por isso, um arquivo de volume ao nível dos ficheiros pode preservar a árvore de ficheiros visível, mas não uma base de dados separada de metadados do Samba. Inclua todos os armazenamentos de metadados dependentes ou reconstrua-os através do processo suportado pela aplicação.
Restaure um ficheiro de teste e valide a aplicação
Crie um ficheiro de origem conhecido com um hash do conteúdo, uma ACL, um xattr de utilizador e quaisquer metadados de aplicação necessários. Faça uma cópia de segurança e restaure-o num volume descartável.
O artigo da ZimaSpace sobre alterações de permissões e metadados em NAS aborda o comportamento mais amplo das migrações; este artigo isola a cópia de segurança e a restauração de volumes Docker.
O problema fica resolvido quando os hashes do conteúdo, os nomes e valores dos xattrs necessários, as ACLs, as etiquetas de segurança e o comportamento da aplicação correspondem após uma segunda cópia de segurança e restauração controladas.
Perguntas frequentes
Os atributos estendidos são o mesmo que as ACLs?
Não. As ACLs podem ser implementadas utilizando xattrs do sistema em alguns sistemas de ficheiros, mas os xattrs também armazenam etiquetas de segurança, capacidades, metadados de utilizador e valores específicos das aplicações.
O tar preserva os atributos estendidos por predefinição?
Não parta desse princípio. O GNU tar disponibiliza opções explícitas para xattrs, e o arquivo tem de armazenar os atributos durante a criação para que a extração os possa restaurar.
Uma restauração pode perder xattrs mesmo quando é executada como root?
Sim. O arquivo pode não os conter, o destino pode não os suportar, uma política de segurança pode rejeitá-los ou os metadados podem estar numa base de dados separada da aplicação.
Suporte e Dicas
Mais para Ler

Guia de armazenamento para gravação de TV em direto: capacidade, retenção e limpeza
Meça gravações reais, reserve margem de segurança, combine limites de idade e capacidade e confirme que o programa elegível mais antigo é removido antes...

Fluxo de recuperação de metadados de multimédia doméstica após o restauro de uma base de dados
Proteja o estado restaurado, verifique a identidade e os caminhos dos ficheiros multimédia e, em seguida, corrija as capas ou correspondências em falta numa...

Lista de verificação de compatibilidade do cliente Jellyfin para áudio, vídeo e legendas
Teste ficheiros representativos, uma variável de cada vez, e registe Direct Play, remux, conversão de áudio, transcodificação de vídeo ou falha para cada cliente.

