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
_______________________________________________
Bug-ddrescue mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-ddrescue
