Error de lunes por la mañana: sudo rm -rf --no-preserve-root /

146

Tenga en cuenta: las respuestas y los comentarios a esta pregunta contienen contenido de otra pregunta similar que ha recibido mucha atención de medios externos pero que resultó ser una pregunta falsa en algún tipo de esquema de marketing viral. Como no permitimos que se abuse de ServerFault de esa manera, la pregunta original se ha eliminado y las respuestas se fusionaron con esta pregunta.

Aquí hay una tragedia entretenida. Esta mañana estaba haciendo un poco de mantenimiento en mi servidor de producción, cuando ejecuté por error el siguiente comando:

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

No vi el último espacio antes /y unos segundos después, cuando las advertencias inundaban mi línea de comando, me di cuenta de que acababa de presionar el botón de autodestrucción. Aquí hay un poco de lo que ardió en mis ojos:

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..

Detuve la tarea y me sentí aliviado cuando descubrí que el servicio de producción todavía se estaba ejecutando. Lamentablemente, el servidor ya no acepta mi clave pública o contraseña para ningún usuario a través de SSH.

¿Cómo avanzarías desde aquí? Nadaré en un océano de alambre de púas para recuperar ese acceso SSH.

El servidor ejecuta Ubuntu-12.04 y está alojado en Hetzner.

ubuntu-12.04 disaster-recovery hetzner Jonas Nielsen
fuente
48
Restaurar desde copias de seguridad. Honestamente, este es uno de esos escenarios no fáciles de retroceder.
MadHatter
310
¿Cómo --no-preserve-rootescribes accidentalmente? : -o
ThatGraemeGuy
144
Greame, las teclas son como una al lado de la otra.
MadHatter
38
Martes de trabajo: busque un nuevo trabajo;) Tómelo como una lección por qué se necesitan copias de seguridad.
TomTom
43
Esto seguramente me parece trolling. No puede escribir accidentalmente --i-really-mean-delete-my-whole-root.
psusi

Respuestas:

95

Inicie el sistema de rescate provisto por Hetzner y verifique qué daño ha hecho.
Transfiera los archivos a una ubicación segura y luego vuelva a implementar el servidor.

Me temo que esa es la mejor solución en su caso.

falsificador
fuente
102
mira el lado bueno, al menos no tiene problemas con el heartbleed!
metacom
222

¿La verdad es? En este punto, no hay una solución automática simple / fácil para esto. La recuperación de datos es una ciencia e incluso las herramientas básicas y comunes necesitan que alguien se siente y se asegure de que los datos estén allí. Si espera recuperarse de esto sin grandes cantidades de tiempo de inactividad, se sentirá decepcionado.

Sugeriría usar testdisk o alguna herramienta de recuperación específica del sistema de archivos. Pruebe un sistema, vea si funciona, y así sucesivamente. No hay una forma real de automatizar el proceso, pero probablemente pueda hacerlo cuidadosamente en lotes.

Dicho esto, hay algunas cosas muy aterradoras en las preguntas y comentarios que deberían formar parte de sus informes posteriores a la acción.

En primer lugar, ejecutó el comando en todas partes sin verificarlo primero. Ejecute un comando en un cuadro. Luego unos pocos, luego más. Básicamente, si algo sale mal, es mejor que afecte a algunos en lugar de a todos sus sistemas.

En segundo lugar

@ ¿Cómo hacer una copia de seguridad sin montar una unidad remota en el servidor?

Me asusta. Las copias de seguridad unidireccionales a nivel de archivo son un problema resuelto . Rsync puede usarse para preservar permisos y copiar archivos de una manera a un sitio de respaldo. Accidentalmente algo? Vuelva a instalar (preferiblemente automáticamente) rsync y las cosas funcionarán. En el futuro, puede usar instantáneas a nivel del sistema de archivos con instantáneas btrfs o zfs y enviarlas para copias de seguridad a nivel del sistema. De hecho, jugaría con la separación de servidores de aplicaciones, bases de datos y almacenamiento e introduciría el principio de privilegio mínimo para que pueda dividir el riesgo de algo como esto ...

Sé que hay algo que puedo hacer. Ahora necesito pensar cómo protegerme

Después de que algo ha sucedido, es el peor momento para considerar esto.

¿Qué podemos aprender de esto?

  1. Las copias de seguridad guardan datos. Posiblemente carreras.
  2. Si tiene una herramienta y no sabe si puede hacer algo, es peligroso. Un jedi puede hacer cosas increíbles con un sable de luz. Una habitación llena de chimpancés con sables de luz ... se volvería desordenada.

  3. Nunca ejecute un comando en todas partes a la vez. Separe las máquinas de prueba y producción, y preferiblemente haga las máquinas de producción en etapas. Es mejor arreglar 1 o 10 máquinas en lugar de 100 o 1000.

  4. Comandos de verificación doble y triple. No hay vergüenza en pedirle a un compañero de trabajo que verifique dos veces "oye, estoy a punto de hacer un disco, ¿podrías revisar esto para que no termine limpiando un disco?". Un envoltorio podría ayudar también, pero nada supera a un conjunto de ojos menos cansados.

que puedes hacer ahora? Enviar un correo electrónico a los clientes. Hágales saber que hay tiempo de inactividad y fallas catastróficas. Hable con sus superiores, legales, ventas y demás, y vea cómo puede mitigar el daño. Comience a planificar la recuperación y, si es necesario, tendrá que, en el mejor de los casos, contratar manos adicionales. En el peor de los casos, planifique gastar mucho dinero en recuperación. En esta etapa, trabajará para mitigar las fallas y las soluciones técnicas.

Journeyman Geek
fuente
99
@MarcoMarsala Si montó algo antes de usar rsync, no lo estaba haciendo correctamente. Debería usar rsync sobre ssh.
Michael Hampton
67
Añadiría a esta excelente respuesta: aléjese de la computadora. No intentes arreglar nada hasta que te hayas calmado. Ya estás viendo un tiempo de inactividad serio; tomarse el tiempo para pensar las cosas en lugar de destruir aún más sus sistemas (como en el ddtema anterior) no va a empeorar las cosas.
Jenny D
22
¿Alguna idea de por qué el comando realmente se ejecutó? Si $fooy $bareran tanto indefinido, rm -rf /debería haber muchos errores con el --no-preserve-rootmensaje. La única forma en que puedo pensar que esto realmente habría funcionado en una máquina CentOS7 es si se $barevalúa *, así que lo que se ejecutó fue rm -rf /*.
terdon
99
Me encanta el estilismo en "¿Accidentalmente algo?". Eso debe significar que la palabra "eliminado" fue "eliminada" o "eliminada" accidentalmente.
sehe
20
@MarcoMarsala bueno, al menos eres famoso ahora independent.co.uk/life-style/gadgets-and-tech/news/…
Martin Smith
92

Cuando eliminas cosas con rm -rf --no-preserve-root, es casi imposible de recuperar. Es muy probable que haya perdido todos los archivos importantes.

Como @faker dijo en su respuesta, el mejor curso de acción es transferir los archivos a una ubicación segura y luego volver a implementar el servidor.

Para evitar situaciones similares en el futuro, te sugiero:

  • Realice copias de seguridad semanalmente, o al menos cada quince días. Esto lo ayudaría a recuperar el servicio afectado con el menor MTTR posible.

  • No trabaje como root cuando no sea necesario . Y siempre piensa dos veces antes de hacer algo. Te sugiero que también instales safe-rm .

  • No escriba opciones que no quiera invocar , como --no-preserve-rooto --permission-to-kill-kittens-explicitly-granted, para el caso.

Amal Murali
fuente
18
Del mismo modo, a menos que REALMENTE LO SIGNIFICA, no agregue el --please-destroy-my-driveparámetro a hdparm.
MikeyB
3
Me gustaría agregar; "Verifique tres veces sus argumentos (y opciones) cuando trabaje como root", "Verifique su CurrentWorkingDirectory (antes de hacer algo como rm -rf *)" y "Use rutas completas a los comandos (no retransmitir en $ PATH).
Baard Kopperud
47

He tenido el mismo problema pero solo probando con un disco duro, he perdido todo. No sé si será útil, pero no instales nada , no sobrescribas tus datos , necesitas montar tus discos duros y lanzar algunas herramientas forenses como autopsia, photorec, Testdisk.

Recomiendo encarecidamente Testdisk, con algunos comandos básicos puede recuperar sus datos si no los sobrescribió.

Octo
fuente
8
Definitivamente recomendaría takign el almacenamiento fuera de línea si es posible y volver a montar como 'solo lectura' si es posible. Ya sea con un disco vivo u otra instancia de servidor.
mhouston100
2
Incluso consideraría hacer una copia dd bitcopy del disco original en un disco nuevo desde un montaje de solo lectura del disco original solo para estar seguro.
Jim
3
«Estas herramientas no recuperarán el nombre y la ruta del archivo» Sí, lo hacen. De las 3 herramientas mencionadas, solo una (Photorec) realiza el tallado.
Andrea Lazzarotto
34

La mejor manera de solucionar un problema como este es no tenerlo en primer lugar.

No ingrese manualmente un comando "rm -rf" que tenga una barra diagonal en la lista de argumentos. (Poner dichos comandos en un script de shell con muy buenas rutinas de validación / cordura para protegerlo de hacer algo estúpido es diferente).

Solo no lo hagas.
Siempre. Si crees que necesitas hacerlo, no estás pensando lo suficiente.

En su lugar, cambie su directorio de trabajo al padre del directorio desde el que desea iniciar la eliminación, de modo que el objetivo del comando rm no requiera una barra diagonal:

cd / mnt

sudo rm -rf hetznerbackup

Monty Harder
fuente
31
Siempre pongo -rf al final de la lista de argumentos, entonces rm /bla/foo/bar -rf. Al menos de esa manera no estoy en muchos problemas cuando presiono acentuadamente regresar después de escribir la rm /parte.
Jens Timmerman
55
Del mismo modo, al eliminar archivos "* ~", escribo la tilde primero, luego agrego el asterisco.
tekknolagi
44
¿Prefieres eliminar tu página de inicio que todo en el directorio actual?
greg0ire
@ greg0ire No, creo que quería decir que dentro /mnt/hetznerbackup, tenía que usar "/" para marcar todo dentro de esa carpeta ... pero desde el padre, solo hetznerbackupes suficiente, sin barras.
T.Todua
1
@tazotodua: Me refería al comentario de
tekknolagi
16

Intentaría recuperar la máquina de respaldo, donde se almacenaron todas las copias:

  • 1er paso: realice una copia de seguridad de estas unidades de "máquina de copia de seguridad" borradas con ddcomand.
  • Segundo paso: se usa testdiskpara recuperar archivos.

Entonces, digamos que desea recuperar 1 TB, necesitará 2 TB adicionales, 1 TB para la copia de seguridad (primer paso) más 1 TB para la recuperación (segundo paso).

Cometí un error similar con el alias rm -fr [sonó el teléfono] y el CD al directorio precioso. Ahora siempre lo pienso dos veces y vuelvo a verificar un par de veces antes de usar el comando rm o dd.

Abc Xyz
fuente
66
Bastante a cero su disco al hacer eso. Eso en serio hace que sea mucho más difícil recuperarse. Hay una buena razón por la cual el OP sugirió que intentaste usar testdisk y recuperarte primero, y aunque la sintaxis de dd puede ser un poco extraña, esa es una buena razón para hacer una verificación doble y triple antes de ejecutar el comando. Solo borraste un servidor, ¿verdad?
Journeyman Geek
1
Todavía puede recuperarse, depende de cuánto tiempo permitió ddborrar su última oportunidad.
Abc Xyz
129129
lamento decir eso, pero me siento un gran troll en esta pregunta ...
tymik
3
espero que te sientas pequeño troll en la respuesta :)
Abc Xyz
55
Sinceramente. No estoy seguro de que seas real. Si es así, probablemente esté en el trabajo equivocado ...
leftcase
7

Como se menciona en otra respuesta, Hetzner tiene un sistema de rescate. Incluye tanto una opción de arranque de red con acceso ssh como un applet de java para darle pantalla y teclado en su servidor virtual.

Si desea recuperar la mayor cantidad posible, reinicie el servidor en el sistema de arranque de red y luego inicie sesión y descargue una imagen del sistema de archivos leyendo el inodo del dispositivo apropiado.

Creo que algo como esto debería funcionar:

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

Por supuesto, la redirección la realiza el shell antes de que se invoque el comando ssh, por lo que server.img es un archivo local. Si desea que sólo el sistema de archivos raíz y no el disco completo, reemplace sdapor sda3suponiendo que está utilizando la misma imagen que yo.

kasperd
fuente
tal vez podría ser: ssh root@host cat /dev/sda | gzip -c - > /path/to/dir_on_huge_partition/server.img.gz(el gzip sobre la marcha ayudará o no según el contenido del sistema de archivos ...)
Olivier Dulac
@OlivierDulac Usar gzip de esa manera enviaría los datos sin comprimir a través de la red y luego los comprimiría en el lado receptor. Supongo que el resultado que pretendía lograr era comprimir los datos mientras se transfieren. La imagen local podría almacenarse comprimida o no, pero las herramientas que le gustaría aplicar a esa imagen más tarde no funcionarán con la versión comprimida. Si todo lo que quiere lograr es la compresión de datos mientras está en tránsito, puede utilizar la función de compresión en ssh. Se puede habilitar con -Csi aún no está habilitado en su configuración.
kasperd
2
Intenté más reducir el tamaño del archivo. Pero si desea ahorrar ancho de banda (buena idea): solo agregue comillas: ssh root@host "cat /dev/sda | gzip -c - " > /path/to/dir_on_huge_partition/server.img.gz(la opción -c de ssh generalmente también es buena, pero aún necesitaría comprimir al final, ya que ssh solo se comprimirá en la entrada de su túnel y descomprimir antes de enviar a stdout)
Olivier Dulac
2

¿Cómo avanzarías desde aquí?

Dejaría de usarlo rmpor el resto de mi vida y pensaría que es una locura que trash-cli no sea el comando de eliminación predeterminado en los sistemas nix.

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

Me aseguraría de que sea lo primero que instale en un sistema completamente nuevo y alias rmalgo que le indique a la gente que use trash-clien su lugar. También incluiría una nota sobre otro alias que realmente se ejecuta /bin/rmpero les dice que eviten usarlo en la mayoría de los casos.

:( Historia verdadera

Gerry
fuente
2
En mi experiencia, este tipo de herramientas son más una molestia que una ayuda real, tarde o temprano, y después de algunas palabrotas, la eliminarás. Puede estar bien para una estación de trabajo, pero en muchas, si no en la mayoría de las situaciones, cuando está haciendo trabajo administrativo en un servidor, realmente necesita eliminar los datos, no solo moverlos a otro lugar (y si ese fuera el caso, simplemente use mv en lugar). Además, mover datos automáticamente a una carpeta de basura puede provocar problemas serios por sí mismo (por ejemplo, la basura no está en el mismo sistema de archivos, seguridad).
maetthu
@maetthu Oh, por supuesto, las cosas se eliminan después de haber estado en la basura durante un cierto número de días. El escritorio de Ubuntu hace esto a los elementos que han estado en la basura más de 30 días. En un servidor es posible que desee algo más corto, por ejemplo. trash-empty 5en un cron. El punto es permitirle un período de gracia porque los humanos cometen errores.
Gerry
¿No es mejor tener un plan de recuperación de desastres en funcionamiento en lugar de prohibir las herramientas esenciales del sistema?
user292812
@ user292812 No sugerí prohibir / bin / rm, solo que no debería ser la primera opción en la mayoría de los casos (tenga en cuenta el alias / bin / rm). Su pregunta también sugiere una elección falsa entre la recuperación ante desastres y una opción de eliminación amigable para los humanos. Deberías tener ambos.
Gerry
1
Un proceso de eliminación de dos pasos puede ahorrarle muchos problemas: 1. muévase a la basura (de forma detallada), 2. bote la basura. Alias ​​tal script para "rm" y me ha salvado de borrar accidentalmente cosas importantes muchas veces.
Sam Watkins
1

Aconsejaría en tal caso que desmonte y use debugfs , y con la ayuda de lsdel puede enumerar todos los archivos eliminados recientemente, que no se limpiaron de las revistas y luego volcar los archivos necesarios. Enlace de búsqueda rápida para el mismo: http://www.linuxvoodoo.com/resources/howtos/debugfs

Espero que ayude a alguien. ;)

Y sí, una de las sugerencias es hacer un script, que movió ream rm a real.rm y symlinc mv a rm ;)

BiG_NoBoDy
fuente
-2

Detenga todos los procesos del servidor y todo lo que pueda causar E / S de disco ... luego ejecute testdisk, debe estar en su pila de software. Si tiene acceso físico, use un livecd con testdisk.

San crujiente
fuente
1
No entiendo por qué crees que tres respuestas que proporcionan exactamente la misma sugerencia no fueron suficientes.
kasperd