Is it possible to mount a gzip compressed dd image on the fly?

Question

I like to create an image backup the first time I'm backing up a system. After this first time I use rsync to do incremental backups.

My usual image backup is as follows:

• Mount and zero out the empty space:

  dd if=/dev/zero of=temp.dd bs=1M
  rm temp.dd
  

• Umount and dd the drive while compressing it

  dd if=/dev/hda conv=sync,noerror bs=64K | gzip -c  > /mnt/sda1/hda.ddimg.gz
  

• To put the system back to normal, I will usually do a

  gzip -dc /mnt/sda1/hda.img.gz | dd of=/dev/hda conv=sync,noerror bs=64K
  

This is really straightforward and allows me to save the 'whole drive' but really just save the used space.

Here is the problem. Lets say I do the above but not on a clean system and don't get the rsync backups going soon enough and there are files that I want to access that are on the image. Let's say I don't have the storage space to actually unzip and dd the image to a drive but want to mount the image to get individual files off of it.... Is this possible?

Normally, one wouldn't compress the dd image, which will allow you to just mount the image using -o loop... but this isn't my case...

Any suggestions for mounting the compressed img on the fly?

Would using AVFS to 'mount' the gz file then mounting the internal dd.img work (I don't think so... but would need verification...)?

Answer 1

It depends on whether the disk image is a full disk image or just a partition.

Washing the partition(s)

If the disk is in good working condition, you will get better compression if you wash the empty space on the disk with zeros. If the disk is failing, skip this step.

If you're imaging an entire disk, then you will want to wash each of the partitions on the disk.

CAUTION: Be careful, you want to set the of to a file in the mounted partition, NOT THE PARTITION ITSELF!

mkdir image_source
sudo mount /dev/sda1 image_source
dd if=/dev/zero of=image_source/wash.tmp bs=4M
rm image_source/wash.tmp
sudo umount image_source

Making a Partition Image

mkdir image
sudo dd if=/dev/sda1 of=image/sda1_backup.img bs=4M

Where sda is the name of the device, and 1 is the partition number. Adjust accordingly for your system if you want to image a different device or partition.

Making a Whole Disk Image

mkdir image
sudo dd if=/dev/sda of=image/sda_backup.img bs=4M

Where sda is the name of the device. Adjust accordingly for your system if you want to image a different device.

Compression

Make a "squashfs" image that contains the full, uncompressed image.

sudo apt-get install squashfs-tools
mksquashfs image squash.img

Streaming Compression

To avoid making a separate temporary file the full size of the disk, you can stream into a squashfs image.

mkdir empty-dir
mksquashfs empty-dir squash.img -p 'sda_backup.img f 444 root root dd if=/dev/sda bs=4M'

Mounting a compressed partition image

• First mount the squashfs image, then mount the partition image stored in the mounted squashfs image.

  mkdir squash_mount
  sudo mount squash.img squash_mount
  

• Now you have the compressed image mounted, mount the image itself (that is inside the squashfs image)

  mkdir compressed_image
  sudo mount squash_mount/sda1_backup.img compressed_image
  

• Now your image is mounted under compressed_image.

EDIT: If you wanted to simply restore the disk image onto a partition at this point (instead of mounting it to browse/read the contents), just dd the image at squash_mount/sda1_backup.img onto the destination instead of doing mount.

Mounting a compressed full disk image

This requires you to use a package called kpartx. kpartx allows you to mount individual partitions in a full disk image.

sudo apt-get install kpartx

• First, mount your squashed partition that contains the full disk image

  mkdir compressed_image
  sudo mount squash.img compressed_image
  

• Now you need to create devices for each of the partitions in the full disk image:

  sudo kpartx -a compressed_image/sda_backup.img
  

  This will create devices for the partitions in the full disk image at /dev/mapper/loopNpP, where N is the number assigned for the loopback device, and P is the partition number, e.g., /dev/mapper/loop0p1.  You can find this number N in the output of losetup --list.  The most recently created loopback device should have the largest N number.

• Now you have a way to mount the individual partitions in the full disk image:

  mkdir fulldisk_part1
  sudo mount /dev/mapper/loop0p1 fulldisk_part1
  

Answer 2

Try archivemount

root@srv1:/backup# archivemount windows-2003-S.gz /target/
Unrecognized archive format

root@srv1:/backup# archivemount -o formatraw windows-2003-S.gz /target/
Calculating uncompressed file size. Please wait.

root@srv1:/backup# ls /target/
data

root@srv1:/backup# file /target/data
/target/data: DOS/MBR boot sector; partition 1 : ID=0x7, start-CHS (0x0,1,1), end-CHS (0x3ff,254,63), startsector 63, 58717512 sectors, extended partition table (last)

archivemount is a FUSE-based file system for Unix variants, including Linux. Its purpose is to mount archives (i.e. tar, tar.gz, etc.) to a mount point where it can be read from or written to as with any other file system. This makes accessing the contents of the archive, which may be compressed, transparent to other programs, without decompressing them.

http://linuxaria.com/howto/how-to-mounts-an-archive-for-access-as-a-file-system

After mounting archive you can use it contents like regular file. Maybe get partition table, or convert, mount image with qemu tools.

squashfs useful for booting from image, but much complex for backuping.

Answer 3

If the image is read-only you can also use nbdkit (man page) and its xz filter (xz should provide better compression and random access times than gzip). If you need temporarily write access, the cow (Copy On Write) filter might be useful.

Create the compressed partition image

dd if=/dev/sda1 bs=16M | xz -9 --block-size=16MiB > sda1.img.xz

A --block-size option of 16 MiB should provide good random access performance.

Note: you may use alternative xz compression programs such as pixz which provides parallel compression, just make sure it splits the output in multiple small blocks, otherwise nbdkit has to decompress a lot of data. For example as of September 2015, pxz does not support this.

Serve it with nbdkit

nbdkit --no-fork --user nobody --group nobody -i 127.0.0.1 \
       --filter xz file sda1.img.xz

Connect to the NBD server

nbd-client 127.0.0.1 10809 /dev/nbd0 -nofork

Mount it read-only

mount -o ro /dev/nbd0 sda1

When done

umount /dev/nbd0
nbd-client -d /dev/nbd0

Stop the nbdkit server by pressing Ctrl+C (or with kill).

Answer 4

This answer complements Cristian Ciupitu's answer. If you use xz compression with a reasonable block size, you can access the disk image using guestfish or other libguestfs tools like this:

nbdkit xz file=disk.img.xz --run 'guestfish --format=raw -a $nbd -i'

UPDATE: Since xz is not a plugin anymore, but has become a filter, the command is now:

nbdkit file disk.img.xz --filter xz --run 'guestfish --format=raw -a $nbd -i'

Answer 5

Not really. You can't really seek to a specific block in the compressed file without decompressing the whole thing first, which makes it difficult to use the compressed image as a block device.

You could use something like dump and restore (or tar, really), all of which use a streaming format...so you can access invidividual files by effectively scanning through the uncompressed stream. It means if the file you want is at the end of the compressed archive you may have a long time to wait, but it doesn't require you to actually decompress everything onto disk.

Using tar for backups may seem a bit old fashioned, but you get a lot of flexability.

Answer 6

Another addendum to Cristian Ciupitu's answer:

If you use nbdkit to mount a full disk image (vs. a partition image), you might need to specify the block size (sector size of the disk) when connecting to the NBD server, as it defaults to 1024 bytes. To use 512 bytes instead:

nbd-client 127.0.0.1 /dev/nbd0 -b 512 -n

After that, the disk will appear as /dev/nbd0, and you should be able to view the partition table using fdisk -l. However, the partitions are not yet mountable - Use kpartx (from doug65536's answer) to create devices for the partitions, e.g.:

kpartx -arv /dev/nbd0

Finally, the partitions will appear in /dev/mapper/, and you can mount them as usual. Make sure to use readonly mode (-o ro), as the xz plugin only supports reads:

mount -o ro /dev/mapper/nbd0p3 /mnt

Answer 7

Yes, AVFS would work.

First you create a "portal" over your filesystem where all operations performed on your files are intercepted through the AVFS FUSE system:

~ $ mkdir avfs                # the AVFS mount-point
~ $ avfsd -o allow_root avfs  # Needs `user_allow_other` option in /etc/fuse.conf
~ $ cd avfs
~/avfs $ ls  # your root filesystem listed

Then attach a loopback device with partition table on the transparently uncompressed disk-image located in the ~/avfs mount-point:

ℹ️ Note: the # character suffix is not a comment but part of the AVFS-syntax that uncompresses the file.

~/avfs $ sudo losetup -Pf ./absolute/path/to/full-disk.img.gz#
/dev/loop0

The command above selected and printed the first unused loop-device.

The kernel has now created additional loop-devices for all the partitions contained in the full-disk.img.gz. You can mount them the usual way:

$ sudo mount /dev/loop0p1 /some/mount/point/