No Backup, quando os números de inode do sistema de arquivos importariam?

Question

plano de fundo: Sendo um pouco covarde, tenho até dd sistemas de arquivos inteiros para backup. Grande desvantagem tornou-se o uso excessivo de memória para os backups completos (que, infelizmente, também incluíram blocos livres)

pergunta Eu gostaria de fazer backup agora apenas dos arquivos dentro do sistema de arquivos, mas ainda assim ser capaz de recriar o sistema de arquivos se necessário. Embora os dados possam ser facilmente extraídos (por exemplo, via rsync -a ),
Eu me pergunto, se existem alguns casos eu ignoro onde por exemplo o inode number atribuído ao arquivo importaria?

Isso é especificamente feito com o fundo de fazer backup do sistema de arquivos raiz / com o sistema nele. Eu não estou muito preocupado com o sistema de arquivos /home/ , mas seria imaginativo o suficiente para esperar que algo estranho pudesse estar ao restaurar o sistema de arquivos raiz / e, de repente, os inodes mudaram?

Uma boa resposta incluiria uma lista mais abrangente de casos em que o número do inode pode ser importante e causar problemas.

atualização Algumas experiências revelam que, por exemplo, os hard links (referenciando naturalmente o mesmo inode) podem precisar de alguma atenção. Não tenho certeza se eles precisam ser reatribuídos necessariamente o mesmo inode.

Felizmente o número de hardlinks em um Ubuntu 12.04 simples aqui é de apenas 10 arquivos (para que eu possa gravá-los e reparar se necessário e rsync -a não se importaria com o número de inode)

Exemplo Um caso que eu acho importante é o caso do módulo de segurança selinux , pois ele usa, de forma negativa, números de inode. Então isso já é um caso, mas talvez haja outros.

Update2 Acabei de executar um teste de backup e restaurar um sistema Ubuntu 12.04 fictício usando rsync -aH ao reformatar a partição entre para configurar um novo ext4 por mkfs.ext4 /dev/sdX -U oldfsUUID . Essencialmente, quando os arquivos foram restaurados, todos os inodes usados com mais frequência não estavam mais relacionados aos originais. Por sorte, parece que, para este caso da minha configuração do Ubuntu 12.04, os inodes não parecem importar. Estou ciente de que isso não prova muito. Eu ainda gostaria de receber uma resposta com uma lista de casos problemáticos. O selinux que eu já mencionei, mas acho que pode haver mais e, portanto, a chance de uma boa resposta de alguém que saiba.

    

Answer 1

Os números de inodes não importam para aplicativos normais. Isso ocorre em parte porque há pouco uso de números de inode e, em parte, porque, se um aplicativo dependesse de números de inode, ele deixaria de funcionar depois de um ciclo de backup e restauração. Portanto, os sistemas de backup não restauram os números de inode, portanto, os aplicativos não dependem deles, portanto, os sistemas de backup não precisam restaurar os números de inode.

A maioria das abordagens para backups não seria capaz de restaurar números de inodes. O driver do sistema de arquivos no kernel usa o inode que estiver livre ao criar um arquivo, não há como restringir isso dos aplicativos.

Alguns sistemas de arquivos nem possuem números de inodes.

A única coisa que os aplicativos usam números de inode é testar se dois caminhos designam o mesmo arquivo: compare o número do dispositivo e o número do inode, em um ponto específico no tempo. O número do dispositivo e o número do inode não precisam permanecer constantes ao longo do tempo para isso. Os próprios programas de backup fazem isso para detectar links físicos.

Não há como abrir um arquivo dado o seu número de inode, ou obter um arquivo para um caminho dado seu número de inode (excluindo ferramentas de depuração que requerem acesso ao dispositivo de bloco subjacente). Na maioria dos sistemas de arquivos, o caminho aponta para o inode, mas o inode não contém um ponteiro para o diretório que contém o arquivo, portanto, isso não poderia ser implementado sem atravessar todo o sistema de arquivos. Além disso, o arquivo pode até ser excluído (como em, pode ter uma contagem de link fixo de 0, esperando para ser fechado antes que seu conteúdo seja excluído e seu inode seja liberado).

O SELinux usa inodes para rastrear contextos, não números de inodes. Os contextos do SELinux são armazenados usando caminhos, como todo o resto.

rsync -AHX é uma maneira segura e comum de fazer backups.

Posso pensar em um aplicativo que usa números de inode: algumas versões de Rogue , um dos primeiros jogos baseados em terminal de tela cheia, o que motivou a biblioteca Curses ainda usada hoje. Ele armazena o número do inode em um arquivo salvo, para evitar a cópia casual de arquivos salvos. Eu nunca vi isso feito em um aplicativo "sério".