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

i have a SSD device as primary sata hard drive witch contains my os. On this device i have Windows and Linux Mint installed. Now i want to make an image of my windows installation so that i can restore the image if something fails. The hard disk uses a GPT Partion Scheme and following Partitions exist (on sda):

  1. EFI Partition
  2. Windows 7 (ms-tree) no idea where this is for
  3. Windows 7 (ntfs) system drive c:
  4. \boot (ext2) for linux mint
  5. \ (ext4) system Partion for linux mint

First of all it would be Nice to know witch Partitions are the minimum i have to back up to restore my running windows. Is it just Partion Number 3 with the ntfs file system or do i also need to include the ms-tree partition? When i don't have a backup of the EFI Partition im be able to create a new one and reinstall the windows boot manager using bcedit form the install disk of windows 7 or?

My Second Question is when i make a backup of the requiered Partions, lets say with

dd if=/dev/sda1 conv=sync,noerror bs=64K | gzip > ~/image-compress_sda1.img.gz

and now my Hard disk crashed and i want to recover on a new one witch i created a gpt partion tabel and a Partion like /dev/sdb2 can i recover my windows using

gzip -dc ~/image-compress_sda1.img.gz | sudo dd of=/dev/sda1 bs=64K

or does this cause Problems with the GPT Partition table? Is there a way to recreate the same Partition scheme a had on my old disc execpt the 4 and 5 partions witch are linux specific? And what happend when the partition is too small does dd just crash?

And my last Question is can i easily mount a img.gz file of an ntfs partion in linux?

share|improve this question
up vote 1 down vote accepted

The EFI System Partition (ESP; your first partition) holds EFI boot loaders, so you must back it up. If you fail to do so, you won't be able to boot when you restore your OS partitions. A file-level backup (using tar, cp, or the like) is adequate for this, and in fact that's likely to be more efficient than a dd backup. A file-level backup will also make it easier to restore to an ESP that's a different size from the original -- dd creates an incomplete filesystem when restoring to a smaller device than the original, and so should never be used for that case. OTOH, a dd backup will preserve the filesystem's serial number, which Linux generally uses in /etc/fstab. If you do a file-level backup, you'll need to adjust /etc/fstab when you create a fresh filesystem and restore the files.

I've never before heard of "ms-tree" as a partition or filesystem type. In a standard Windows EFI installation, though, there is a Microsoft Reserved Partition, which is basically just empty space that Windows partitioning software can use as "scratch space" in future operations. AFAIK, it doesn't contain any long-term data, and so can be omitted from backups; however, if you want to be extra safe, you could do a dd backup of it.

Your third partition (your Windows C: drive) is obviously critical. I recommend either using a Windows backup tool to handle it or use ntfsclone in Linux. I don't recall if it's possible to restore to a smaller partition than the original when using ntfsclone, but I'm pretty sure it is possible to restore to a larger partition. The ntfsclone documentation says that a restored partition won't be bootable, but this is true only on BIOS-based computers; on an EFI system, an ntfsclone-created image should boot fine, provided the boot loader on the ESP is restored properly. (There may be issues with the partition table, though; I've never tested with restoring to a new disk.) Check the documentation for the Windows software if you use that option for backing up Windows.

Broadly speaking, restoring to a partition won't cause partition table issues -- that is, if you restore to /dev/sda1 (or whatever), the partition table won't be affected. The partition table is stored outside of any given partition, so to damage the partition table you'd need to abuse partitioning software (gdisk, parted, GParted, etc.) or write to the whole-disk device (/dev/sda). As just alluded to, though, software may refer to partitions by their GUID values, which are stored in the partition table. You can identify and change your partitions' GUID values with gdisk or sgdisk, as in:

sudo sgdisk -i 1 /dev/sda
Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI System)
Partition unique GUID: 2C47C282-EE6E-45DE-A5AD-E8658CA67DE6
First sector: 2048 (at 1024.0 KiB)
Last sector: 390625 (at 190.7 MiB)
Partition size: 388578 sectors (189.7 MiB)
Attribute flags: 1000000000000000
Partition name: 'EFI System'

This example shows the partition is an ESP (on the Partition GUID code line) and that it has a GUID value of 2C47C282-EE6E-45DE-A5AD-E8658CA67DE6 (on the Partition unique GUID line). If you needed to replicate this data on another disk, you'd use the -u option to sgdisk, as in:

sudo sgdisk -u 1:2C47C282-EE6E-45DE-A5AD-E8658CA67DE6 /dev/sda

This sets the unique GUID for partition 1 to 2C47C282-EE6E-45DE-A5AD-E8658CA67DE6. There are other ways to do this, too; consult the gdisk and sgdisk man pages for details. I'd like to emphasize that this might not be necessary, though. What's more, replicating GUIDs unnecessarily can cause problems, particularly if the original and new disks will be used together in the same computer. That's because these values are supposed to be unique, so if two partitions have the same GUID, some software's assumptions may be violated. The main reason you'd want to do this is if a boot loader or some other tool refers to partitions by their GUID values (also called the PARTUUID in some Linux tools). In that case, replicating the GUID values will let the software work without reconfiguration -- but adjusting the software's configuration will also work. The trouble is that how to reconfigure the software depends on the software.

share|improve this answer

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.