[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Shahrukh Merchant
Subject: Re: [Bug-ddrescue] How to restore just a single partition of a multi-partition image file?
Date: Fri, 25 Jan 2019 12:12:45 -0300
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

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?


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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]