Debian 8.9 restaura arquivos apagados, mas bloqueados

0

Eu acidentalmente corri rm -R / home /. Meu Homefolder continha vários discos de máquinas virtuais que estavam em uso no momento. Eu também recebi o erro, que alguns arquivos não poderiam ter sido excluídos. No entanto, não consigo mais acessar os arquivos em minha pasta / home /.

Procurando uma solução, descobri que poderia tentar restaurar os arquivos com cp / proc / PID / fd / 12 / target /.

Agora estou um pouco confuso - como a máquina virtual ainda está funcionando, provavelmente grava no disco que estou tentando recuperar.

Terei inconsistências nesses discos? Ou você talvez tenha outra dica?

Eu aprecio todo tipo de ajuda!

Muito obrigado!

    
por SevenOfNine 13.02.2018 / 08:18

1 resposta

1

Um arquivo em um determinado sistema de arquivos é referenciado por seu nó de índice aka inode . Contanto que haja referências a este inode, seja em disco (ligado como nome (s) de arquivo (s), pode existir várias vezes) ou "na memória" (descriptor de arquivo aberto aka fd, ponto de montagem, mmaped ...) o arquivo e seus dados ficam no disco. Quando não há mais referência a ele, ele é realmente excluído e o espaço é recuperado. Quando a referência de disco se torna 0, mesmo que ainda existam referências "na memória", não há maneira de revinculá-la com um novo nome, porque não há API do kernel para o usuário permitindo, por exemplo, vincular um inode referenciado por seu fd ou próprio valor de inode, só está disponível por nome de arquivo (a menos que em um sistema de arquivos adequado usando magia escura e perigosa : debugfs ln ).

O kernel do Linux ainda oferece alguns recursos para acessar esse arquivo com o /proc pseudo filesystem. Cada arquivo aberto em /proc/PID/fd/ é exibido como um link simbólico apontando para um arquivo. O nome do arquivo é informação cosmética (e pode estar errado quando o arquivo foi desvinculado), mas o arquivo em si deve ser considerado como o arquivo real, como visto pelo kernel.

Portanto, para este caso, enquanto a VM estiver em execução, o arquivo usado como o back-end de disco da VM ainda existe, mas não pode ser vinculado novamente ao disco. O que pode ser feito facilmente é copiá-lo com um comando adequado, por exemplo:

cp --sparse=always /proc/PID/fd/12 > backup .

Como a VM está em execução, isso pode criar um resultado inconsistente: o sistema de arquivos (dentro do arquivo) pode mudar durante a cópia e pode se tornar inconsistente e corrompido. Portanto, congele a VM se o hypervisor permitir que ela e não feche o arquivo em disco da VM quando congelada, adicione uma nova referência ao arquivo sem nome e pare a VM. Se você não quiser ter nenhuma chance, adicione a referência antes de congelá-la. Qualquer comando lendo o arquivo e durando o tempo suficiente é bom. Por exemplo:

$ sleep 99999 < /proc/PID/fd/12 &
[1] 12087

Agora você deve verificar se /proc/12087/fd/0 está referenciando o mesmo arquivo ... (deleted) .

A VM agora pode ser congelada ou parada (mas não será possível iniciar novamente). Como não há mais atividade no sistema de arquivos, o backup deve ser consistente (com a recuperação do diário do sistema de arquivos, se simplesmente congelado). Usar cp com a opção --sparse=always parece ser uma boa opção se o arquivo de disco da VM for "preguiçoso" provisionado e principalmente vazio, para usar menos espaço.

    
por 16.02.2018 / 02:15