Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Despite a lot of Googling I couldn't find an answer to my problem.

I'm a Linux sysadmin and I want to backup a Windows XP installation (but it could be any other OS) located on the first partition of a 160 GB hard disk (which I have shrinked to its minimum size, about 4.8 GB), and the MBR, in the same file. The goal is to have a single disk image that I could use to overwrite a new hard disk (ex. dd if=/my/file.img of=/dev/sda) and use gparted to grow the partition to the new disk's full size afterwards, thus having an image as easy to use as the hybrid disk images Debian or Ubuntu release for their live systems (which you can write directly to USB sticks with dd, but I only want to use them on plain hard disks).

I already know how to backup/restore the MBR or a single partition with dd, but now I'd like to backup both in a single file.

I didn't try anything yet, but I thought of two methods :

  1. Concatenate (with cat, for example) both the MBR and the partition image files into a single image file, but I'm not sure there's nothing between them in the original disk.

  2. Use dd's "count" option to backup the hard disk until the end of the first partition, but then, I don't know how to calculate the correct size to end the copy at. Maybe the number of bytes copied when backing up the partition (which dd outputs when it has completed) with 512 bytes added for the MBR, but again, I don't know hard disks data structures deeply enough to be sure that there's not some data between them that I should add to the total.

Backing up the entire disk to a sparse or compressed file is not an option, since I'd like to be able to use this image on a disk smaller than the original one (but larger than the shrinked partition, of course).

Any advice would be appreciated, either a confirmation that the first method would (or wouldn't) work, a way to calculate the correct number for the 2nd method, or a completely different method to reach this goal, the only limitation being that, as a Linux user, I'd prefer a method using only basic software available on most Linux distributions, like dd or cat.

share|improve this question
up vote 1 down vote accepted

Your option #2 should work. For instance, if fdisk or parted shows that the Windows partition ends at sector 9,375,000, you could do:

dd if=/dev/sda of=/path/to/winxp.img bs=512 count=9375001

(Note the addition of 1 to the count value, since sectors are numbered starting with 0.) To copy this image to another disk, you'd do the reverse, and you can omit the count and bs options (although setting a higher bs value may improve performance; my example sets it to 4096, which is the physical sector size on new Advanced Format disks):

dd if=/path/to/winxp.img of=/dev/sdb bs=4096

The copy will terminate at the end of the file. As long as the disk has at least 9,375,001 sectors, everything should work. On a BIOS-based computer, the boot loader resides in the Master Boot Record (MBR; the first sector of the disk). Sometimes additional code (such as for GRUB or some types of disk-encryption software) goes in the sectors in-between the MBR and the beginning of the first partition. All of those sectors will exist in the backup file. Although it's theoretically possible for some software to store data outside of the partitions at the very end of the disk, this practice is uncommon. In fact, I don't know of anything that does this, at least not on a BIOS/MBR computer. (The newer GUID Partition Table, or GPT, partitioning system does store a backup of the partition table at the end of the disk. Thus, if you wanted to back up a GPT disk, you'd need to either do something more complex or perform a partition table repair operation after restoring the backup.)

Note that all of this ignores the fact that Windows installations tend to be highly machine-specific. If you move the installation to a new computer, the drivers probably won't match, and at best you'll have to reboot half a dozen or a dozen times while Windows updates them all. At worst this process might fail. There are also issues of the Windows serial number.

share|improve this answer
I would just like to second the last paragraph. Windows installations tend to not do good when moving between different hardware. MS includes a special 'sysprep /oobe /generalize' command that will remove system specific info from the install (activation keys, etc.) but even this is not really going to make moving between different hardware an easy experience. Thus this may be a fatal flaw in accomplishing what the OP wants to do. – Atari911 Nov 25 '13 at 18:41
So if I understand correctly, the basic "formula" is : run fdisk, switch display units to sectors, note the number where the partition ends, add 1, and use that as the "count" number for dd, the block size being 512 ? – MoonSweep Nov 25 '13 at 18:47
As a side note, I'm aware of the fact that a Windows installation would likely not work on different hardware, but I already successfully used sysprep on Windows XP at work before, to clone identical machines and changing activation key, domain SSID, etc etc at first boot time. I know this kind of disk images will have to be at least model-specific, so I'm aware of the issue. But thanks anyway for the warning :) – MoonSweep Nov 25 '13 at 19:02
The fdisk option you need to show sectors instead of cylinders is -u. – Cocoabean Jun 30 '15 at 23:20

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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