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


Tenga en cuenta que: 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 se ha convertido en una pregunta falsa en algún tipo de esquema de marketing viral. Como no permitimos que ServerFault sea objeto de abuso de tal manera, la pregunta original se ha eliminado y las respuestas se combinaron 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 pulsar el botón de autodestrucción. Aquí hay un poco de lo que se quemó 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..

Paré la tarea y me sentí aliviado cuando descubrí que el servicio de producción aún estaba en ejecución. 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é un océano de alambre de púas para recuperar ese acceso SSH.

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


142
2018-04-07 06:39


origen


Restaurar desde copias de seguridad. Honestamente, este es uno de esos escenarios no fáciles de retroceder. - MadHatter
Como escribes --no-preserve-root ¡¿accidentalmente?! : -o - ThatGraemeGuy
Greame, las llaves son como una al lado de la otra. - MadHatter
Trabajo del martes: busque un nuevo trabajo;) Tómelo como una lección de por qué se necesitan copias de seguridad. - TomTom
Esto seguro que me parece un trolling. No puede escribir accidentalmente --i-really-mean-delete-my-whole-root. - psusi


Respuestas:


Inicie el sistema de rescate proporcionado por Hetzner y compruebe qué daño ha causado.
Transfiera los archivos a una ubicación segura y vuelva a desplegar el servidor después.

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


92
2018-04-07 07:00



Mira el lado bueno, al menos no tiene problemas con el corazón. - metacom


¿La verdad es? En este punto, no hay una solución automática simple / fácil para esto. La recuperación de datos es un 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. Probar un sistema, ver si funciona, y así sucesivamente. No hay una manera real de automatizar el proceso. pero probablemente puedas cuidadosamente hacerlo en lotes.

Dicho esto, hay algunas cosas muy alarmantes 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 comprobarlo primero. Ejecutar un comando en un cuadro. Luego unos pocos, luego más. Básicamente, si algo sale mal, es mejor que afecte a un pocos en lugar de todos sus sistemas.

En segundo lugar

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

Me asusta. Las copias de seguridad de nivel de archivo de una manera son problema resuelto. Rsync puede usarse para preservar permisos y copiar sobre archivos de una sola mano a un sitio de copia de seguridad. Accidentalmente algo? Reinstalar (preferiblemente automáticamente) rsync back, y las cosas funcionan. En el futuro, puede usar instantáneas de nivel de sistema de archivos con instantáneas de btrfs o zfs y enviarlas para copias de seguridad de nivel de sistema. En realidad, me gustaría separar los servidores de aplicaciones, las bases de datos y el almacenamiento, e introducir el principio de privilegio mínimo para que dividiera 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 pasado 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 lo que puede hacer, 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 ensuciaría.
  3. Nunca ejecute un comando en todas partes a la vez. Separa las máquinas de prueba y producción, y preferiblemente las máquinas de producción en etapas. Es mejor arreglar 1 o 10 máquinas en lugar de 100 o 1000.

  4. Doble y triple comprobación de comandos. No es vergonzoso pedirle a un compañero de trabajo que verifique dos veces "hey, estoy a punto de hacer una unidad de disco, ¿podría ver si la cordura lo comprueba para que no termine de limpiar una unidad?". Una envoltura también puede ayudar, pero nada le gana a un par de ojos menos cansados.

que puedes hacer ahora? Recibe un correo electrónico a los clientes. Hágales saber que hay tiempo de inactividad y fallas catastróficas. Hable con sus superiores, legales, de 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 contratar, en el mejor de los casos, manos adicionales. En el peor de los casos, planea gastar mucho dinero en la recuperación. En esta etapa, usted trabajará para mitigar la caída y las correcciones técnicas.


219
2018-04-11 08:02



@MarcoMarsala Si montó algo antes de usar rsync, no lo estaba haciendo correctamente. Deberías estar usando rsync sobre ssh. - Michael Hampton♦
Yo añadiría a esta excelente respuesta: Aléjate 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 sus sistemas aún más (como en el dd tema arriba) no lo va a empeorar. - Jenny D
¿Alguna idea de por qué se ejecutó el comando? Si $foo y $bar ambos estaban indefinidos, rm -rf / debería haber cometido un error con el --no-preserve-root mensaje. La única forma en que puedo pensar que esto hubiera funcionado en una máquina CentOS7 es si $bar evaluado para *, así que lo que se corrió fue rm -rf /*. - terdon
Me encanta el estilismo en "¿Accidentalmente algo?". Eso debe significar que la palabra "eliminado" fue "eliminado" o "eliminado" accidentalmente. - sehe
@MarcoMarsala bueno al menos eres famoso ahora independent.co.uk/life-style/gadgets-and-tech/news/… - Martin Smith


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

Como @faker 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 que:

  • Tomar copias de seguridad semanalmente, o al menos quincenalmente. Esto le ayudaría a obtener una copia de seguridad del servicio afectado con el mínimo MTTR posible.

  • No trabaje como root cuando no sea necesario. Y siempre Piénsalo dos veces antes de hacer nada. Te sugiero que también instales caja fuerte.

  • No escriba opciones que no pretende invocar, como --no-preserve-root o --permission-to-kill-kittens-explicitly-granted, para esa materia.


90
2018-04-07 07:57



Del mismo modo, a menos que REALMENTE LO SIENTA, no agregue el --please-destroy-my-drive parámetro a hdparm. - MikeyB
Me gustaría añadir; "Revise tres veces sus argumentos (y opciones) cuando trabaje como root", "Revise su CurrentWorkingDirectory (antes de hacer algo como rm -rf *)", y "Use rutas completas a los comandos (no transmita a $ PATH). - Baard Kopperud


He tenido el mismo problema pero solo probando con un disco duro, perdí 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ó.


47
2018-04-11 08:17



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


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 estos comandos en un script de shell con rutinas de validación / sanidad realmente buenas para protegerte de hacer algo estúpido es diferente).

Simplemente 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 inclinada:

cd / mnt

sudo rm -rf hetznerbackup


33
2018-04-07 21:22



Siempre pongo la -rf al final de la lista de argumentos, por lo que rm /bla/foo/bar -rf. Al menos de esa manera no tengo muchos problemas cuando presiono accidentalmente regresar después de escribir el rm / parte. - Jens Timmerman
Del mismo modo, al eliminar los archivos "* ~", primero escribo la tilde y luego agrego el asterisco. - tekknolagi
¿Así que prefieres eliminar tu casa antes que todo en el directorio actual? - greg0ire
@greg0ire No, creo que quería decir, que dentro de /mnt/hetznerbackup, tuvo que usar "/" para marcar todo lo que estaba dentro de esa carpeta ... pero solo de los padres hetznerbackup Es suficiente, sin barras. - T.Todua
@tazotodua: me refería al comentario de tekknolagi - greg0ire


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

  • 1er paso: realice una copia de seguridad de las unidades "copia de seguridad" borradas con dd comandante
  • 2do paso - Uso testdisk para recuperar archivos.

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

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


16
2018-04-11 00:32



Bastante puso a cero tu disco haciendo eso. Eso en serio hace que sea mucho más difícil recuperarse. Hay una buena razón por la que el OP sugirió que intentó usar testdisk y recuperarse primero, y aunque la sintaxis de dd puede ser un poco extraña, esa es una buena razón para realizar una doble y triple comprobación antes de ejecutar el comando. Solo borraste un servidor, ¿verdad? - Journeyman Geek
Aún puedes recuperarte, depende de cuanto tiempo lo hayas permitido. dd para borrar tu ultima oportunidad - Abc Xyz
Lamento decir eso, pero me siento enorme troll en esta pregunta ... - tymik
Espero que te sientas pequeño troll en la respuesta :) - Abc Xyz
Sinceramente. No estoy seguro de que seas real. Si es así, probablemente estás en el trabajo equivocado ... - leftcase


Como se mencionó 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 brindarle pantalla y teclado en su servidor vs.

Si desea recuperar todo lo posible, reinicie el servidor en el sistema netboot y luego inicie sesión y descargue una imagen del sistema de archivos leyendo desde el inodo del dispositivo apropiado.

Creo que algo como esto debería funcionar:

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

Por supuesto, el shell realiza la redirección antes de invocar el comando ssh, por lo que server.img es un archivo local. Si desea solo el sistema de archivos raíz y no el disco completo, reemplace sda por sda3 asumiendo que estás usando la misma imagen que yo.


7
2018-04-07 07:54



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á en el lado receptor. Supongo que el resultado que pretendía lograr era comprimir los datos mientras se transferían. La imagen local se puede almacenar comprimida o no, pero las herramientas que le gustaría aplicar a esa imagen más adelante 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 hacer uso de la función de compresión en ssh. Se puede habilitar con -C Si aún no está habilitado en su configuración. - kasperd
Estaba más tratando de reducir el tamaño del archivo. Pero si desea ahorrar ancho de banda (buena idea): simplemente agregue citas: ssh root@host "cat /dev/sda | gzip -c - " > /path/to/dir_on_huge_partition/server.img.gz (La opción -c de ssh también suele ser buena, pero aún necesitarás comprimir al final, ya que ssh solo se comprimirá en la entrada de su túnel y se descomprimirá antes de enviarla a la salida estándar) - Olivier Dulac


¿Cómo avanzarías desde aquí?

Juraría usando rm por el resto de mi vida y creo 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 nuevo sistema y alias rm a algo que le dice a la gente que use trash-cli en lugar. También incluiría una nota sobre otro alias que realmente se ejecuta /bin/rm pero les dice que eviten usarlo en la mayoría de los casos.

:( Historia verdadera


2
2018-04-15 09:51



En mi experiencia, este tipo de herramientas son más una molestia que una ayuda real, tarde o temprano y, después de jurar, lo eliminarás. Puede que esté bien para una estación de trabajo, pero en muchas, si no en la mayoría de las situaciones, cuando realiza un 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, el traslado automático de datos a una carpeta de basura puede llevar a problemas graves 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 con los artículos que han estado en la basura por más de 30 días. En un servidor es posible que desee algo más corto, por ejemplo. trash-empty 5 en un cron. El punto es permitirte 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 (observe el alias / bin / rm). Su pregunta también sugiere una elección falsa entre la recuperación de desastres y una opción de eliminación amigable para el ser humano. Deberías tener ambos. - Gerry
Un proceso de eliminación de dos pasos puede ahorrar muchos problemas: 1. pasar a la papelera (verbalmente), 2. vaciar la papelera. Alias ​​un script como "rm" y me ha salvado de eliminar accidentalmente cosas importantes muchas veces. - Sam Watkins


Yo aconsejaría en tal caso desmontar y usar. debugfs, y con ayuda de lsdel puede enumerar todos los archivos eliminados recientemente, que no se limpiaron de revistas y luego tugurio 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 guión, lo que movió ream rm a real.rm y symlinc mv a rm ;)


1
2018-04-18 14:46