I'd like to backup my current Debian 9 server OS partition so I can install a clean version of Debian 10.

However, after installing Debian 10, I'd like to mount my old OS image so I can browse and restore files as needed.

I thought I would use CloneZilla but apparently you can't directly mount the images that it creates?

  • is debootstrap an option? if you're happy with your current filesystem layout and enough free space available, you could get away without deleting/formatting anything (debootstrap to subdir, then switch) – frostschutz Sep 12 '19 at 13:55

As root, just cat the partition to another partition: cat /dev/sdXn > /dev/sdYi

or to a file: cat /dev/sdXn > backup.img

Or to a file or partition on another machine: cat /dev/sdXn | ssh user@host 'cat > backup.img'

You could use dd instead of cat, but there's no good reason to do so:

dd if=/dev/sdXn of=backup.img

Or if you want a progress bar while it's copying and/or control over how much buffering is used during the copy, you could use pv:

pv /dev/sdXn > backup.img

If the partition has read-errors, you might want to use ddrescue instead of cat:

ddrescue /dev/sdXn /dev/sdYi


ddrescue /dev/sdXn backup.img

ddrescue won't write to stdout (or read from stdin, either), so if you want that backup.img on another machine, you'll have to copy it (e.g. with scp) afterwards, or write it to an NFS mount.

Or, as mentioned by user1133275 in a comment, you could use process substitution:

ddrescue /dev/sdXn >(ssh user@host 'cat > backup.img')

Finally, if you want a compressed, mountable filesystem you could use qemu-img:

qemu-img convert -c -O qcow2 /dev/sdXn backup.qcow2

To mount it:

qemu-nbd --connect=/dev/nbd0 /path/to/backup.qcow2
mount /dev/nbd0 /mnt

Both qemu-img and qemu-nbd are in the qemu-utils package. BTW, if you took an image of the entire disk rather than just a partition, you could run your old system as a VM in your new system.

Another alternative is just to install a second disk and install the Debian 10 on that. Then you can just mount the old drive somewhere on the new system. Or even dual-boot between Debian 9 and Debian 10.

Personally, I would recommend a file copy (e.g. with tar or rsync or even cp -a) rather than an image backup. It's more useful, can be extracted easily to anywhere you want, and doesn't waste space or time copying empty or unused sectors.

image backup are (almost always) the worst way to backup a filesystem.

|improve this answer|||||
  • Thanks so much! It looks like there are a bunch of options. I asked in the above comment as well, but I'll also ask here: Is it possible to compress the image but still be able to mount it without having to extract/decompress it first? – SofaKng Sep 12 '19 at 13:53
  • Not unless the image file is on a filesystem that supports transparent compression - e.g. btrfs or ZFS. – cas Sep 12 '19 at 13:54
  • on second thoughts, you could probably convert the raw disk image to a .qcow2 image (which are often used for VMs). or a squashfs (often used for live CDs). both of those support compression, and can be mounted. – cas Sep 12 '19 at 13:58
  • 1
    ddrescue /dev/sdXn >(ssh user@host 'cat > backup.img') – user1133275 Sep 12 '19 at 14:11
  • yep, process subst. would work. – cas Sep 12 '19 at 14:13

e2image can be used to create an image of an ext4 file system, while only copying sectors which are in use:

e2image -ra /dev/sda1 /path/to/file.img

file.img will be created as a sparse file, so it will only occupy the space which is really used in the file system, even though its apparent size will reflect the capacity of the file system.

You can also use e2image to produce a QCOW2 image:

e2image -Qa /dev/sda1 /path/to/file.qcow2

This will produce a compact file which can still be mounted.

Both images can be compressed, although that results in a file which can’t be mounted directly.

|improve this answer|||||
  • nice, i wasn't aware of e2image. – cas Sep 12 '19 at 14:12

having your ext4 partition mounted as /whatever

mkisofs -o    /somehwere_else/whatever.iso    /whatever

now you have a however large whatever.iso. You will obviously have to be mindful of disk space for where you move it around to.

to access that iso you would simply do

mount -o loop /somewhere/whatever.iso   /anywhereyoulike/mywhateveriso/

everything that was under your folder /whatever would now be accessible read-only under /anywhwereyoulike/mywhateveriso/

The fact that you have an ext4 partition is almost irrelevant, because you will be dumping that data into a container which will be in a different filesystem format. So whether it was data in an ext4 or xfs or btrfs partition does not matter because at that point you already have linux kernel filesystem support to access it in the first place.

Once you have your data in that iso container via mkisofs which is pretty universal, that data can now be accessed from nearly anywhere because isofs is universal... if your computer can read a cd/dvd [iso9660/udf] then you'll be able to access your whatever.iso. Doing a .iso will make it very portable.

using cat or tar or dd will preserve the file system which may be problematic

|improve this answer|||||

Not the answer you're looking for? Browse other questions tagged or ask your own question.