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:
[code]
[root@machine backup_disks]# parted disco2
GNU Parted 1.8.6
Using /array/backup_disks/disco2
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit
Unit? [compact]? B
(parted) print
Model: (file)
Disk /array/backup_disks/disco2: 80060424192B
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 32256B 106928639B 106896384B primary ext3 boot
2 106928640B 80056650239B 79949721600B primary lvm
(parted) quit
[/code]
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:
[code]
[root@machine backup_disks]# mkdir mymount
[root@machine backup_disks]# mount -o loop,seek=32256,ro disco2 mymount
[/code]
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:
[code]
[root@machine backup_disks]# losetup -o 106928640 /dev/loop1 disco2
[/code]
You should be able to access the raw partition at /dev/loop1 and, thus, it's now visible to 'pvscan':
[code]
[root@machine backup_disks]# pvscan
PV /dev/loop1 VG VolGroup00 lvm2 [74,44 GB / 32,00 MB free]
PV /dev/md0 VG VolGroup00 lvm2 [3,18 TB / 64,00 MB free]
[/code]
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:
[code]
[root@machine backup_disks]# vgdisplay
--- Volume group ---
VG Name VolGroup00
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 3
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 1
Max PV 0
Cur PV 1
Act PV 1
VG Size 74,44 GB
PE Size 32,00 MB
Total PE 2382
Alloc PE / Size 2381 / 74,41 GB
Free PE / Size 1 / 32,00 MB
VG UUID 4BAKDW-94eP-0ZjE-aa7n-Efab-gu0m-5NF0GX
--- Volume group ---
VG Name VolGroup00
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 2
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 1
Act PV 1
VG Size 3,18 TB
PE Size 64,00 MB
Total PE 52165
Alloc PE / Size 52164 / 3,18 TB
Free PE / Size 1 / 64,00 MB
VG UUID 9xAyLn-5jex-Bc00-0zmG-CPA0-x9Sx-3M3eio
[/code]
Check the ID of the new volume (in this case: 4BAKDW-94eP-0ZjE-aa7n-Efab-gu0m-5NF0GX) and use vgrename to do so:
[code]
[root@machine backup_disks]# vgrename 4BAKDW-94eP-0ZjE-aa7n-Efab-gu0m-5NF0GX VolGroup00_oldmachine
Volume group "VolGroup00" successfully renamed to "VolGroup00_oldmachine"
[/code]
Check everything went well, again with pvscan:
[code]
[root@machine backup_disks]# pvscan
PV /dev/loop1 VG VolGroup00_oldmachine lvm2 [74,44 GB / 32,00 MB free]
PV /dev/md0 VG VolGroup00 lvm2 [3,18 TB / 64,00 MB free]
Total: 2 [1,26 TB] / in use: 2 [1,26 TB] / in no VG: 0 [0 ]
[/code]
There you go! Now you should be able to follow standard LVM approaches to mount the volume.
