Executado acidentalmente sudo rm / * em um servidor remoto
Executei acidentalmente rm /*enquanto estava logado como root em um servidor Ubuntu remoto e apaguei praticamente todos os binários e atualmente não consigo efetuar login via ssh ou ftp para restaurar os arquivos (e espero o melhor).
Existe uma maneira de corrigir essa bagunça, ou devo ligar para o datacenter e solicitar um formato?
Você pode confirmar se este é um servidor físico ou virtual? Além disso, se você executou o -rargumento rmou realmente executou o comando que você mostra. O seu provedor de hospedagem oferece alguma maneira de acessar as imagens de disco fora dessa máquina específica?
rm /*deve excluir muito pouco. Não existe nenhum -rsinalizador que exclua recursivamente qualquer coisa, e sem ele os diretórios não serão excluídos (e mesmo se os diretórios foram excluídos, apenas os vazios podem ser excluídos). Esta resposta é baseada na suposição de que você não executou rm -rf /*.
Os únicos arquivos de conseqüência no sistema de arquivos raiz podem ser os links simbólicos para o kernel e o initrd (embora em um sistema Ubuntu que eu esteja vendo, eles não existam) ou um /lib64link simbólico em sistemas de 64 bits.
O problema pode ser apenas que o /lib64 -> /liblink simbólico foi excluído. Isso é bastante desagradável, pois quase todos os programas contam com esse link simbólico:
/lib64/ld-linux-x86-64.so.2 (0x00007f8946ab7000)
Esse ld-linuxé o carregador dinâmico e, se não estiver disponível, você não poderá executar nenhum executável dinâmico. Isso tornará extremamente difícil o login, e talvez você não consiga.
Um salvador pode ser busybox. Execute isto para verificar:
Nesse caso, o busybox deve ser executável, mas a questão é como você pode executá-lo?
Se você tiver acesso ao prompt do carregador de inicialização, poderá inicializar com init=/bin/static-sh, onde static-sh é um link simbólico busybox(verifique se /bin/static-shexiste - existe no meu sistema, mas não é o Ubuntu padrão. Este bug sugere que esteja disponível) .)
Depois de ter um shell raiz, você pode recriar o /lib64link simbólico. Pode ser necessário primeiro remontar o sistema de arquivos raiz como leitura / gravação. O busybox deve ter essas ferramentas integradas, que você pode executar da seguinte maneira:
# busybox ln -s /lib /lib64
Se o bash funcionar, o problema deve ser corrigido.
Se você precisar recuperar arquivos da instalação atual, peça ao seu host para ajudá-lo. Supondo que seja uma VM, são necessários cerca de cinco minutos do dia para criar uma imagem do seu disco, reinstalar o host do zero e despejar a imagem de disco antiga no seu novo sistema de arquivos.
Se você não precisar de nada, peça a reinstalação. Quase sempre a opção mais rápida quando você desossa as coisas com força.
Concordar. Se eles são um serviço de hospedagem de VM razoavelmente competente, devem conseguir fazer isso. Entre em contato com eles o mais rápido possível para garantir que eles ainda tenham um backup antes da instalação.
— Shadur 9/08/11
Se você acabou de excluir o link simbólico / lib64 para / lib e ainda tiver o console aberto, basta:
/lib/ld-linux-x86-64.so.2 /bin/ln -s /lib /lib64
e você poderá executar comandos normalmente novamente. Ajuste o caminho para sua biblioteca LD real. Você também pode executar qualquer outro comando que você quiser, apenas o precedendo com o caminho completo da biblioteca ld.
— Neuro Mancer
Sem ter acesso ao servidor físico, não há muito o que fazer.
Então, devo pedir um formato ou existe uma maneira de restaurar esses arquivos sem mexer em tudo?
Você esquece que existe uma alta probabilidade de que este seja um servidor virtual. Nesse caso, "servidor físico" não significa muito, exceto ter acesso a ferramentas remotas de nível superior.