![[LinuxFocus-icon]](../../common/images/logolftop_319x45.gif) |
LinuxFocus article number 340
http://linuxfocus.org
|
|
|
|
|
![[Photo of the Author]](../../common/images2/DetlefMuller_logo.gif)
por Detlef MÜller
<detlef_mue/at/web.de>
Sobre el autor:
Me llaman 'Linux' en el café internet, aunque sólo he estado trabajando
con el SO de Tux desde hace dos años ... quizás es el momento de
conseguir un BSD también. ...
Sin trabajo actualmente, pero me gustaría verme envuelto en un proyecto
de Linux. Para mi Linux es dos cosas, un sustituto del trabajo y un
hobby.
Mi otro hobby es Attac, desde el principio
de 2004. Me gustaría colaborar en la implementación de Linux de manera eficiente
en esta área.
Mi primera página
web ...
La visión: un sistema de e-democracia que
permita a todos los participantes votar en internet - usando
software libre, por supuesto.
Traducido al español por:
José Manuel González Calvar <jmcalvar(at)speedymail.org>
|
Pérdida de Datos: El Caso con Peor Panorama
Resumen:
Una de las mejores decisiones que he tomado sobre Linux ha sido la de
sólo utilizar sistemas de archivos que soportasen journaling .
Esta decisión ha sido confirmada justo ayer de una manera muy
convincente. Un proceso de copia chapucero se comió todos los datos en
la partición, incluidos todos los datos de un proyecto de Linux, y
además hizo la partición imposible de montar.
Era un sistema de archivos con journal ReiserFS ...
Los sistemas de archivos con journaling son algunas de las ventajas que
hacen que trabajar en Linux sea más seguro. Te aseguran contra
quepuedas usar el botón reset - generalmente (!) sin
que haya ningún efecto desastroso.
Este artículo sobre una pérdida de datos en la vida real
nos muestra que esto puede, a veces tener efectos deprimentes, y
describe los 'bits y bytes'del rescate heróico efectuado por una
herramienta profesional y funcional de Linux llamada 'reiserfsck'.
_________________ _________________ _________________
|
Introducción de Linux
Tux ha estado en mi ordenador desde hace aproximadamente dos años
- ahora tres pingüinos habitan en mi ordenador. Dos de la especie SuSE,
una del género Debian, Knoppix por linea materna.
Todo empezó, con una ganga que conseguí en E-Bay. Había
oído mucho sobre Linux, y quería llegar a ser un
especialista, por eso esta fue mi manera de empezar.
Problemas de Novato ...
Definitivamente los primeros pasos no fueron fáciles. Con
qué frecuencia terminé maldiciendo la superabundancia de
nuevos términos técnicos - especialmente cuando
éstos nunca son explicados (normalmente).
Cuando lees las primeras lineas del manual del distribuidor
Alemán, te inundan con KDE, YaST, Bash, etc,... y además una
revista de ordenadores con gran nombre, la ha descrito como la
distribución con mejor documentación ...
Ni caso - nada es simple o está claro.
(Suspiro) increíble...pero ocurre. Volvamos al punto principal.
ReiserFS en EISA 486
Este SuSE Linux 7.3 venía en un viejo 486 y todavía
tenía un viejo bus EISA (...si, esas cosas todavía
existen.)
El primer hard reset (botón reset) y siguiente reinicio causaron
problemas. No hubo más acceso al sistema de archivos, y
sólo se montaba en modo read-only (sólo acceso de
lectura).
"¿Qué se supone que quiere decir esto?"
Quiere decir un montón de trabajo. Los intentos de
reparación fueron infructuosos....finalmente, simplemente
reinstalé todo SuSE.
Todo esto me pasó 5 ó 6 veces. Cada vez que arrancaba con
el sistema de recuperación de SuSE, usaba la herramienta de
reparación e2fsck para sistemas de archivos ext2, y una vez
también edité el archivo /etc/fstab con el miserable
editor vi. El sistema estaba entonces OK...o quizás no.
Finalmente, reinstalé Linux. En este momento, habían
pasado un montón de días. Este asunto lleva tiempo a los
novatos...
Entonces tuve la idea - inspirado por un artículo en c't - de
instalar un sistema de archivos con journaling mediante YaST. Antes dije
que lo hice, y desde entonces he estado esquivando el tema de cómo
comencé a recuperar el sistema.
Si el sistema no se hubiera apagado de antemano, tendría un
efectivo 'replayed nnn transactions in ...' mientras Linux se estuviera
encendiendo, y el ordenador arrancaría correctamente.
"Aleluya!" pienso. Es mejor. Desde ahora, no más ext2 -
¡journaling es el camino a seguir desde aquí!
'Repetición del Journal' de una partición ReiserFS
mientras el sistema arranca ... (del archivo de log) :
.....
reiserfs: found format "3.6" with standard journal
reiserfs: checking transaction log (sd(8,4)) for (sd(8,4))
reiserfs: replayed 109 transactions in 10 seconds
reiserfs: using ordered data mode
.....
Pruebas Críticas
Quería saber para asegurar.
Cuando ya me había familiarizado razonablemente con el JFs,
realicé algunas pruebas críticas. El sistema de archivos fue sometido a
un hard reset con el sistema completamente arrancado.
Arranqué KDE, con cantidad de programas, abrí archivos con
el editor, entonces apreté el botó Reset. Las pruebas
fueron satisfactorias. El sistema de archivos sobrevivió
realmente sobrevivió.
El activar 'salida de emergencia' en un proceso de copia que está
corriendo no causó problemas.
El sistema SCSI 486 causó algunos problemas, aunque
ReiserFS 'es lo que indica en el bote'. Siempre devuelve
el sistema de archivos a un estado estado consistente y utilizable. Los
archivos abiertos asimismo vuelven a su estado original.
las pruebas que reailcé más tarde bajo las mismas
condiciones con ext3, la variedad de journal de ext2, fueron
también satisfactorias.
Esto es lo que aparece en el log con ext3 durante el arranque del
sistema:
.....
Journalled Block Device driver loaded
(recovery.c, 256): journal_recover: JBD: recovery, exit status 0,
recovered transactions 450798 to 451415
(recovery.c, 258): journal_recover: JBD: Replayed 3756 and revoked 6/15
blocks
kjournald starting. mit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,1), internal journal
ext3_orphan_cleanup: deleting unreferenced inode 355953
ext3_orphan_cleanup: deleting unreferenced inode 355952
EXT3-fs: sd(8,1): 2 orphan inodes deleted
EXT3-fs: recovery plete.
EXT3-fs: mounted filesystem with ordered data mode.
.....
Otros sistemas de archivo de journal
Esto ha sido el preámbulo ...
Desde entonces he venido utilizando ext3 y XFS.
He estado alejado de JFS, ya que se supone que no es totalmente
seguro aun. No estoy diciendo nada negativo de él, simplemente no
lo he probado todavía.
XFS ha desaparecido. No me importa; No he tenido problemas con
él, pero no lo utilizo desde hace tiempo.
He seguido utilizando el sistema de archivos ext3. Está ahora en un 486
corriendo un Debian / inestable.
Simpre es posible pasar una
partició con datos que tiene ext2 a ext3 - en un sistema
encendido. Yo lo he probado - funciona!
He vuelto a utilizar ext3 de nuevo la última vez que instalé
la versión de Knoppix en el disco duro.
La mayoría de los sistemas en mi PC de trabajo - sólo
un PIII/500 - están en ReiserFS.
Cómo están divididos los dos discos de mi PC de
trabajo:
Graphic 2, sda partitioning (SCSI disk)
Graphic 3, hda partitioning
D-day
Durante los pasados 3/4 de año he estado trabajando en un CD de
documentación para Linux. Esto supone gran cantidad de datos:
howtos, tutoriales, FAQs, más diferentes formatos y archivos en
cada caso, y el mismo volumen de nuevo para actualizaciones.
También estoy escribiendo archivos HTML adicionales, para que sea
fácil echarle un vistazo rápido al CD-ROM.
Ha habido un montón de cosas que hacer las pasadas semanas. Se
supone que una versión libre de este CD estará disponible
pronto. Así - poner junto una imagen, escribir unos cuantos scripts
para grabar en linea de comandos - es má rapido que utilizar un
programa de KDE.
Y pongo todo en mi disco duro. Mi almacén de datos es /dev/hda5 en
un disco de IDE de 60-Gb. La partición es de 20 Gigs (de los cuales
sobre el 80% está lleno). Todos los bits y bytes importantes,
supone cantidad de trabajo. Si le ocurriera algo alguna vez....oh,
seguramente no es muy probable, después de todo no es Windows con FATxx
.
He pensado muchas veces en hacer backups, pero hasta la fecha no he
hecho nada. Tengo algunas copias en un disco duro separado y las voy
dejando ahí.
Ayer por la tarde me fui del cafe Internet, donde descargué algunos
paquetes de la web de SuSE. Era documentación original de SuSE
desde la versi ón 7.3 hasta la 9.0 en dos CDs. Arranqué el PC
en casa con SuSE 8.1. Normalmente utilizo Debian, pero los pquetes de
SuSE eran RPMs, por eso usé la versión 8.1 esta vez. Y pude
instalar el primer paquete de documentació de la 9.0. No es
problema instalar un paquete más nuevo en la versión 8*.
Entonces instalé los RPMs de la versión 9.0, los copié a
la antes mencionada partició hda5, y desinstalé los RPMs. Hice
los mismo con la 8.0.
Sin cerrar KDE, cambié a otra consola y presioné <CTRL
ALT> <DEL> para apagar PC. Tuve un error en la linea de
comandos - olvidé exactamente lo que era - todo lo que recuerdo
es...que el PC se hizo el muerto. No podía hacer nada...
OK,
entonces presioné el botón del Reset - No tendré miedo de
hacerlo en Linux nunca más .
El peor panorama
Cuando arranqué Debian no noté nada al principio. Ya en KDE:
No estaba viendo directorios en mi partición
de trabajo.
Pero si estaba a punto de reventar ... ?
Probablemente no se
habráa montado(no, mierda - se monta automáticamente en el
arranque).
Y entonces, después de un mensaje de error tras intentar 'mount
/dev/hda5' - too many file systems - superbloque equivocado. Estaba
temiendo lo peor...
Lo que estoy expermientando es un caso real de de pérdida de
datos.
Y ahora? Erm ... quizás tratar de montarla de nuevo? De ninguna manera -
si no se montó la primera vez, no va a montarse la segunda vez.
Pero lo intenté de todos modos ... nada! La partición que tenía meses de
desarrollo, un montón de páginas HTML que había escrito, scripts para
quemar CDs, recopilaciones de DEBs y RPMs de Internet, y montones de
otras diversas cosas - todo se había ido, al Nirvana o donde quisiera
que se fuera..
Por supuesto, algunos datos están todavía en el disco, pero podré
acceder a ellos de nuevo?
Te reclinas, enciendes un cigarro ...
Lo primero que se me vino a la cabeza fue recuperación de datos. La
partición es una ReiserFS. Hay un montón de herramientas para esto. Una
vez leí algo en un artículo sobre Knoppix: Originalmente instalé Debian
desde Knoppix. Las herramientas debería estar ahí.
Y ahí estaban.
reiserfsck en una operación de emergencia
Primero un vistazo por el directorio doc. Debe estar bajo
/usr/share/doc/reiser-algo. Bajo Algo (...debería llamarse
reiserfsprogs) encontré algunos archivos en inglés, uno por cada
herramienta, extraidos de las páginas man.
Un vistazo rápido a las herramientas de recuperación de datos
revela que reiserfsck debe ser el 'bisturí'. bien, empezamos...
Primero lo llamé sin cambiar nada. -hacer chequeos parece lo correcto al
principio. Primero el diagnóstico, y luego la operación...
# reiserfsck -check
Bild 4, reiserfsck -check
No lo comprendo todo, pero comprendo que reiserfsck ha encontrado
errores y dice que los puede arreglar. Suena bien.
Pensé sobre un minuto en el comienzo de la operación. Manejo el bisturí
utilizando... ...
# reiserfsck --rebuild tree /dev/hda5
Graphic 5, reiserfsck --rebuild-tree
Esto me pone nervioso. No pienso - Voy a recuperar lo que tendré que
hacer en las próximas semanas.
"Estará restaurado el sistema ya?" ... Sí, debería.
Obtuve el viejo mensaje 'replaying journal'. Es el Buen Samaritano que
hace la restauración posible - un tipo de tabla de contenidos para todas
las subparticiones. Dos lineas más tarde, reiserfsck viene a través de
un bit nulo incorrecto y... lo corrige.
Lo que viene Pass 0 de la restauración, visualmente separado en
la consola. Este proceso toma cerca de 15 minutos para mis 20 GB...una
pantalla de porcentaje se muestra al usuario para que eche un ojo al
progreso.
El gráfico 2 muestra los detalles de un error. Qué quiere decir
exactamente? Hmm ... pregúntame algo más. :)
Gráfico 6, Pass 0 up to 2, 3 (el principio
sólo)
Está en ello ... Pass 1 es realmente rápido. No hay mensajes de
error de datos.
Pass 2 es lo mismo.
En Pass 3 me desbordaron un montón de mensajes de error.
Reconozco los archivos, son del proceso de copia de la documentación de
SuSE. Esto demuestra que algo fue erróneo con este proceso de copia en
particular. ¿Que sería, un bug en el Konqueror de KDE 3 o un bug en
ReiserFS?
Graphic 7, Pass 3 (end)
De acuerdo a la descripción, se realiza una búsqueda en Pass 3a
de archivos perdidos o directorios.
Gráfica 8, Pass 3a
La herramienta normalmente encuenra lo que está buscando, especificando
el error, y corrigiendo las entradas relevantes, presentándolas con un
'corrected to ...' al final de la línea.
Entonces muestra un resumen de sus operaciones normales de rescate. En
Pass 4, nos muestra un mensaje simple de que la sincronización
(del journal en su estado actual en el disco duro) ha finalizado.
Graphic 9, Pass 4 and end
Ahora mis datos son accesible otra vez.
No tengo mensajes durante el montaje - un signo fiable de que un comando
UNIX se ha ejecutado con éxito. :-))
Bien está lo que bien acaba?
Y el Konqueror me está mostrando mis viejos directorios en la partición
hda5. Todo ha vuelto a su sitio de nuevo ... o debería decir, casi
todo. Se han perdido algunos de los archivos copiados - lógicamente. No
se puede esperar un resultado perfecto de un proceso fallido. Puedo
volver a copiarlos.
Hoy, el día después, todavía no he chequeado mis datos en hda5. Pero es
como si todo hubiera sido restaurado. La herramienta ha parecido muy
profesional en uso crítico!
Son las 16:30 hrs del día D-Day+1. La campana de alarma sonó hace 18
horas. El artículo (éste) está próximo a finalizarse - esto es cómo fue
una operación de emergencia con éxito.
Estoy contento de haber salvado el progreso de la 'consola' después de
recuperarlo en un archivo ayer. Esto quiere decir que he podido incluir
capturas de pantalla del 'accidente' original en este artículo.
P.D (2 días más tarde): no hay señal de ninguna pérdida de datos.
Trabajo en la partición afectada todo el tiempo
Veredicto
Pérdida de datos pueden ocurrir en un sistema de archivos de journal,
pero las oportunidades de recuperación completa son más altas. JFs son
fiables y fáciles de mantener.
Un sistema de archivos de journal es un deber para cada
usuario de Linux (perdonarán una opinión tan rotunda en el mundo del
software libre).
La mayoría de las distribuciones ofrecen al usuario un sistema de
archivos de journal o configuración predetarminada durante el
procedimiento de instalación.
Y ... eso significa que a los que no les gustan los backups pueden
disponer de sus datos sin necesidad de backup.
Sin embargo, esto no
debería derivar en no realizar copias de seguridad.
Así que siempre
haga backups!
Referencias
Artículos sobre sistemas de archivos de Journal:
2005-01-14, generated by lfparser_pdf version 2.51
