Bueno, aquí voy a contar como conseguí recuperar una partición ReiserFS que se fastidió (creo que porque se creó una unidad LVM sobre esa partición). A pesar del cachondeo con el que está escrito, me estuve informando por internet de los pasos que hacía, y conseguí recuperar los ficheros de la partición (al menos la mayoría de ellos). Por eso creo que puede ser más que útil para cualquiera que tenga un problema parecido. Eso sí: todo lo que hagais es bajo vuestra responsabilidad. A mi no me vengais a decir nada luego.
Bueno, a mi padre se le ha fastidiado un disco duro que tenía con linux (OpenSuse 10.1, creo...).
El sistema se da por perdido ya, pero justo mi padre se dejó allí unas fotos de su nieto que no tiene grabadas en ningún otro lado, y estamos intentando recuperar parte del sistema para ver si al menos podemos copiar las fotos a otro lado.
Ahora que intentamos ver dentro esto es lo único que hay:
linux:~ # vgs
VG #PV #LV #SN Attr VSize VFree
system 1 0 0 wz--n- 36.88G 36.88G
Grupo de volumenes que está completamente vacío (debería suponerlo ya al ver el espacio libre en el anterior comando)
linux:~ # lvscan
Aquí me quedo un poco perplejo. ¿Como es que hay un volumen correcto en la partición pero completamente vacío?
Yo supongo que dentro de este volumen estaría la partición de Linux, pero la verdad es que no recuerdo ni cuantas particiones ni que tipo de partición (como es SuSE, sospecho que era ReiserFS, pero tampoco lo tengo nada claro).
Una de las cosas que mucha gente echa en cara al Linux y que en cambio yo le veo una cierta ventaja, es que los ficheros de configuración son casi todos de texto.
Se me ocurrió buscar dentro de la partición a ver si podía encontrar el:
/etc/lvm/backup/system
Así al menos podía saber como estaba antes configurado el LVM en esta máquina.
La busqueda ha ido bastante bien:
# Generated by LVM2: Sat Sep 23 23:11:06 2006
contents = "Text Format Volume Group"
version = 1
description = ""
creation_host = "linux" # Linux linux 2.6.16.21-0.21-default #1 Tue Aug 29 16:42:05 UTC 2006 i686
creation_time = 1159045866 # Sat Sep 23 23:11:06 2006
system {
id = "hQoVaG-qvCt-jbzJ-vovn-HF2q
seqno = 2
status = ["RESIZEABLE", "READ", "WRITE"]
extent_size = 8192
max_lv = 0
max_pv = 0
physical_volumes {
pv0 {
id = "EJD1kZ-2CP1-DwLT-cGuk-ZR86
device = "/dev/hdb2"
status = ["ALLOCATABLE"]
pe_start = 384
pe_count = 9442
Para encontrar el contenido de este fichero en la partición usé
# grep -a -A 5000 -B 50 "Text Format Volume Group" /dev/hdb2 | strings | less
Joder, la putada es que lo que encuentro es lo que hay ahora. Joder, un LVM con una partición enorme vacía.
¿Como coño podía haber esto antes en el disco si había un Linux funcionando?
Menos mal, que intenté buscar el fstab. Y este contradice al anterior:
/dev/hda2 / reiserfs acl,user_xattr 1 1
/dev/hda1 swap swap defaults 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs noauto 0 0
usbfs /proc/bus/usb usbfs noauto 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0
/dev/cdrecorder /media/cdrecorder subfs noauto,fs=cdfss,ro,procuid,nosuid,nodev,exec,ioch
arset=utf8 0 0
none /subdomain subdomainfs noauto 0 0
Para encontrar el fstab usé esta otra búsqueda:
grep -a -A 10 -B 10 "/dev/hda1" /dev/hdb2 | strings | less
(Hice la búsqueda de esta manera porque sabía que /dev/hda1 es el swap, y en el fstab tiene que haber una entrada para el swap. Por eso, alguno de los ficheros que encuentre con /dev/hda1 será el fstab)
Según el FSTAB, esa partición no era LVM, y tenia un sistema reiserfs.
Además en la cabecera del fichero de LVM aparece una fecha curiosa: Sat Sep 23 23:11:06 2006
Eso es hace muy poco, cuando mi padre ya tenía su disco duro fastidiado desde finales de Agosto.
A ver... sospecha extraña. ¿No será que cuando mi padre intentó arreglar el linux con la opción de Reinstalación/Recuperación de maquina existente se fastidio la partición que había y la sobreescribió con LVM?
Y si es esto que ha pasado. ¿Pensais que se puede recuperar la partición que había antes?
Por lo que he visto con el 'grep', la partición continua teniendo datos (de hecho casi todos los datos), pero no tengo muy claro que hace el LVM cuando gestiona una partición. ¿Sobrescribe el principio de la partición? ¿Cuanto sobreescribe?
Otra duda que tengo... supongo que el ReiserFS este será como otros sistemas de ficheros Unix y tendrá varios supernodes separados por el disco, pero no se si se puede recuperar despues de haber fastidiado el comienzo. ¿Pensais que un reiserfsck puede hacer algún bien?
Al final me perdió la impaciencia.
He supuesto que el LVM ha sobreescrito la antigua partición ReiserFS y he decidido resucitarla.
Primero me he cargado el volumen lvm:
# vgremove
Luego he cambiado el tipo de la partición que antes era ReiserFS:
# sfdisk -c /dev/hdb 2 83
Ahora las particiones ya tienen otro aspecto:
Device Boot Start End Blocks Id System
/dev/hdb1 1 50 401593+ 82 Linux swap / Solaris
/dev/hdb2 * 51 4865 38676487+ 83 Linux
Pero bueno, de momento nada, porque el ReiserFS sigue estando muy mal:
# reiserfsck -l recover.txt --rebuild-sb /dev/hdb2
reiserfs_open: a superblock with wrong parameters was found in the block (16).
Failed to open the filesystem.
If the partition table has not been changed, and the partition is
valid and it really contains a reiserfs partition, then the
superblock is corrupted and you need to run this utility with
--rebuild-sb.
Esto da un miedo de cuidado... Porque la verdad es que no estoy seguro que no haya cambiado la partición, tan solo he cambiado el tipo y he confiado en que tenía razón.
Pero el mundo está lleno de valientes, y me animo a intentar recuperar el superblock:
# reiserfsck -l recover.txt --rebuild-sb /dev/hdb2
En las pregunta que hace, respondo a todo por los defectos. No tengo ni puta idea de como estaba configurada el ReiserFS de la partición, pero vengo la suerte de suponer que mi padre cuando instaló SuSE dejó los valores por defecto:
- Reiser 3.6.x
- Block Size de 4069
- Journal: si
- Resizer: no lo usé
- Do you want to rebuild the journal header?: si
Y tuve suerte:
Do you want to rebuild the journal header? (y/n)[n]: y
Reiserfs super block in block 16 on 0x342 of format 3.6 with standard journal
Count of blocks on the device: 9669120
Number of bitmaps: 296
Blocksize: 4096
Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 0
Root block: 0
Filesystem is NOT clean
El programa encontró un superblock. Parecía que estaba bien, así que ... cuando me preguntó si quería usarlo, respondí que sí.
Pero parecía que no había terminado todo:
The fs may still be unconsistent. Run reiserfsck --check.
Y la verdad tenía razón al hacerme la recomendación:
# reiserfsck --check /dev/hdb2
Reiserfs journal '/dev/hdb2' in blocks [18..8211]: 0 transactions replayed
Checking internal tree..
Bad root block 0. (--rebuild-tree did not complete)
Pero bueno, parece que todo se iba a arreglar con un --rebuild-tree:
# reiserfsck --rebuild-tree -S -l recovery.log /dev/hdb2
Esto se echó un buen rato...
Y ahora viene el momento crítico, a montar esta partición y ver que pasa:
# mount -t reiserfs /dev/hdb2 /mnt/rescue
La sorpresa es que parece haber quedado casi todo bien. No se, no voy a probar a rearancar el linux en este disco duro, pero al menos he podido acceder al /home y con un poco de suerte recuperar todos los ficheros que hagan falta. Luego, cuando sea menester, ya se reformateará y se instalará algo de nuevo.
¡¡Final Feliz!! Las fotos y los videosa de mi sobrino estan localizados y copiados. Prueba superada.
1 comentario:
Es cierto. Los desastres informáticos son totalmente inesperados, desde un pico de tension hasta un virus informático que te hace perder el tiempo hasta la desesperación. Es terrible el tiempo que he perdido en limpiar el ordenador, ni siquiera con una restauración del sistema se ha corregido el problema. A golpe de HKEY_LOCAL_MACHINE/Run y RunOnce. Que horror, y ni que decir de los Adware, hay que ser cansinos. Cuantas veces se nos ha pasado por la cabeza que se nos estropea el ordenador y que tenemos que hacer una copia de seguridad cuanto antes. Nadie ni núnca se esta a salvo de una eventual pérdida de datos de discos duros de ahí la importancia de un buen sistema de copias de seguridad. Esta es la mejor forma de recuperar su informacion en un momento de desastre que generalmente coincide con las prisas a la hora de utilizar el sistema. Y si a pesar de todo es necesario una recuperacion de datos ó recuperar el disco duro porque no teníamos las copias actualizadas, le recomendamos consulte con una empresa especializada como es el caso de www.lineared.com en dónde le podrán recuperar los datos ó llevar a cabo la recuperacion del disco duro . No lo dude, esta es la forma mas eficaz y segura de recuperar discos duros .
Publicar un comentario