Restoring disk images

Discussion in 'Offtopic Discussions' started by HelenF, Jul 26, 2018.

  1. HelenF

    HelenF Member

    Joined:
    Jun 22, 2013
    Messages:
    382
    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
     
    Tags:
  2. levi

    levi Still fresh, damnit!

    Joined:
    Oct 6, 2008
    Messages:
    9,759
    Location:
    Somewhere off the coast of the EU
    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.
     
  3. HelenF

    HelenF Member

    Joined:
    Jun 22, 2013
    Messages:
    382
    Location:
    UK
    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 ;)
     
  4. Linux-SWAT

    Linux-SWAT Hardcore Member

    Joined:
    Feb 13, 2010
    Messages:
    8,051
    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.
     
  5. HelenF

    HelenF Member

    Joined:
    Jun 22, 2013
    Messages:
    382
    Location:
    UK
    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.
     
  6. Linux-SWAT

    Linux-SWAT Hardcore Member

    Joined:
    Feb 13, 2010
    Messages:
    8,051
    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.
     
  7. HelenF

    HelenF Member

    Joined:
    Jun 22, 2013
    Messages:
    382
    Location:
    UK
    > 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: Jul 27, 2018
  8. levi

    levi Still fresh, damnit!

    Joined:
    Oct 6, 2008
    Messages:
    9,759
    Location:
    Somewhere off the coast of the EU
    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.
     
  9. Linux-SWAT

    Linux-SWAT Hardcore Member

    Joined:
    Feb 13, 2010
    Messages:
    8,051
    > 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).
     
  10. HelenF

    HelenF Member

    Joined:
    Jun 22, 2013
    Messages:
    382
    Location:
    UK
    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?

    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: Jul 27, 2018
  11. levi

    levi Still fresh, damnit!

    Joined:
    Oct 6, 2008
    Messages:
    9,759
    Location:
    Somewhere off the coast of the EU
    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!
     
  12. HelenF

    HelenF Member

    Joined:
    Jun 22, 2013
    Messages:
    382
    Location:
    UK
    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).
     
    levi likes this.

Share This Page

Loading...