Recovering files from a Ghost 4 Linux/Unix bzipped image (G4U/G4L)

Recently a colleague of mine used G4L to backup his disk. G4L is nice and handy if you want to backup an entire disk in zipped (bz2) format and ship it off to an ftp server for backup. We now needed to recover some files off that backup. The issue is all of our machines are identical, and since the backup was a lowlevel image of the entire disk, unzipping the img would not be possible. This post describes the steps I took to manage to mount partitions out of the bzipped image.

Doing some research, it became apparent that G4L uses Gnu DD behind the scenes to create the disk image. Basically G4L is a wrapper around dd to make it easier to perform networked backups. This was great as it meant that I did not have to deal with proprietery or weird formats.

As mentioned, unzipping the img first was not an option, this is because the image required the entire disk to expand into. Using G4L to recover the partition was also not an option as we needed a free machine to push the image onto. After googling a bit, I managed to find AVFS (A Virtual File System). AVFS makes it easy to deal with all kinds of archives and network drives. In this situation I needed its bz2 support. I installed the fuse module for avfs and started it as root, this was required such that I can use the mount command while being able to use the avfs fuse filesystem.

To not keep typing for ages, I will conclude by showing the commands that were required to mount the device and I will display a few output messages from these commands as well.

assuming the following setup

export zipimg=/media/backup/arcimg.bz2export mntloc=/media/backup/mnt
Setting up avfs
mkdir ~/.avfs # needed by avfs mountavfs # mounts the avfs virtual filesystem mounting the partitions fdisk -ul ~/.avfs${zipimg}# note that the first time you run this command will be slow (if the file is big enough) as avfs has to do its magic on the zipped file.
The output will be something like
last_lba(): I don't know how to handle files with mode 81a4 You must set cylinders. You can do this from the extra functions menu. Disk /root/.avfs/media/backup/arcimgbz2#: 0 MB, 0 bytes 255 heads, 63 sectors/track, 0 cylinders, total 0 sectors Units = sectors of 1 * 512 = 512 bytes                                                            Device Boot      Start         End      Blocks   Id  System /root/.avfs/media/backup/arcimg.bz2#1   *          63      401624      200781   fd  Linux raid autodetect /root/.avfs/media/backup/arcimg.bz2#2          401625      803249      200812+  fd  Linux raid autodetect /root/.avfs/media/backup/arcimg.bz2#3          803250     4723109     1959930   82  Linux swap / Solaris /root/.avfs/media/backup/arcimg.bz2#4         4723110   976768064   486022477+   5  Extended Partition 4 has different physical/logical endings:      phys=(1023, 254, 63) logical=(60800, 254, 63) /root/.avfs/media/backup/arcimgbz2#5         4723173    24274214     9775521   fd  Linux raid autodetect /root/.avfs/media/backup/arcimgbz2#6        24274278    43825319     9775521   fd  Linux raid autodetect /root/.avfs/media/backup/arcimgbz2#7        43825383    82911464    19543041   fd  Linux raid autodetect /root/.avfs/media/backup/arcimgbz2#8        82911528   976768064   446928268+  fd  Linux raid autodetect
YES you guessed it, it was a raid setup. I was interested in the home partition which I found out was the last one START=82911528. To mount it you need to calc 82911528 * 512 = 42450702336
mount -t ext3 -ro loop,offset=42450702336 ~/.avfs${zipimg}# ${mntloc}
OK so you also need to know the filesystem type, in this case it was ext3, the -r flag means it is mounted as a read only filesystem.

Many things fell into place for me to get to this point, without God’s grace I would have given up early.