Mounting disk images with multiple partitions

February 1st, 2011 ntavares Posted in en_US, filesystems, hardware No Comments »

Ouvir com webReader

This is a common scenario: you made a disk image from a disk which wanted to wipe out, but when you finally arrange some time to do proper backup (you're probably not interested in backing up your /tmp, for instance), you don't even remeber what's on it.

First of all, you'll need to know the disk's partition layout:

  1. [root@machine backup_disks]# parted disco2
  2. GNU Parted 1.8.6
  3. Using /array/backup_disks/disco2
  4. Welcome to GNU Parted! Type 'help' to view a list of commands.
  5. (parted) unit                                                             
  6. Unit?  [compact]? B                                                       
  7. (parted) print                                                           
  8. Model:  (file)
  9. Disk /array/backup_disks/disco2: 80060424192B
  10. Sector size (logical/physical): 512B/512B
  11. Partition Table: msdos
  13. Number  Start       End           Size          Type     File system  Flags
  14.  1      32256B      106928639B    106896384B    primary  ext3         boot
  15.  2      106928640B  80056650239B  79949721600B  primary               lvm 
  17. (parted) quit

I prefer 'parted' as it handles partition tables on files better than fdisk, but I suppose you could use 'fdisk -l' as well (ignoring the warnings and errors).

The easiest way (although not the quickest) is to simple 'dd' from it, using seek/skip counters, according to the partition table.

The following is the quickest approach: you can just mount simple partitions, like "boot" in the above example with:

  1. [root@machine backup_disks]# mkdir mymount
  2. [root@machine backup_disks]# mount -o loop,seek=32256,ro disco2 mymount

But, in the case of LVM, you need to scan and join it to the LVM pool you probably already have (refer to the LVM howto, for more information). This is due to LVM not being a filesystem (which could be mounted) but rather a partition type, in this case. So, first of all, you'll want to "export" that partition as a block device, so it can be analyzed by the LVM tools. You can do that with the loopback tools:

  1. [root@machine backup_disks]# losetup -o 106928640 /dev/loop1 disco2

You should be able to access the raw partition at /dev/loop1 and, thus, it's now visible to 'pvscan':

  1. [root@machine backup_disks]# pvscan
  2.   PV /dev/loop1   VG VolGroup00   lvm2 [74,44 GB / 32,00 MB free]
  3.   PV /dev/md0     VG VolGroup00   lvm2 [3,18 TB / 64,00 MB free]

This is also another common situation, due to distribution defaults: you mounted a disk that shares the Volume Group name with the running disks. It's better to rename it ASAP, before confusion happens:

  1. [root@machine backup_disks]# vgdisplay
  2.   --- Volume group ---
  3.   VG Name               VolGroup00
  4.   System ID             
  5.   Format                lvm2
  6.   Metadata Areas        1
  7.   Metadata Sequence No  3
  8.   VG Access             read/write
  9.   VG Status             resizable
  10.   MAX LV                0
  11.   Cur LV                2
  12.   Open LV               1
  13.   Max PV                0
  14.   Cur PV                1
  15.   Act PV                1
  16.   VG Size               74,44 GB
  17.   PE Size               32,00 MB
  18.   Total PE              2382
  19.   Alloc PE / Size       2381 / 74,41 GB
  20.   Free  PE / Size       1 / 32,00 MB
  21.   VG UUID               4BAKDW-94eP-0ZjE-aa7n-Efab-gu0m-5NF0GX
  23.   --- Volume group ---
  24.   VG Name               VolGroup00
  25.   System ID             
  26.   Format                lvm2
  27.   Metadata Areas        1
  28.   Metadata Sequence No  2
  29.   VG Access             read/write
  30.   VG Status             resizable
  31.   MAX LV                0
  32.   Cur LV                1
  33.   Open LV               1
  34.   Max PV                0
  35.   Cur PV                1
  36.   Act PV                1
  37.   VG Size               3,18 TB
  38.   PE Size               64,00 MB
  39.   Total PE              52165
  40.   Alloc PE / Size       52164 / 3,18 TB
  41.   Free  PE / Size       1 / 64,00 MB
  42.   VG UUID               9xAyLn-5jex-Bc00-0zmG-CPA0-x9Sx-3M3eio

Check the ID of the new volume (in this case: 4BAKDW-94eP-0ZjE-aa7n-Efab-gu0m-5NF0GX) and use vgrename to do so:

  1. [root@machine backup_disks]# vgrename 4BAKDW-94eP-0ZjE-aa7n-Efab-gu0m-5NF0GX VolGroup00_oldmachine
  2.   Volume group "VolGroup00" successfully renamed to "VolGroup00_oldmachine"

Check everything went well, again with pvscan:

  1. [root@machine backup_disks]# pvscan
  2.   PV /dev/loop1   VG VolGroup00_oldmachine   lvm2 [74,44 GB / 32,00 MB free]
  3.   PV /dev/md0     VG VolGroup00           lvm2 [3,18 TB / 64,00 MB free]
  4.   Total: 2 [1,26 TB] / in use: 2 [1,26 TB] / in no VG: 0 [0   ]

There you go! Now you should be able to follow standard LVM approaches to mount the volume.

AddThis Social Bookmark Button

Sobre o ZFS

July 11th, 2009 ntavares Posted in filesystems, pt_PT, solaris No Comments »

Ouvir com webReader

Tão cedo comecei a experimentar e a afinar o parzinho sensação (ZFS and MySQL), fui logo procurar se já alguém tinha começado alguma implementação de ZFS em/para Linux [tal e qual o que aconteceu com o DTrace, mas com menos sorte!] e adivinhem! Existe uma, e é feita por um camarada português, Ricardo Correia. Ao que parece, o projecto começou patrocinado pelo Google Summer of Code de 2006. Vejam os sites para mais informações:

Entretanto, cruzei-me com esta demonstração surreal do ZFS (ainda estou a tentar perceber como embebê-la neste post)...

AddThis Social Bookmark Button