Y me dice que no hay volúmenes lógicos definidos. Oficialmente preocupado.
Ya con esto comienzo a buscar en Internet y no encontré al menos de momento nada que me ayudara directamente. Salvo que personas con casos similares a los míos resolvieron volcando los primeros bits de la partición y de aquí sacaron el archivo de backup de lvm
Eso no funcionó para mi, pero si me orientó en el camino, ya que en esa página se asegura que el archivo de configuración se guarda al principio d ela partición, pero pensé que no necesariamente era mi caso, dado a que la partición la entrego desde el virtualizador en LVM y el a su vez esta partición la trabaja y la convierte a LVM. Tal véz el Journaling del virtualizador hizo su trabajo (solo especulo).
Así que hice lo siguiente:
Cree un nuevo volúmen lógico en el virtualizador un tanto más grande que el volumen que deseaba restaurar y le dí formato ext2 Le entregué este nuevo "disco" a la maquina virtual. Inicie la maquina virtual y esperé que saliera el initramfs Monte la partición en /target
Hice un volcado completo del disco (en mi caso /dev/sda5 donde estaba creado el volumen en la maquina virtual) a un archivo (lo llame salida) en mi nuevo disco:
dd if=/dev/sda5 of=salida.txt
Apagué la maquina virtual y monté el disco en el virtualizador.
Busqué en el archivo "salida.txt" la cadena "logical_volumes" y me hice una idea en que parte estaba las líneas que necesitaba (realmente en este punto fue suerte porque nunca había modificado el sistema de archivos y solo había una copia)
grep -a -n -i logical_volumes salida.txt
Con sed estraje ±100 líneas.
sed -n -e '201200,201300p' -e '201300q' > tmp.txt
En el nuevo archivo, con vim busque la cadena "#Generated" y al encontrarlo encontré la configuración, esta la pegue en un nuevo archivo llamado backup.conf Desmonté mi disco en el virtualizador e inicie la maquina virtual hasta que cayera de nuevo en el initramfs.
Ahora mi nuevo problema, la metadata sigue mala. Por lo que cambié el uuid para que reparara la metadata
pvchange -u /dev/sad5
Al ejecutar vgcfgrestore me daba error (lógico, el uuid del pv no coincida con el uuid del sda5). Hice un pvdisplay y tome nota del nuevo uuid. Apague nuevamente mi maquina virtual monté el disco en el virtualizador, edité el archivo, cambio el uuid del pv0 para que cocindiera con el uuid de la maquina. Desmonté e inicie de nuevo la maquina virtual hasta el initramfs.
Ejecute vgcfgrestore y funcionó.
vgcfgrestore -vvv -f /target/backup.conf
Reinicié la maquina virtual y arrancó sin problemas.
Mientras redacto este articulo me doy cuenta que los comandos sed y grep los pude haber ejecutado directamente sobre /dev/sda5, y de esta forma ahorrarme el volcado del disco, en fin, son cosas que se piensan luego con calma, si alguien lo puede probar.
Quizá es una partición de una máquina virtual, si es así tiene otro procedimiento
quizá deba revisarse el LV!!!! EL LV! el LV se revisa como fsck /dev/c/c
nunca nunca se hace con la partición del disco, si tienes LV todo es con LV.
Montar LVM GNU/Linux y Reparar
sudo su
instalamos lvm2
aptitude install lvm2 ó yum install lvm2
fdisk -l (para verificar que existen lvm)
pvscan (escaneo particiones lvm)
vgscan (detectar grupos LVM)
vgchange -a y (activa los LVM logicos para poder escanearlos)
lvscan (para poder ver los volumenes logicos disponibles)
crear una carpera en la cual montar el volumen logico.
/mnt/volumen1 o /media/volumen1 según el sistema.
para un caso particular es importante que el sistema no monte en el arranque /dev/sales/reports ya que si esta corrupto no permitira autenticar en el sistema.
Type root's password Edit the /etc/fstab file Comment out the line with /dev/sales/repor Reboot
Para verificar el estado de los volumenes y comprobar si tenemos errores
cat /proc/partition pvscan
si tenemos errores
Fortunately, the meta data and file system on the disk that was /dev/sdc are intact. So the recovery is to just put the disk back. Reboot the server. The /etc/init.d/boot.lvm start script will scan and activate the volume group at boot time. Don't forget to uncomment the /dev/sales/reports device in the /etc/fstab file.
Otra forma de error LVM corrupto. Solution 1:
Since the disk was never removed, leave it as is. There were no device UUID errors, so don't attempt to restore the UUIDs. This is a good candidate to just try restoring the LVM meta data. Run a file system check on /dev/sales/reports. whit e2fsck /dev/sales/reports
si vgcfgrestore sales falla
vgcfgrestore sales
Couldn't find device with uuid '56ogEk-OzLS-cKBc-z9vJ-kP65-DUBI-hwZPSu'. Couldn't find all physical volumes for volume group sales. Restore failed.
Comparing the output of cat /proc/partitions and pvscan shows the missing device is /dev/sdc, andpvscan shows which UUID it needs for that device. So, copy and paste the UUID that pvscan shows for /dev/sdc.
ls-lvm:~ # pvcreate --uuid 56ogEk-OzLS-cKBc-z9vJ-kP65-DUBI-hwZPSu /dev/sdc
Physical volume "/dev/sdc" successfully created
Restore the LVM meta data
ls-lvm:~ # vgcfgrestore sales
Restored volume group sales
ls-lvm:~ # vgscan
Reading all physical volumes. This may take a while...
Found volume group "sales" using metadata type lvm2
ls-lvm:~ # vgchange -ay sales
1 logical volume(s) in volume group "sales" now active
Run a file system check on /dev/sales/reports.
ls-lvm:~ # e2fsck /dev/sales/reports e2fsck 1.38 (30-Jun-2005) /dev/sales/reports: clean, 961/131072 files, 257431/262144 blocks
ls-lvm:~ # mount /dev/sales/reports /sales/reports/
ls-lvm:~ # df -h /sales/reports
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/sales-reports
1008M 990M 0 100% /sales/reports
Tomado de http://www.novell.com/coolsolutions/appnote/19386.html http://hotfixed.net/2011/07/25/montar-particiones-lvm-desde-un-livecd/
pero cometí un grave error, que ejecuté el comando:
pvcreate /dev/sdb1
Donde sdb1 era uno de los dos discos duros que ya formaban parte del volúmen :(
Al hace vgscan obtenía esto:
mail:/etc/lvm/archive# vgscan Reading all physical volumes. This may take a while… Couldn't find device with uuid 'lgV0hS-vv3p-k06d-xk1C-5NT7-PBxI-kEXcF6'. Couldn't find all physical volumes for volume group mail. Couldn't find device with uuid 'lgV0hS-vv3p-k06d-xk1C-5NT7-PBxI-kEXcF6'. Couldn't find all physical volumes for volume group mail. Volume group “mail” not found
Esto significa que el volúmen mail ya no existía !!
Afortunadamente, encontré a Epe en la noche y a través del chat me dió las luces de como podría recuperar el volúmen. De esta conversación nació esta frase :).
Esto es lo que hice para recuperar el volúmen:
1.- hacer un backup de lo importante, como el servidor tenía pocas horas de instalado no lo había hecho antes :) 2.- dentro de /etc/lvm podemos encontrar archive/ y backup/. Esta ultima ruta es muy importante porque mantiene un respaldo de los volúmenes para casos de desastre; 3.- Al hacer vgscan obtenía el uuid del disco que faltaba en el volúmen y por el cual este no arrancaba, dentro de /etc/lvm/backup/mail existía una entrada para el pv /dev/sdb1 con ese uuid 4.- Para recrear el volúmen conociendo el uuid se ejecuta:
pvcreate –uuid “lgV0hS-vv3p-k06d-xk1C-5NT7-PBxI-kEXcF6” –restorefile /etc/lvm/backup/mail /dev/sdb1
5.- Eso restaurará el volúmen, lo podemos contatar con el comando vgdisplay:
VG Name mail System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 4 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 2 Act PV 2 VG Size 67,58 GB PE Size 4,00 MB Total PE 17301 Alloc PE / Size 8620 / 33,67 GB Free PE / Size 8681 / 33,91 GB VG UUID l56tSf-1JWP-hK8q-1eLa-G2Vj-YwAw-ER5hWK
Y listo, ya esta restaurado el volúmen :)
Ahora, para agregar los demás discos previamente particionados hice:
vgextend mail /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1
Y cambié el tamaño con:
resize2fs /dev/mapper/mail-root
Luego de eso, vgdisplay me muestra lo siguiente:
— Volume group — VG Name mail System ID Format lvm2 Metadata Areas 5 Metadata Sequence No 6 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 6 Act PV 6 VG Size 203,22 GB PE Size 4,00 MB Total PE 52025 Alloc PE / Size 51884 / 202,67 GB Free PE / Size 141 / 564,00 MB VG UUID l56tSf-1JWP-hK8q-1eLa-G2Vj-YwAw-ER5hWK
Que fácil fué pasar de tener 32Gb a 200 :) pero que susto que me llevé.
Esta experiencia me hizo sacar tres conclusiones, puede resultar muy pero muy fácil perder la información por ingresar mal un comando, el backup es muy importante y, siempre es bueno tener a un guru conectado al mensajero instantáneo ;)
Cada vez que realice una operación con LVM, por defecto, el anterior metadatos está archivado en /etc/lvm/archive. Usted puede utilizar vgcfgrestore a restaurar, o agarrar la extiende con la mano (más difícil, pero lvcreate(8) debe cubrir).
Ya puedo acceder a todo el disco, por lo que puedo recuperar los datos perdidos. ¿Cómo lo he hecho? pues ahora lo explico:
Primero he creado un fichero de texto, al que en un brote de originalidad le he puesto de nombre mandriva.lvm el cual en principio contiene la definición del LVM cuando funcionaba, pero al que hay que modificar algunas opciones para que coincida con el sistema actual. El fichero final ha sido el siguiente:
MANDRIVA { id = “eNt60S-MX9n-vHc7-rnsJ-hQma-aVq9-1K04Ie” # id actual del LVM, a “buscar” seqno = 6 status = [“RESIZEABLE”, “READ”, “WRITE”] extent_size = 8192 max_lv = 0 max_pv = 0
physical_volumes {
pv0 { id = “ejlwIR-iUOU-dAY0-gnjS-qMOG-89qS-Rmd4jP” # id actual del disco físico a “buscar” device = “/dev/sdf3” # el fichero de dispositivo, que no hará falta explicar como se obtiene ;)
status = [“ALLOCATABLE”] pe_start = 384 pe_count = 76038 } }
logical_volumes { root { id = “PASJvW-dOga-ESF3-p4ba-U0lZ-W9n4-nC5b3S” status = [“READ”, “WRITE”, “VISIBLE”] segment_count = 1
segment1 { start_extent = 0 extent_count = 3584
type = “striped” stripe_count = 1 # linear
stripes = [ “pv0”, 0 ] } }
games { id = “52tD7P-y83Y-McfE-2mOO-Qgfz-FtSR-3B6lLs” status = [“READ”, “WRITE”, “VISIBLE”] segment_count = 1 segment1 { start_extent = 0 extent_count = 4100
type = “striped” stripe_count = 1 # linear
stripes = [ “pv0”, 3584 ] } }
home { id = “i7LZyI-AFac-rNXR-YdJ2-2250-2Uv7-4o8YxJ” status = [“READ”, “WRITE”, “VISIBLE”] segment_count = 1
segment1 { start_extent = 0 extent_count = 68354
type = “striped” stripe_count = 1 # linear stripes = [ “pv0”, 7684 ] } } } } # Generated by LVM2: Sat Sep 8 12:25:44 2007
contents = “Text Format Volume Group” version = 1
description = “”
creation_host = “localhost” # Linux localhost 2.6.17-13mdvlegacy #1 SMP Fri Mar 23 19:05:24 UTC 2007 i686 creation_time = 1189254344 # Sat Sep 8 12:25:44 2007
Con este fichero entonces hay que restaurar el LVM y luego activarlo en el sistema:
[root@asterix ~]# vgcfgrestore -f ./mandriva.lvm MANDRIVA
Restored volume group MANDRIVA
[root@asterix ~]# vgchange -a y MANDRIVA
3 logical volume(s) in volume group "MANDRIVA" now active
A partir de este glorioso momento ya podemos montar los tres volúmenes lógicos con normalidad y acceder a los datos.
Evidentemente el principal problema era saber cuales eran los id's del LVM. El primero lo he encontrado con el comando lvm:
[root@edhunter ~]# lvm lvm> vgdisplay
VG Name MANDRIVA
System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 1 VG Access read/write VG Status resizable MAX LV 0 Cur LV 0 Open LV 0 Max PV 0 Cur PV 1 Act PV 1 VG Size 297,02 GiB PE Size 4,00 MiB Total PE 76038 Alloc PE / Size 0 / 0 Free PE / Size 76038 / 297,02 GiB VG UUID eNt60S-MX9n-vHc7-rnsJ-hQma-aVq9-1K04Ie
Como podéis ver, el valor de esta última línea es la del id usado al principio de mi fichero y que define al LVM. Ahora el segundo valor, pues también dentro del programa lvm:
lvm> pvdisplay
PV Name /dev/sdf3
VG Name MANDRIVA PV Size 297,02 GiB / not usable 507,00 KiB Allocatable yes PE Size 4,00 MiB Total PE 76038 Free PE 76038 Allocated PE 0 PV UUID ejlwIR-iUOU-dAY0-gnjS-qMOG-89qS-Rmd4jP
Otra vez, el valor de esta última línea nos muestra el id que nos faltaba. Además, por si a alguien le quedaba una duda, ahí también sale que el dispositivo es /dev/sdf3, aunque creo que a estas alturas ya era obvio para todos.
ReadyNAS uses non-standard ext3 block-size, which in my case is 16384 bytes (use command "lvsc" to check) The home directory is partitioned as LV group, so conventional mount command is not gonna work
We cannot use regular command “mount” to mount the non-standard blocksize ext3 partition. Fortunately, there is a tool called “fuse-ext3” running in userspace that can help us. The tool can be downloaded here.
Here's an example how to mount my ReadyNAS's LV volume:
fuse-ext2 -o sync_read,allow_other,rw+ /dev/c/c /media/readynas2
And here is the command to mount the system (root) partition which has the Linux software (I will post later about how to reset root password without resetting the ReadyNAS to factory default etc.)
fuse-ext2 -o sync_read,allow_other,rw+ /dev/c/c /media/readynas2
I know this topic has been covered many times in these forums and other places on the net, but I am still having trouble accessing the actual files on the NAS disks. I have come frustratingly close to being access the files, but not close enough! I'd like to know why my directory listing of the mounted raid looks like this?:
root@ubuntu:/mnt# ls -lasc ls: cannot access backup: Input/output error ls: cannot access media: Input/output error ls: cannot access home: Input/output error ls: cannot access .timemachine: Input/output error ls: cannot access testshare: Input/output error total 68 16 drwxrwxrwx 8 root root 16384 2011-11-02 15:24 . 4 drwxr-xr-x 22 root root 4096 2011-11-02 20:40 .. 16 -rw——- 1 root root 7168 2011-11-02 15:28 aquota.group 16 -rw——- 1 root root 7168 2011-11-02 15:28 aquota.user ? -????????? ? ? ? ? ? backup ? -????????? ? ? ? ? ? home 16 drwx—— 2 root root 16384 2011-11-01 19:57 lost+found ? -????????? ? ? ? ? ? media ? -????????? ? ? ? ? ? testshare ? -????????? ? ? ? ? ? .timemachine root@ubuntu:/mnt#
and what do I need to do to access the files in the folder “testshare”?
Some background info:
I have two identical ReadyNAS NV+ with four 750GB drives in each of them, using x-raid (giving ~2TB storage). One of them is totally messed up, and one is just fine. The working one is basically empty - it only has 8 jpeg images stored in a share called testshare. My thinking is that I need to prove that I can recover 8 lousy jpegs from the one that is working before I will have any chance of recovering thousands of precious jpegs from the trashed one Smiley Sad
My test setup:
MacBook Pro running VirtualBox, with a VM running ubuntu 10.04. lvm2 and fuseext2 are installed. I have created four virtual hard disks, each 698.64 GB, and attached them to the VM. I have created another virtual disk, which I use for accessing a physical hard drive attached to the host via a USB SATA adapter. I have cloned, one-by-one, each of the four disks from the working NV+, though only the first 5 GB, assuming that this should be more than enough data from each disk to be able to access the less than 20 MB of files on the RAID volume.
For cloning from the physical disk (always /dev/sdf) to each of the raid disks (/dev/sdb, sdc, sdd, sde) I used:
dd if=/dev/sdf of=/dev/sdb bs=512 conv=noerror,sync count=10485760
Here is the result of mounting and trying to access the raid volume:
root@ubuntu:~# pvscan
PV /dev/sdb5 VG c lvm2 [696.41 GiB / 0 free] PV /dev/sdc5 VG c lvm2 [696.41 GiB / 0 free] PV /dev/sdd5 VG c lvm2 [696.41 GiB / 5.00 GiB free] Total: 3 [2.04 TiB] / in use: 3 [2.04 TiB] / in no VG: 0 [0 ]
root@ubuntu:~# vgscan
Reading all physical volumes. This may take a while... Found volume group "c" using metadata type lvm2
root@ubuntu:~# vgchange -a y c
1 logical volume(s) in volume group "c" now active
root@ubuntu:~# lvscan
ACTIVE '/dev/c/c' [2.04 TiB] inherit
root@ubuntu:~# fuseext2 -o ro /dev/c/c /mnt root@ubuntu:~# cd /mnt root@ubuntu:/mnt# ls -lasc ls: cannot access backup: Input/output error ls: cannot access media: Input/output error ls: cannot access home: Input/output error ls: cannot access .timemachine: Input/output error ls: cannot access testshare: Input/output error total 68 16 drwxrwxrwx 8 root root 16384 2011-11-02 15:24 . 4 drwxr-xr-x 22 root root 4096 2011-11-02 20:40 .. 16 -rw——- 1 root root 7168 2011-11-02 15:28 aquota.group 16 -rw——- 1 root root 7168 2011-11-02 15:28 aquota.user ? -????????? ? ? ? ? ? backup ? -????????? ? ? ? ? ? home 16 drwx—— 2 root root 16384 2011-11-01 19:57 lost+found ? -????????? ? ? ? ? ? media ? -????????? ? ? ? ? ? testshare ? -????????? ? ? ? ? ? .timemachine root@ubuntu:/mnt#
So close! :shock: What am I missing here? (habria que usar al menos 10gb de disco, 5 gb de dd es muy poco)
Simple step by step guide to mounting Sparc-based ReadyNAS Drives in x86-based Linux:
Tested on brand new install of Ubuntu 10.10 (32bit x86), no other dependencies- 23rd Jan 2011
In a terminal window:
(1) sudo su (2) apt-get install fuseext2 (3) apt-get install lvm2 (4) modprobe fuse (5) vgscan (6) vgchange -ay c (7) fuseext2 -o ro -o sync_read /dev/c/c /mnt
That's it!!! You can now see the mounted files in the /mnt directory