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

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.

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.

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

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.

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

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

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.

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.

¿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

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 ;)

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.