7

I am using dd to create an image of my boot partition on Ubuntu 14.04. This is my first time doing this.

In checking the usage on my disk, I used df -h. You will see that my /dev/sda1 partition is 5.8G in size...

bash$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       220G  5.8G  203G   3% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            3.9G  4.0K  3.9G   1% /dev
tmpfs           797M  976K  796M   1% /run
none            5.0M     0  5.0M   0% /run/lock
none            3.9G   30M  3.9G   1% /run/shm
none            100M   28K  100M   1% /run/user
/dev/sda5       239G   32K  239G   1% /windows

I tried to create in image and save it in /tmp with the following command:

bash$ sudo dd if=/dev/sda1 of=/tmp/ubuntu.image

It started creating an image in my /tmp dir, but as I checked on its progress, the image kept growing to well over 30G before I cancelled it.

This raises a few questions in my mind:

  • Why would the disk image be so large?
  • Is it going to equal the size of the partition?
  • Is there a way to keep the disk image to just the size of the actual space used?
  • Is there a better tool to use?
  • 1
    Actually, /dev/sda1 is 220GB with 5.8GB in use. I hope it's not the boot partition, and yes, dd copies sector by sector, so the final image will be the same size. Try fsarchiver instead. – mikewhatever Oct 14 '14 at 16:01

3 Answers3

9
/dev/sda1       220G  5.8G  203G   3% /

/dev/sda1 is 220 GB in size, and has 5.8 GB used. So:

  1. dd makes a byte-for-byte copy, so the total size of the partition matters, not what's in the partition.
  2. Yes. It will grow to 220 GB.
  3. You can compress the resulting image using gzip or xz:

    sudo dd if=/dev/sda1 | xz > /tmp/ubuntu.image
    
  4. Depends on what you call a better tool. For some tasks, a byte-for-byte copy is needed (say, data recovery from a failing disk). In such cases, dd + compression is the simplest way. If not, consider something like partimage .
muru
  • 197,895
  • 55
  • 485
  • 740
  • This is very helpful - thanks! Piping thru gzip will presumably compress all that empty space down to nothing, I assume. Thanks again. – andrewniesen Oct 14 '14 at 16:28
  • @andrewniesen hopefully, yes. I just piped 1 GB of /dev/zero to xz and came away with a file 144KB in size. – muru Oct 14 '14 at 16:30
  • 1
    well... I hope the OP is not really trying to copy a mounted partition in a file on the same partition... confusion will arise (at least). – Rmano Oct 14 '14 at 17:58
  • @Rmano true that (and +1). I hope its from a live or read-only mounted system, but even then, where is /tmp mounted to? – muru Oct 14 '14 at 18:10
4

Well... you have good answers about the size of the dd file (which if uncompressed is the same size of the partition).

But I see another problem here: you have:

bash$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       220G  5.8G  203G   3% /
[...]

... and /tmp is not mounted elsewhere, so it's on /dev/sda1, and /dev/sda1 is mounted.

So if you do:

 sudo dd if=/dev/sda1 of=/tmp/ubuntu.image 

you are copying an image of /dev/sda1 partition on a filesystem on the same partition --- which will cause:

  1. to fill the partition before the command will have a chance to finish (think about it), unless compressing on-the-fly and being lucky, but

  2. to record a file with a completely inconsistent copy of that partition; mounted partitions are changing all the time in a multitasking operating system.

As a rule of thumb, you dd a partition only when it is not mounted.

Moreover, given that the partition is the / partition of your system, and that you are executing the command as root, you will completely fill your root partition (root reserved space will be used up), and you risk to need to boot with a rescue disc to recovery the mess...

Rmano
  • 31,947
3

It's my understanding that dd makes an exact clone of the drive, including empty space. If your drive is 220GB, dd will make a copy that is 220GB, regardless of how much of that space is used.

This answer on ServerFault recommends piping through gzip which should be a pretty efficient way to compress the unused space.

dd if=/dev/sda1 | gzip -c  > /tmp/ubuntu.image

You may also wish to defragment first and write zeros to the empty space, both of which could theoretically make the compression more efficient.