El otro día estaba buscando en mi servidor NFS unas plantillas de Joomla para un sitio web que estoy ayudando a construir, pero me di cuenta que las plantillas no estaban por ninguna parte, continué buscando, pero al final no encontré nada, sólo logré encontrar algunas plantillas en el disco duro de mi laptop, las cuales me salvaron la vida y con las que pude reconstruir lo que había comenzado días atrás; finalmente subí al servidor NFS el contenido de las plantillas para almacenarlas en el directorio del proyecto, pero la pregunta es: ¿qué pasó con las plantillas originales que yo guardé? Lo más extraño es que ese disco en el cual yo guardo mis datos, fotos, música, etc., que por cierto es un disco externo, le hago respaldo diario a eso de las 3am, hacia otro disco externo usando el programa rsync, así que decidí buscar las plantillas en el disco de respaldo, pero tampoco hubo éxito, la misma información del disco de datos estaba en el disco de backup, menos los archivos que yo buscaba.
Para hacer corta la historia, descubrí que fue lo que pasó y el porqué las plantillas desaparecieron, la respuesta es la siguiente, pero primero veamos la configuración del sistema: actualmente tengo conectados a una laptop con Fedora 13, dos discos duros externos de 1TB cada uno, montados en los directorios /mnt/data y /mnt/backup, estos discos estan conectados por medio de los puertos USB, las particiones de datos y backup se identifican como /dev/sdb1 y /dev/sdc1 respectivamente, los cuales aparecen en el archivo /etc/fstab. Hasta ahí todo bien; para hacer el respaldo del disco de datos, utilizo rsync+crontab como dije anteriormente y el comando que utilizo para tal es el siguiente ya en el archivo crontab:
0 3 * * * rsync -av --delete /mnt/data/ /mnt/backup/
De esta forma el backup es realizado a las 3 AM todos los días, parte de la culpa de la pérdida de los archivos que yo buscaba se encuentra en esa línea de comandos, específicamente en el parámetro --delete, este parámetro lo que hace es mantener una copia exacta del folder de origen en el destino, de esa forma cualquier archivo que ha sido borrado del origen, es tambien eliminado del destino al momento de hacer el backup; ahora la explicación es que los discos en algún momento se desmontaron (posiblemente por una falla eléctrica) y cuando volvieron a montarse lo hicieron en el punto de montaje contrario, el disco de respaldo, o backup, con archivos faltantes fue montado como el disco de datos, por tanto cuando el comando rsync fué ejecutado por el crontab, el disco de origen no tenía las plantillas en las cuales yo habia trabajado, pero si estaban en el disco de backup y gracias a la opción --delete estas fueron borradas.
Ahora la pregunta es ¿cómo prevenir que ésto suceda nuevamente?, la respuesta esta en el Identificador Unico Universal o UUID, por sus siglas en inglés, y utilizarlo para identificar a los discos externos al momento de montarlos por medio del archivo /etc/fstab como se muestra a continuación:
Primero, tenemos que obtener los UUID de los discos externos que estoy utilizando para posteriormente actualizar estos datos en el archivo /etc/fstab, podemos hacer uso del comando blkid de la siguiente forma:
$ blkid /dev/sdb1
/dev/sdb1: UUID="a1849435-8fd4-4fb6-8432-07f4b4973297" TYPE="ext3"
O también podemos hacer uso del siguiente comando para ver los UUID de todos los discos en el sistema:
$ ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 Jan 5 19:20 0a021fff-4a8a-4df9-8c2a-db06c644a11d -> ../../sda1
lrwxrwxrwx 1 root root 10 Feb 15 17:31 0c630398-7933-4f74-aef0-ac2bc63333ec -> ../../sdc1
lrwxrwxrwx 1 root root 10 Jan 5 19:20 14efb499-dcc5-42e2-a13c-37741fc5d0da -> ../../sda3
lrwxrwxrwx 1 root root 10 Jan 5 19:20 42f2f283-d5d5-4a84-9720-70bf549a8b45 -> ../../sda2
lrwxrwxrwx 1 root root 10 Jan 5 19:20 a1849435-8fd4-4fb6-8432-07f4b4973297 -> ../../sdb1
[fdiaz@fcofs ~]$
Con la información anterior, actualizamos el archivo /etc/fstab:
$ more /etc/fstab
#
# /etc/fstab
# Created by anaconda on Sun Dec 12 11:05:45 2010
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=14efb499-dcc5-42e2-a13c-37741fc5d0da / ext4 defaults 1 1
UUID=0a021fff-4a8a-4df9-8c2a-db06c644a11d /boot ext3 defaults 1 2
UUID=42f2f283-d5d5-4a84-9720-70bf549a8b45 swap swap defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
UUID=a1849435-8fd4-4fb6-8432-07f4b4973297 /mnt/data ext3 defaults 1 3
UUID=0c630398-7933-4f74-aef0-ac2bc63333ec /mnt/backup ext3 defaults 0 0
Ahora cada vez que el sistema inicia, lo cual pasa unas dos veces al año, pero en caso de que la energía eléctrica falle o cuando me voy de vacaciones, el sistema se encargará de montar el disco correcto en el punto de montaje adecuado y no tendré el problema de perdida de datos cuando el comando rsync sea ejecutado al hacer el respaldo de los discos.
¿Pero, qué es el UUID? bueno es un identificador usado en algunas aplicaciones de software, está estandarizado por la Fundación de Software Libre, u OSF por sus siglas en inglés, como parte del Ambiente de Computación Distribuido (o DCE: Distributed Computing Environment).
La idea detrás del UUID es permitir que diversos sistemas puedan identificar componentes de software de forma única, de esta forma se pueden identificar objetos de forma inequívoca con cierta confianza de que no encontrará otro objeto con el mismo identificador. Entre los usos más comunes de esta tecnología se encuentran:
- Los UUID se utilizan para nombrar objetos COM;
- Sistemas de particionamiento de discos duros;
- Second Life lo utiliza para identificar todos los objetos existentes en su mundo virtual;
- etc.
El UUID es un número de 16 bytes(128 bits), con una cantidad aproximada de 3 x 10³⁸ posibles combinaciones de números, en su forma canonica consiste de 32 numeros hexadecimales, presentados en 5 grupos y separados por guiones, siguiendo el patrón 8-4-4-4-12, haciendo un total de 36 caracteres (32 numeros y 4 guiones), asi tenemos los siguientes ejemplos de identificadores UUID:
550e8400-e29b-41d4-a716-446655440000
0c630398-7933-4f74-aef0-ac2bc63333ec
a1849435-8fd4-4fb6-8432-07f4b4973297
Las especificaciones técnicas, algoritmos y una implementación de UUID se encuentran en el documento RFC 4122 para quienes esten interesados en profundizar más al respecto sobre las diferentes versiones y variantes de los UUID, asi como sus usos en otras áreas.
Hasta la próxima.
http://www.ietf.org/rfc/rfc4122.txt
http://en.wikipedia.org/wiki/Universally_unique_identifier
http://wiki.secondlife.com/wiki/UUID
