fondo:
Siendo un poco cobarde, hasta ahora tengo ddsistemas de archivos completos como respaldo. El mayor inconveniente ha sido el uso excesivo de memoria para esas copias de seguridad completas (que lamentablemente también incluían bloques gratuitos)
pregunta
Me gustaría hacer una copia de seguridad ahora solo de los archivos dentro del sistema de archivos, pero aún así poder recrear el sistema de archivos si es necesario. Si bien los datos se pueden extraer fácilmente (es decir, a través de rsync -a),
me pregunto si hay algunoscasospaso por altodóndepor ejemplo el¿Importaría el número de inodo asignado al archivo?
Esto es especialmente en el contexto de realizar una copia de seguridad del /sistema de archivos raíz con el sistema en él. No estoy tan preocupado por el /home/sistema de archivos, pero ¿sería lo suficientemente imaginativo como para esperar que ocurra algo extraño al restaurar el /sistema de archivos raíz y de repente los inodos hayan cambiado?
Una buena respuesta incluiría una lista más completa de casos en los que el número de inodo podría ser importante y eventualmente causar problemas.
actualizar Algunos experimentos revelan que, por ejemplo, elenlaces duros(naturalmente haciendo referencia al mismo inodo) podría necesitar algo de atención. No estoy seguro de si es necesario reasignarlos necesariamente al mismo inodo.
Afortunadamente, la cantidad de enlaces físicos en un Ubuntu 12.04 simple aquí es solo de aproximadamente 10 archivos (para que pueda grabarlos en secuencias de comandos y repararlos si es necesario y rsync -ano me importe el número de inodo)
Ejemplo Un caso que creo importante es el deselinuxmódulo de seguridad, ya que básicamente utiliza números de inodo. Entonces este ya es un caso, pero tal vez haya otros.
Actualización2
Acabo de ejecutar una prueba de copia de seguridad y restauración de un sistema Ubuntu 12.04 ficticio rsync -aHmientras reformateo la partición intermedia para configurar un nuevo ext4 mediante mkfs.ext4 /dev/sdX -U oldfsUUID. Esencialmente, cuando los archivos restaurados, todos los inodos utilizados con mayor frecuencia ya no estaban relacionados con los originales. Afortunadamente, parece que para este caso de mi configuración de Ubuntu 12.04 los inodos no parecieron importar. Soy consciente de que esto no prueba mucho. Todavía agradecería una respuesta con una lista de casos problemáticos. El que selinuxya mencioné, pero creo que puede haber más y de ahí la posibilidad de una buena respuesta de alguien que sepa.
Respuesta1
Los números de inodo no importan para las aplicaciones normales. Esto se debe en parte a que los números de inodo tienen poca utilidad y en parte a que si una aplicación dependiera de los números de inodo, dejaría de funcionar después de un ciclo de copia de seguridad y restauración. Entonces, los sistemas de respaldo no restauran los números de inodo, por lo que las aplicaciones no dependen de ellos, por lo que los sistemas de respaldo no necesitan restaurar los números de inodo.
La mayoría de los enfoques para las copias de seguridad ni siquiera podrían restaurar los números de inodos. El controlador del sistema de archivos en el kernel usa cualquier inodo que esté libre al crear un archivo, no hay forma de restringirlo desde las aplicaciones.
Algunos sistemas de archivos ni siquiera tienen números de inodo.
Lo único para lo que las aplicaciones usan números de inodo es para probar si dos rutas designan el mismo archivo: comparar el número de dispositivo y el número de inodo, en un momento específico. Para ello, el número de dispositivo y el número de inodo no tienen que permanecer constantes en el tiempo. Los propios programas de respaldo hacen esto para detectar enlaces físicos.
No hay manera de abrir un archivo dado su número de inodo, o acceder a un archivo a una ruta dado su número de inodo (excluyendo las herramientas de depuración que requieren acceso al dispositivo de bloque subyacente). En la mayoría de los sistemas de archivos, la ruta apunta al inodo, pero el inodo no contiene un puntero al directorio que contiene el archivo, por lo que esto no se podría implementar sin atravesar todo el sistema de archivos. Además, el archivo podría incluso eliminarse (es decir, podría tener un recuento de enlaces físicos de 0, esperando a que se cierre antes de que se elimine su contenido y se libere su inodo).
SELinux usa inodos para rastrear contextos, no números de inodos. Los contextos SELinux se almacenan mediante rutas, como todo lo demás.
rsync -AHXes una forma segura y común de realizar copias de seguridad.
Puedo pensar en una aplicación que usa números de inodo: algunas versiones dePícaro, uno de los primeros juegos basados en terminal de pantalla completa, lo que motivó la biblioteca Curses que todavía se utiliza en la actualidad. Almacena el número de inodo en un archivo guardado para evitar la copia casual de archivos guardados. Nunca he visto eso hecho en una aplicación "seria".