39 votos

Volver a enlazar un archivo borrado

A veces la gente borra archivos que no debería, un proceso de larga duración todavía tiene el archivo abierto, y la recuperación de los datos por catting /proc/<pid>/fd/N no es lo suficientemente impresionante. Bastante impresionante sería si pudieras "deshacer" el borrado ejecutando alguna opción mágica a ln que te permitiera volver a enlazar con el número de inodo (recuperado a través de lsof).

No encuentro ninguna herramienta de Linux para hacer esto, al menos con una búsqueda superficial en Google.

¿Qué tienes, fallo de servidor?

EDIT1: La razón por la que se ha catado el archivo de /proc/<pid>/fd/N no es lo suficientemente impresionante es porque el proceso que todavía tiene el archivo abierto sigue escribiendo en él. Un borrado elimina la referencia al inodo del espacio de nombres del sistema de archivos. Lo que quiero es una forma de recrear la referencia.

EDIT2: 'debugfs ln' funciona, pero el riesgo es demasiado alto, ya que frota los datos del sistema de archivos en bruto. El archivo recuperado también es muy inconsistente. El recuento de enlaces es cero y no puedo añadir enlaces a él. Estoy peor así ya que puedo usar /proc/<pid>/fd/N para acceder a los datos sin corromper mi fs.

19voto

tnimeu Puntos 71

Bastante impresionante sería si pudieras "deshacer" el borrado ejecutando alguna opción mágica a ln que te permitiera volver a enlazar con el número de inodo (recuperado a través de lsof).

Esta maravilla fue presentada a ln en v8.0 (GNU/coreutils) con el -L|--logical opción que provoca ln para hacer referencia a un /proc/<pid>/fd/<handle> primero. Así que un simple

ln -L /proc/<pid>/fd/<handle> /path/to/deleted/file

es suficiente para volver a enlazar un archivo borrado.

11 votos

Esto no funciona; si el archivo se borra, fallará.

2 votos

No, no lo hará. Yo lo uso regularmente para restaurar archivos borrados pero aún abiertos. Pero hay que asegurarse de que el nuevo /path/to/deleted/file está en el mismo sistema de archivos como estaba el archivo justo antes de ser eliminado, de lo contrario, esto - de hecho - fallará. (Puede obtener la ruta antigua con ls -l /proc/<pid>/fd/<handle> )

4 votos

Este tipo de funcionalidad (Ver esta pregunta y respuesta) fue específicamente rechazado como un riesgo de seguridad [a un hipotético esquema de seguridad que gira en torno a un proceso privilegiado que le da a su proceso un manejador de archivo de sólo lectura a un archivo que posee pero al que no tiene acceso de otra manera]; lo probé (aunque con un pequeño programa en C para usar directamente la llamada al sistema pertinente) y no funcionó.

14voto

Warner Puntos 17528

Parece que ya entiendes mucho, así que no entraré en excesivos detalles. Hay varios métodos para encontrar el inodo y normalmente puedes cat y redirigir STDOUT. Puedes usar debugfs . Ejecute este comando dentro de:

ln <$INODE> FILENAME

Asegúrate de tener copias de seguridad del sistema de archivos. Probablemente necesitarás ejecutar un fsck después. He probado esto con éxito con un inodo que todavía se está escribiendo y funciona para crear un nuevo enlace duro a un inodo desreferenciado.

Si el archivo se desvincula con un archivo no abierto en ext3, los datos se pierden. No estoy seguro de la consistencia de esto, pero la mayor parte de mi experiencia en la recuperación de datos es con ext2. Del FAQ de ext3:

P: ¿Cómo puedo recuperar (recuperar) archivos borrados de mi partición ext3? En realidad, ¡no se puede! Esto es lo que dice uno de los de los desarrolladores, Andreas Dilger, dijo al respecto:

Para garantizar que ext3 pueda reanudar de forma segura una desvinculación después de un accidente, 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 de los bloques y marca el inodo como "borrado" y deja los punteros los punteros de bloque.

Su única esperanza es "grep" para las partes de sus archivos que han sido borrados y esperar lo mejor.

También hay información relevante en esta pregunta:

He sobrescrito un archivo grande con uno en blanco en un servidor linux. Puedo recuperar el archivo existente?

0 votos

Comentario que espero sea borrado por no ser revelador.

1 votos

En el caso de un archivo borrado pero aún abierto no creo que se pongan a cero los punteros en el inodo. Además, en lugar de usar "ln" en debugfs yo usaría "undel" para que los recuentos de referencias de los inodos se actualicen correctamente.

0 votos

No quise aludir como tal, embobo. No es así, he probado el rendimiento. He aclarado mi lenguaje.

9voto

pktoss Puntos 61

La forma de debugfs como viste no funciona realmente y en el mejor de los casos tu archivo se borrará automáticamente (debido al diario) después de reiniciar y en el peor de los casos puedes destrozar tu sistema de archivos resultando en el "ciclo de muerte del reinicio". La solución correcta (TM) es realizar el undelete en el nivel VFS (que también tiene el beneficio añadido de trabajar con prácticamente todos los sistemas de archivos Linux actuales). La forma de llamada al sistema (flink) ha sido derribada cada vez que ha aparecido en LKML así 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.git para una versión probada con el kernel de ubuntu maverick). Con él, después de insertar el módulo (sudo insmod flink_dev.ko) puedes simplemente hacer "./flinkapp /proc//fd/X /my/link/path" y hará exactamente lo que quieres.

También se puede utilizar una versión de vfs-undelete.sourceforge.net que también funciona (y también puede volver a enlazar automáticamente con el nombre original), pero el código de fdlink es más sencillo y funciona igual de bien, por lo que es mi preferencia.

4voto

Bill Weiss Puntos 6677

No sé cómo hacer exactamente lo que quieres, pero lo que yo haría es:

  • Abrir el archivo RO desde otro proceso
  • Esperar a que el proceso original salga
  • Copiar los datos de su FD abierto a un archivo

No es lo ideal, obviamente, pero es posible. La otra opción es jugar con debugfs (usando el link ), pero eso es algo que da miedo en una máquina de producción.

0 votos

El comando debugfs link no soporta este caso de uso en absoluto.

0 votos

tldp.org/HOWTO/Ext2fs-Undeletion-11.html sugiere que sí. No lo he probado, pero parece razonable.

0 votos

link no funcionó en mis pruebas pero ln lo hizo.

2voto

jeffreypriebe Puntos 1070

Una pregunta interesante. Un entrevistador me hizo la misma pregunta en una entrevista de trabajo. Lo que le dije fue que no había una forma fácil de hacerlo y que, en general, no merecía la pena el tiempo y el esfuerzo que suponía. Le pregunté cuál creía que era la solución a este problema ....

  1. Utilice lsof para encontrar el número de inodo en el disco para el proceso, ya que seguirá apareciendo aunque el archivo haya sido eliminado... la clave es que siga abierto.
  2. Extraer la información del sistema de archivos basado en esto a través de un depurador del sistema de archivos.

1 votos

Puedo extraer los datos sin problemas de /proc/<pid>/fd/N pero eso no es lo que estoy tratando de hacer.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: