Re: [Bug-ddrescue] How to restore just a single partition of a multi-partition image file?

[Shahrukh Merchant]

Thanks David, your response (below), as well as Timothy's response to my 
question as to why use the NTFS tools for a partition-based copy, allude 
to the difference between a partition-based clone (sector by sector 
copy) vs. a file-system based clone (file by file copy).

As David points out, file-based clones indeed have their place and have 
certain advantages such as being able to "clone" to a smaller partition 
if the source partition is not close to full, doing incremental clone 
updates, etc.

But for system backup and recovery purposes, I'm very skeptical of 
file-based "clones" because any number of utilities have subtle problems 
in copying (e.g., files with super-restricted permissions such as 
ownership by "Trusted Installer," very long full pathnames, odd 
characters in the file names, super-hidden files, etc.), and in the case 
of system partitions, the recovered partition sometimes not being 
bootable without further intervention. I have been bitten by this more 
than once.

I stopped using Norton Ghost about 10 years ago just because of this: I 
couldn't open their proprietary (yet another problem) backup file format 
in their restore utility (of that version of Ghost) because ONE file had 
a filename that exceeded some length. My current problem was caused by 
Partition Wizard's built-in file-based copy process (when it needed to 
move files off the end of a partition prior to shrinking it) corrupting 
all files owned by Trusted Installer and some by System located wholly 
or partially in sectors from the part it shrank (it created the files 
but with no content and 0 size, which corrupted beyond repair the system 
partition). I had to repair it from a 1-month old ddrescue image (which 
I did successfully), which is what started my current thread.

Since my problem with Norton Ghost, I stopped using 
file-system-dependent utilities for complete system backups (I still use 
it for differential backups but even there I use Cobian Backup, which 
does not use any proprietary formats but rather creates a parallel 
directory tree for the backed up files using presumably the OS's native 
copy function).

I switched to Vista's backup utility using .vhd disk images for a couple 
of years, then to Terabyte's Image for DOS for about 5 years, and since 
2017 ddrescue (when I discovered it upon needing to recover a failing 
drive, and then found it checked all the boxes and then some for a 
system backup and cloning solution as well, and have been using it since 
for that).

It seems to me that (a) if the destination file system itself were 
corrupt, restoring the partition from a backup one with a non-corrupt 
file system would wipe out any corruption in the destination file system 
as well (a good thing), since the entire partition is being replaced, 
file system and all and (b) if the source file system I'm trying to 
restore from is corrupt then I'm still better off doing a 
sector-by-sector partition restore and trying to repair and find "lost" 
files with repair tools and only then copying the recovered files to its 
final destination (yes, finally file-by-file at this point in this 
limited circumstance).

I was perhaps not very clear in my original post, but in my case neither 
source nor destination filesystem is corrupt, at least I have no reason 
to believe it is so. It is the OS *installation* that got corrupted 
owing to necessary system files being wiped out.

Timothy, to address your point, I agree that ntfsfix is not a bad idea 
anyway when things have been flaky. Might have been instructive to have 
done it on my flaky system partition before I restored it. By the way, 
anyone know was ntfsfix does differently, compared to DOS's chkdsk /f?

Shahrukh

On 2019-01-24 4:54 AM, David Morrison wrote:
> I think you might be making this too hard, but I am writing this from a 
> Mac user perspective where if it was a Mac disk, this is what I would 
> do. I imagine similar tools are available for Windows.
>
> The first thing you would do is to mount the disk image of the failed 
> disk so it is visible as a file system. This would typically mount the 
> partitions on that disk image individually. Preferably you would mount 
> them read only, and there are ways to do that through the command line 
> on Mac or a utility called Disk Arbitrator.
>
> Having got the partition I wanted accessible from the file system, I 
> would then Restore it to the correct partition on the new disk using 
> Disk Utility. (Clonezilla should be able to do this too.)
>
> The advantage of this technique over ddrescue is that you are not 
> copying block-by-block to the new partition, complete with any weirdness 
> that contains. Instead you are copying as files, which will copy to the 
> full new partition rather than just the first 200GB that ddrescue will 
> copy to. It would also set up boot blocks, etc as they need to be to be 
> bootable.
>
> This should also clear up any damage to the filesystem, if it can repair 
> it. But ofc if the C drive is very damaged as you suggest, then you have 
> to wonder whether it will be capable of doing anything afterwards.
>
> Cheers
>
> David