Início / server / Perguntas / 587102
Accepted
Jonas Bylov
Asked: 2014-04-07 22:39:14 +0800 CST

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

  • 772

Observação: as respostas e 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 falsa 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 mescladas com esta 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 erroneamente o seguinte comando:

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

Eu não localizei o último espaço antes /e alguns segundos depois, quando os avisos estavam inundando minha linha de comando, percebi que tinha acabado de apertar o botão de autodestruição. Aqui está um pouco do que ardeu em 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..

Interrompi 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 para nenhum usuário via SSH.

Como você avançaria a partir daqui? Vou nadar um oceano de arame farpado para recuperar o acesso SSH.

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

disaster-recovery hetzner ubuntu-12.04

9 respostas

  1. 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 até 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. Experimente um sistema, veja se funciona e assim por diante. Não há uma maneira real de automatizar o processo, mas você provavelmente pode fazê-lo cuidadosamente em lotes.

    Dito isto, há algumas coisas muito assustadoras nas perguntas e comentários que deveriam fazer parte de seus relatórios pós-ação.

    Em primeiro lugar, você executou o comando em todos os lugares sem verificá-lo primeiro. Execute um comando em uma caixa. Depois alguns, depois mais. Basicamente, se algo der errado, é melhor que isso afete alguns em vez de todos os seus sistemas.

    Em segundo lugar

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

    Me assusta. Os backups unidirecionais de nível de arquivo são um problema resolvido . O Rsync pode ser usado para preservar permissões e copiar arquivos de uma maneira para um site de backup. Acidentalmente alguma coisa? Reinstale (de preferência automaticamente) o rsync back e as coisas funcionam. No futuro, você pode 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 brincaria com a separação de servidores de aplicativos, bancos de dados e armazenamento e introduziria o princípio de privilégio mínimo 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 o que ela 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 uma bagunça.

    3. Nunca execute um comando em todos os lugares ao mesmo tempo. Separe as máquinas de teste e de 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 de trabalho para verificar novamente "ei, estou prestes a dd uma unidade, você poderia verificar isso para que eu não acabe limpando uma unidade?". Uma embalagem também pode ajudar, mas nada supera um par de olhos menos cansados.

    o que você pode fazer agora? Receba um e-mail para os clientes. Deixe-os saber que há tempo de inatividade e falhas catastróficas. Converse com seus superiores, jurídicos, vendas e afins e veja como você pode mitigar os danos. Comece a planejar a recuperação e, se necessário, você terá que, na melhor das hipóteses, contratar mãos extras. Na pior das hipóteses, planeje gastar muito dinheiro na recuperação. Nesta fase, você trabalhará para mitigar a queda, bem como correções técnicas.

    • 224
  2. Best Answer

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

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

    • 97

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

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

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

    • Faça backups semanalmente, ou pelo menos quinzenalmente. Isso o ajudaria a recuperar o serviço afetado com o mínimo de 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 safe-rm .

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

    • 93

  4. 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 sobrescreva seus dados , você precisa montar seus discos rígidos e lançar algumas ferramentas forenses, como autopsy, photorec, Testdisk.

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

    • 48

  5. 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 script de shell com rotinas de validação/sanidade realmente boas para protegê-lo de fazer algo estúpido é diferente.)

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

    Em vez disso, altere seu diretório de trabalho para o pai do diretório 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

    • 34

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

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

    Então, digamos que você deseja recuperar 1 TB, você precisará de 2 TB extras, 1 TB para backup (1ª etapa) mais 1 TB para recuperação (2ª etapa).

    Eu cometi um erro semelhante com o alias rm -fr [telefone tocou] e cd para o diretório precioso. Agora eu sempre penso duas vezes e volto a verificar algumas vezes antes de usar o comando rm ou dd.

    • 15

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

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

    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 invocado, então server.img é um arquivo local. Se você deseja apenas o sistema de arquivos raiz e não o disco completo, substitua sdaassumindo sda3que está usando a mesma imagem que eu.

    • 7

  8. Como você avançaria a partir daqui?

    Eu juraria não usar rmpelo resto da minha vida e pensaria que é uma loucura que trash-cli não seja o comando de remoção padrão em sistemas nix.

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

    Eu me certificaria de que é a primeira coisa que eu instalo em um novo sistema e alias rmalgo que diga às pessoas para usarem trash-cli. Também incluiria uma nota sobre outro alias que realmente é executado, /bin/rmmas informa a eles para evitar usá-lo na maioria dos casos.

    :( História verdadeira

    • 3

  9. Eu aconselharia, nesse caso, desmontar e usar debugfs e, com a ajuda de lsdel , você pode listar todos os arquivos removidos recentemente, que não foram limpos dos diários e, em seguida, despejar 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 script, que moveu ream rm para real.rm e symlinc mv para rm ;)

    • 2

relate perguntas