A veces las personas eliminan archivos que no deberían, un proceso de larga duración todavía tiene el archivo abierto y recuperar los datos mediante catting /proc/<pid>/fd/Nno es lo suficientemente increíble. Lo suficientemente impresionante sería si pudiera "deshacer" la eliminación ejecutando alguna opción mágica en ln que le permitiría volver a vincularse al número de inodo (recuperado a través de lsof).
No puedo encontrar ninguna herramienta de Linux para hacer esto, al menos con una búsqueda superficial en Google.
¿Qué tienes, error del servidor?
EDITAR 1: La razón por la que extraer el archivo /proc/<pid>/fd/Nno es lo suficientemente sorprendente es porque el proceso que todavía tiene el archivo abierto todavía está escribiendo en él. Una eliminación elimina la referencia al inodo del espacio de nombres del sistema de archivos. Lo que quiero es una forma de recrear la referencia.
EDITAR2: 'debugfs ln' funciona pero el riesgo es demasiado alto ya que borra los datos sin procesar del sistema de archivos. El archivo recuperado también es increíblemente inconsistente. El recuento de enlaces es cero y no puedo agregarle enlaces. Estoy peor de esta manera ya que puedo /proc/<pid>/fd/Nacceder a los datos sin dañar mi fs.
Respuesta1
Lo suficientemente impresionante sería si pudiera "deshacer" la eliminación ejecutando alguna opción mágica en ln que le permitiría volver a vincularse al número de inodo (recuperado a través de lsof).
Esta maravilla fue introducida lnenv8.0(GNU/coreutils) con la -L|--logicalopción que provoca lnla desreferenciación de un /proc/<pid>/fd/<handle>primero. tan simple
ln -L /proc/<pid>/fd/<handle> /path/to/deleted/file
es suficiente para volver a vincular un archivo eliminado.
Respuesta2
Parece que ya entiendes muchas cosas, así que no entraré en demasiados detalles. Hay varios métodos para encontrar el inodo y normalmente puedes cat y redirigir STDOUT. Puedes usardebugfs. Ejecute este comando dentro de:
ln <$INODE> FILENAME
Asegúrese de tener copias de seguridad del sistema de archivos. Probablemente necesitarás ejecutar un fsck después. Probé esto con éxito con un inodo aún en proceso de escritura y funciona para crear un nuevo enlace físico a un inodo desreferenciado.
Si el archivo se desvincula de un archivo no abierto en ext3, los datos se pierden. No estoy seguro de qué tan consistente es esto, pero la mayor parte de mi experiencia en recuperación de datos es con ext2. De las preguntas frecuentes de ext3:
P: ¿Cómo puedo recuperar (recuperar) archivos eliminados de mi partición ext3? En realidad, ¡no puedes! Esto es lo que dijo al respecto uno de los desarrolladores, Andreas Dilger:
Para garantizar que ext3 pueda reanudar de forma segura una desvinculación después de un fallo, en realidad pone a cero los punteros de bloque en el inodo, mientras que ext2 simplemente marca estos bloques como no utilizados en los mapas de bits del bloque y marca el inodo como "eliminado" y abandona el bloque. punteros solos.
Su única esperanza es "buscar" partes de sus archivos que se han eliminado y esperar lo mejor.
También hay información relevante en esta pregunta:
Respuesta3
la forma debugfs, como vio, realmente no funciona y, en el mejor de los casos, su archivo se eliminará automáticamente (debido al diario) después del reinicio y, en el peor de los casos, puede destruir su sistema de archivos, lo que resultará en un "ciclo de reinicio de la muerte". La solución correcta (TM) es realizar la recuperación en el nivel VFS (que también tiene el beneficio adicional de trabajar con prácticamente todos los sistemas de archivos Linux actuales). La forma de llamada al sistema (flink) se ha desactivado cada vez que aparecía en LKML, por lo que la mejor forma es a través de un módulo + ioctl.
Un proyecto que implementa este enfoque y tiene un código razonablemente pequeño y limpio es fdlink (https://github.com/pkt/fdlink.gitpara una versión probada con el kernel de ubuntu maverick). Con él, después de insertar el módulo (sudo insmod flink_dev.ko), puede simplemente hacer "./flinkapp /proc//fd/X /my/link/path" y hará exactamente lo que desea.
También puede usar una versión trasladada hacia adelante de vfs-undelete.sourceforge.net que también funciona (y también puede volver a vincularse automáticamente al nombre original), pero el código de fdlink es más simple y funciona igual de bien, así que es mi preferencia.
Respuesta4
No sé cómo hacer exactamente lo que quieres, pero lo que haría es:
- Abra el archivo RO de otro proceso.
- Espere a que salga el proceso original.
- Copie los datos de su FD abierto a un archivo
Obviamente no es lo ideal, pero es posible. La otra opción es jugar con debugfs (usando el linkcomando), ¡pero eso da un poco de miedo en una máquina de producción!