Erro de segunda-feira de manhã: sudo rm -rf --no-preserve-root /

Observação: as respostas e os comentários a esta pergunta contêm conteúdo de outra pergunta semelhante que recebeu muita atenção da mídia externa, mas acabou sendo uma pergunta fraudulenta em algum tipo de esquema de marketing viral. Como não permitimos que o ServerFault seja abusado dessa maneira, a pergunta original foi excluída e as respostas foram mescladas com essa pergunta.

Aqui está uma tragédia divertida. Esta manhã eu estava fazendo um pouco de manutenção no meu servidor de produção, quando executei por engano o seguinte comando:

sudo rm -rf --no-preserve-root /mnt/hetznerbackup /

Não localizei o último espaço antes /e alguns segundos depois, quando os avisos inundavam minha linha de comando, percebi que havia acabado de apertar o botão de autodestruição. Aqui está um pouco do que queimou nos meus olhos:

rm: cannot remove `/mnt/hetznerbackup': Is a directory
rm: cannot remove `/sys/fs/ecryptfs/version': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/inode_readahead_blks': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/mb_max_to_scan': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/delayed_allocation_blocks': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/max_writeback_mb_bump': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/mb_stream_req': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/mb_min_to_scan': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/mb_stats': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/trigger_fs_error': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/session_write_kbytes': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/lifetime_write_kbytes': Operation not permitted
# and so on..

Parei a tarefa e fiquei aliviado quando descobri que o serviço de produção ainda estava em execução. Infelizmente, o servidor não aceita mais minha chave pública ou senha de qualquer usuário via SSH.

Como você avançaria daqui? Nado em um oceano de arame farpado para recuperar o acesso SSH.

O servidor está executando o Ubuntu-12.04 e hospedado no Hetzner.

Inicialize no sistema de resgate fornecido pela Hetzner e verifique o dano que você causou.
Transfira os arquivos para um local seguro e reimplemente o servidor posteriormente.

Receio que seja a melhor solução no seu caso.

Fato é? Neste ponto, não há uma correção automática simples / fácil para isso. A recuperação de dados é uma ciência e mesmo as ferramentas básicas e comuns precisam de alguém para se sentar e garantir que os dados estejam lá. Se você espera se recuperar disso sem grandes quantidades de tempo de inatividade, ficará desapontado.

Eu sugiro usar testdisk ou alguma ferramenta de recuperação específica do sistema de arquivos. Tente um sistema, veja se funciona e assim por diante. Não existe uma maneira real de automatizar o processo, mas você provavelmente pode fazê-lo com cuidado em lotes.

Dito isto, há algumas coisas muito assustadoras nas perguntas e comentários que devem fazer parte dos seus relatórios após a ação.

Primeiro, você executou o comando em qualquer lugar sem verificar primeiro. Execute um comando em uma caixa. Depois alguns, depois mais. Basicamente, se algo der errado, é melhor que isso afete alguns e não todos os seus sistemas.

Em segundo lugar

@ Tim como fazer um backup sem montar uma unidade remota no servidor?

Me assusta. Os backups unidirecionais em nível de arquivo são um problema resolvido . O Rsync pode ser usado para preservar permissões e copiar arquivos em um caminho para um site de backup. Acidentalmente alguma coisa? Reinstale (de preferência automaticamente) o rsync de volta, e tudo funcionará. No futuro, você poderá usar instantâneos no nível do sistema de arquivos com instantâneos btrfs ou zfs e enviá-los para backups no nível do sistema. Na verdade, eu brincava com a separação de servidores de aplicativos, bancos de dados e armazenamento e introduzia o princípio do menor privilégio para que você dividisse o risco de algo assim.

Eu sei que há qualquer coisa que eu possa fazer. Agora preciso pensar em como me proteger

Depois que algo aconteceu, é o pior momento para considerar isso.

O que podemos aprender com isso?

1. Os backups salvam dados. Possivelmente carreiras.
2. Se você tem uma ferramenta e não sabe se o que pode fazer, é perigoso. Um jedi pode fazer coisas incríveis com um sabre de luz. Uma sala cheia de chimpanzés com sabres de luz ... ficaria bagunçada.

3. Nunca execute um comando em todos os lugares ao mesmo tempo. Separe as máquinas de teste e produção e, de preferência, faça as máquinas de produção em etapas. É melhor consertar 1 ou 10 máquinas em vez de 100 ou 1000.

4. Comandos de verificação dupla e tripla. Não há vergonha em pedir a um colega para checar "ei, eu estou prestes a fazer uma unidade, você poderia verificar isso com prudência para não acabar limpando uma unidade?". Um invólucro pode ajudar também, mas nada supera um conjunto de olhos menos cansado.

o que você pode fazer agora? Receba um email para os clientes. Deixe que eles saibam que há tempo de inatividade e falhas catastróficas. Converse com seus superiores, legais, vendas e outros e veja como você pode mitigar os danos. Comece a planejar a recuperação e, se necessário, precisará contratar, na melhor das hipóteses, mãos extras. Na pior das hipóteses, planeje gastar muito dinheiro em recuperação. Nesta fase, você trabalhará para atenuar a queda e as correções técnicas.

Quando você exclui itens com rm -rf --no-preserve-root, é quase impossível recuperar. É muito provável que você tenha perdido todos os arquivos importantes.

Como o @faker disse em sua resposta, o melhor curso de ação é transferir os arquivos para um local seguro e reimplementar o servidor posteriormente.

Para evitar situações semelhantes no futuro, sugiro que você:

• Faça backups semanalmente ou pelo menos quinzenalmente. Isso ajudaria você a recuperar o serviço afetado com o menor MTTR possível.

• Não trabalhe como root quando não for necessário . E sempre pense duas vezes antes de fazer qualquer coisa. Eu sugiro que você também instale o safe-rm .

• Não digite as opções que não pretende chamar , como --no-preserve-rootou --permission-to-kill-kittens-explicitly-granted, nesse caso.

Eu tive o mesmo problema, mas apenas testando com um disco rígido, perdi tudo. Não sei se será útil, mas não instale nada , não substitua seus dados , você precisa montar seus discos rígidos e lançar algumas ferramentas forenses, como autópsia, photorec, Testdisk.

Eu recomendo fortemente o Testdisk, com alguns comandos básicos, você pode recuperar seus dados se não os substituir.

A melhor maneira de corrigir um problema como esse é não tê-lo em primeiro lugar.

Não insira manualmente um comando "rm -rf" que tenha uma barra na lista de argumentos. (Colocar esses comandos em um shell script com boas rotinas de validação / sanidade para protegê-lo de fazer algo estúpido é diferente.)

Apenas não faça isso.
Sempre. Se você acha que precisa fazer isso, não está pensando o suficiente.

Em vez disso, altere seu diretório de trabalho para o pai do diretório a partir do qual você pretende iniciar a remoção, para que o destino do comando rm não exija uma barra:

cd / mnt

sudo rm -rf hetznerbackup

Eu tentaria recuperar a máquina de backup, onde todas as cópias foram armazenadas:

• 1º passo - Faça um backup dessas unidades de "máquina de backup" apagadas com ddcomando.
• 2º passo - Use testdiskpara recuperar arquivos.

Digamos que você queira recuperar 1 TB, você precisará de 2 TB extras, 1 TB para backup (1º passo) e 1 TB para recuperação (2º passo).

Cometi um erro semelhante com o apelido rm -fr [telefone tocou] e cd no diretório precioso. Agora eu sempre penso duas vezes e verifique novamente algumas vezes antes de usar o comando rm ou dd.

Como mencionado em outra resposta, Hetzner possui um sistema de resgate. Inclui uma opção netboot com acesso ssh, bem como um applet java para fornecer a tela e o teclado no seu vserver.

Se você deseja recuperar o máximo possível, reinicie o servidor no sistema netboot e, em seguida, efetue login e faça o download de uma imagem do sistema de arquivos lendo o inode apropriado do dispositivo.

Eu acho que algo assim deve funcionar:

ssh root@host cat /dev/sda > server.img

É claro que o redirecionamento é feito pelo shell antes que o comando ssh seja chamado, portanto server.img é um arquivo local. Se você quiser apenas o sistema de arquivos raiz e não o disco cheio, substitua sdapor sda3supondo que você está usando a mesma imagem que eu.

Como você avançaria daqui?

Eu juraria usar rmo resto da minha vida e pensaria que é loucura que o lixo-cli não seja o comando de remoção padrão nos sistemas nix.

https://github.com/andreafrancia/trash-cli

Eu me certificaria de que é a primeira coisa que instalo em um sistema totalmente novo e alias rmalgo que diz às pessoas para usar trash-cli. Também incluiria uma observação sobre outro alias que realmente é executado, /bin/rmmas diz a eles para evitar usá-lo na maioria dos casos.

:( História real

Eu aconselho, nesse caso, é desmontar e usar debugfs , e com a ajuda do lsdel você pode listar todos os arquivos removidos recentemente, que não foram limpos dos diários e depois despejaram os arquivos necessários. Link de pesquisa rápida para o mesmo: http://www.linuxvoodoo.com/resources/howtos/debugfs

espero que ajude alguém. ;)

E sim, uma das sugestões é fazer o script, que moveu ream rm para real.rm e symlinc mv para rm ;)

Interrompa todo o processo do servidor e tudo o que possa causar a E / S do disco ... e execute o testdisk, ele deve estar na sua pilha de software. Se você tiver acesso físico, use um livecd com testdisk.