Hi,
Perhaps other people may elaborate on this a bit more, but what you describe
is more like a "duplication" than a "cloning". What you do ( copy from a
working drive to another drive, maybe of another size ) is maybe more
achievable with a tool like Clonezilla.
Most people probably use ddrescue as its original purpose, to clone a
failing drive in order to rescue files. Then, it would be between drives of
the same zize or, in the case of only having smaller drives at hand, clone
the first part to Drive1, then the second part to Drive2, and manage to
concatenate them somehow for the rescue.
In that way, the contents of the disk ( MBR, GPT, other partition schemes )
do not pose a problem, because either you are using a disk with compatible
size, or the sum of the destination disks' are enough for the cloning.
In a cloning/rescue way, changing the partition´s size to make space for the
next partitions ( GPT, etc ) would possibly cause corruption on the original
partition, because say a 980GB partition would now become a 480GB partition.
And to access it one would need to fix the filesystem, on something that was
already in a suspect condition
----- Original Message -----
From: "Shahrukh Merchant" <shahr...@shahrukhmerchant.com>
To: <bug-ddrescue@gnu.org>
Sent: Sunday, April 13, 2025 2:48 AM
Subject: Using ddrescue to clone (or rescue) between unequally sized GPT
drives
I've been using ddrescue to clone MBR hard drives for many many years,
even when the source and destination drives are of different sizes. This
has been rather trivial in the case of MBR drives:
A. If destination drive capacity > source drive capacity
ddrescue -f /dev/sda /dev/sdb mapfile
i.e., nothing special to be done and any extra space on the destination
drive is just unallocated and can be used to expand the last partition or
create a new one with standard disk management tools on Windows or Linux.
B. If destination drive capacity < source drive capacity (of course the
allocated partitions still must fit within the destination drive, with
unallocated sectors at the end, which occurs quite frequently in my use
cases)
ddrescue -f -s12345678s /dev/sda /dev/sdb mapfile
where one would use "fdisk -l" to determine the last-used sector of the
last partition to use with the -s option (after adding 1)
The problem I now have is with GPT drives (I resisted crossing the 2 TiB
threshold till now ...) which have several sectors of backup partition
table and other information at the very END of the disk as well as the
beginning (regardless of unallocated space in between). So my approach
above needs to be augmented to take into account this additional
structural information stored not only at the very start of the disk as in
the case of MBR drives, but also at the very end. How would I need to
adjust my ddrescue commands to take this into account? Specifically:
1. What command can I use to get the sector number and size of the
position of the secondary GPT header at the end of the disk?
2. Is there any other structure information scattered elsewhere on the
drive (i.e., other than at the very beginning and the very end) that would
complicate this even more?
3. How would I modify my simple 1-liner ddrescue flow (to presumably
multiple invocations) to copy all the relevant parts and have a clean GPT
drive at the end of my cloning operation in the case where the disks are
not EXACTLY the same size?
4. Another more subtle problem: There is also a protective MBR on a GPT
drive that makes the entire drive look like a single partition fully
allocated disk, and this would also need adjustment of the faked partition
size if the destination drive is larger or smaller than the source drive;
so where and how would that adjustment need to be made?
More fundamentally, I'm actually surprised that this hasn't come up before
since GPT drives have been around for a while now and I would imagine that
rescuing or cloning to a drive that is larger than the original would be a
frequent occurrence. For the purely cloning application perhaps there are
other tools that take care of this, but they typically aren't doing any
rescuing. And even though the end result would be useable since the
primary GPT header and partition information would still be intact, the
secondary header/partition info blocks would indeed be corrupted.
I believe gdisk will fix this corruption both by recreating the secondary
end-of-disk partition information and fixing the protective MBR info, but
this is not self-evident and it seems anecdotally that many tools
including gparted will choke on the mismatch and not recognize any
partitions, which would cause unnecessary anguish when in fact the disk
might indeed be entirely useable.
Perhaps a new option for ddrescue is called for here? A
"GPT-fix-unequal-source-vs-destination-size" option? Which of course would
only apply in the case of a complete disk copy (i.e., not a partition
copy, which wouldn't have this problem).
Shahrukh Merchant
