Restoring disk images


HelenF

Very Active Member
Joined
Jun 22, 2013
Messages
615
Location
UK
I've been trying to restore some Windows 7 partitions from gzipped image files using a Fedora live USB, and the result is broken.

I restored the MBR earlier and the partitions look right. Used "partprobe" on the first try, but had rebooted before the second try. There should really have been a backup of the whole unallocated 1MiB at the start of the drive, but I imagine missing that would only break the bootloader, not the whole lot, right?

There appears to be something recognizable as NTFS in the partitions afterwards, so I guess I'm not doing completely the wrong thing.

The "No space left on device" is suspicious, but strangely, everything looks the right size, and the 64K blocks are an integer division...

"mount" told me to run chkdsk from Windows, so I booted a Windows DVD to try that, but it couldn't fix it.

I extracted the small one as a file on my main computer (also Fedora), and I can mount that with "loop" and view the contents, so seems like the NTFS in the image is OK.

Currently running badblocks on the target hard drive. So far, pattern 0xaa is OK, so apparently not a hard drive failure either.

Any idea what I've done wrong here and how to fix it?


Code:
[liveuser@localhost]$ gunzip -c sda1.img.gz | wc -c
1572864000

[liveuser@localhost]$ gunzip -c sda2.img.gz | wc -c
303817555968

[liveuser@localhost]$ gunzip -c sda3.img.gz | wc -c
14680064000

[liveuser@localhost]$ sudo fdisk -l /dev/sda
Disk /dev/sda: 298.1 GiB, 320072933376 bytes, 625142448 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x6479a0bb
Device     Boot     Start       End   Sectors  Size Id Type
/dev/sda1  *         2048   3074047   3072000  1.5G  7 HPFS/NTFS/exFAT
/dev/sda2         3074048 596467711 593393664  283G  7 HPFS/NTFS/exFAT
/dev/sda3       596467712 625139711  28672000 13.7G  7 HPFS/NTFS/exFAT

[root@localhost]# gunzip -c sda1.img.gz | dd of=/dev/sda1 conv=sync bs=64K
dd: error writing '/dev/sda1': No space left on device
780+23221 records in
24000+0 records out
1572864000 bytes (1.6 GB, 1.5 GiB) copied, 18.9797 s, 82.9 MB/s

[root@localhost]# gunzip -c sda2.img.gz | dd of=/dev/sda2 conv=sync bs=64K
dd: error writing '/dev/sda2': No space left on device
272833+4363056 records in
4635888+0 records out
303817555968 bytes (304 GB, 283 GiB) copied, 3152.46 s, 96.4 MB/s

[root@localhost]# gunzip -c sda3.img.gz | dd of=/dev/sda3 conv=sync bs=64K
dd: error writing '/dev/sda3': No space left on device
15757+208244 records in
224000+0 records out
14680064000 bytes (15 GB, 14 GiB) copied, 245.341 s, 59.8 MB/s

Code:
[root@localhost ~]# mount -t ntfs /dev/sda1 sda1
ntfs_mst_post_read_fixup_warn: magic: 0x44414142  size: 1024   usa_ofs: 1849  usa_count: 46218: Invalid argument
Record 0 has no FILE magic (0x44414142)
Failed to load $MFT: Input/output error
Failed to mount '/dev/sda1': Input/output error
NTFS is either inconsistent, or there is a hardware fault, or it's a
SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows
then reboot into Windows twice. The usage of the /f parameter is very
important! If the device is a SoftRAID/FakeRAID then first activate
it and mount a different device under the /dev/mapper/ directory, (e.g.
/dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation
for more details.

chkdsk.jpg
gparted.png
 
No idea if this is any help, but to boot a drive using the old MBR spec, you need an MBR in the drive boot block and a VBR in the boot sector of the booting partition. But it looks to me like your gzipped archives probably contain the VBR block on the booting drive. I am highly suspicious of that dd error you get though.
 
When it failed to boot the first time, I hoped it was only unbootable, but after further investigation it turned out to be much worse than that ;)
 
I think the "no space left" is ok, I've seen it before and it's harmless.

You should use the ntfs-3g instead of ntfs when mounting.

Check g4l scripts to see how it clone/restore. Maybe you'll get some hints.
G4l event has a special ntfsclone option.
 
OK, I'm using ntfs-3g now. ntfsclone is an option when making new backups. But if the backups already exist as gzipped dd images, whether it was a good decision or not, that's what I have to work with now.

----

badblocks came up clean, and I started over from the zeroed-out drive.

I realized at this point I only need to restore the small partition to see whether it's going to work or not (i.e. a minute or so rather than hours).

And the oddest thing, it works if I extract it to a temporary file first. Also note the absence of the "no space left on device" error. But firstly, I don't have room to do that with the big one (~300G compressed to 15). And secondly, I'd really like to know why it's doing this...

Code:
# gunzip -c sda1.img.gz | dd of=sda1.img bs=64K
359+47282 records in
359+47282 records out
1572864000 bytes (1.6 GB, 1.5 GiB) copied, 18.54 s, 84.8 MB/s

# mount -r -t ntfs-3g sda1.img /mnt/img

# umount sda1.img

# dd if=sda1.img of=/dev/sda1 conv=sync bs=64K
24000+0 records in
24000+0 records out
1572864000 bytes (1.6 GB, 1.5 GiB) copied, 15.4322 s, 102 MB/s

# mount -r -t ntfs-3g /dev/sda1 /mnt/sda1

# umount /dev/sda1

# gunzip -c sda1.img.gz | dd of=/dev/sda1 conv=sync bs=64K
dd: error writing '/dev/sda1': No space left on device
263+23738 records in
24000+0 records out
1572864000 bytes (1.6 GB, 1.5 GiB) copied, 17.9085 s, 87.8 MB/s

# mount -r -t ntfs-3g /dev/sda1 /mnt/sda1
ntfs_mst_post_read_fixup_warn: magic: 0xad44755d  size: 1024   usa_ofs: 25445  usa_count: 8988: Invalid argument
Record 0 has no FILE magic (0xad44755d)
Failed to load $MFT: Input/output error
Failed to mount '/dev/sda1': Input/output error
NTFS is either inconsistent, or there is a hardware fault, or it's a
SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows
then reboot into Windows twice. The usage of the /f parameter is very
important! If the device is a SoftRAID/FakeRAID then first activate
it and mount a different device under the /dev/mapper/ directory, (e.g.
/dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation
for more details.
 
Another thing, it's usually a good practice to clone/restore the disk geometry with sfdisk.

Isn't there hints in the ntfsrestore, or normal restore scripts from g4l ?
I think you should find some tips here.

Also I wouldn't use the bs= option when restoring. I think it's useless.
 
> Another thing, it's usually a good practice to clone/restore the disk geometry with sfdisk.

Thanks for the tip. I can do that when making new backups. As I said, this backup already exists. It contains a 512-byte file called mbr.bin, which apparently does include all the partition info. (Whether past self understood what she was doing or whether that was just luck, no idea.)

> Isn't there hints in the ntfsrestore, or normal restore scripts from g4l ?
> I think you should find some tips here.

At this point it seems nothing to do with NTFS. These are raw images, and at the byte level, two restore commands that would be expected to do the same thing are giving different results.

I had a quick look in the g4l scripts. As I thought, looks like restoring with g4l uses backups that were made with g4l. My backups already exist, so I don't think g4l is going to help me restore them.

> Also I wouldn't use the bs= option when restoring. I think it's useless.

The default is 512 bytes, which combined with sync option seems likely to make it slow.
...
Yup, leaving out the "bs" makes restoring take 7 times as long, so for the big partition I'd be waiting for days. The small one took 114s with default bs; 98s with bs=2K; 21s with bs=4K; 15s with bs=8K (and all the remaining steps up to 1M).
 
Last edited:
Yes, bs can speed things up as it defaults to 1 otherwise and uses a lot more CPU unnecessarily. I'm suspicious about that conv=sync argument you're passing there; according to the docs that means it will pad out anything it can't read either because the source is too slow or you're at EOF with zeroes to the bs size. It looks like it works once for you since you didn't get the out of space error the first time you did it, but you didn't test mount the drive after that step as far as I can see, only did a test mount after it errored about space.

Try without conv=sync. Maybe conv=fsync is worth using, but normally when blatting disc images with dd I don't use any conv option myself.
 
> g4l uses backups that were made with g4l

It's actually standard backups which are made with standard Linux shell commands (looked at those scripts a while ago).
 
Try without conv=sync. Maybe conv=fsync is worth using, but normally when blatting disc images with dd I don't use any conv option myself.

Huh, you're right, seems like that might be the problem. I just saw that option in all of the examples I read about how to do this, and didn't really understand what it does. I'll try the other partitions and report back later/tomorrow about whether it worked!

Where do you mean that I didn't test mount the drive?

It's actually standard backups which are made with standard Linux shell commands (looked at those scripts a while ago).

OK, maybe I didn't look hard enough. But it's still only relevant if their backups were made with the same commands as mine.
 
Last edited:
Sorry, you did do a test mount. There being no error output made me skip over that command I guess when grokking your session script. I did say 'as far as I can see' as I was aware that I'd only really skimmed it!
 
Thanks levi, the computer seems to work again!

I'll see if I can figure out where I picked up that bad idea, and whether it was my own fault or whether some website(s) need a complaint ;)

The computer still needed a repair from the Windows DVD to make it boot (and I was too impatient and tried several things at once, so I don't know which one was needed).
 
Back
Top