Because it's there ...

[Dan]

... and 'cuz I'm both cheap and lazy.


The 411

The players:

• An older PATA Maxtor (3.5 desktop type) 120g currently housing my F16 install. (Which was supposed to be a temporary disposable install ... six months ago. <....> )
  
• A currently empty SATA 500g Hitachi (2.5 - notebook type) spare drive laying in a desk drawer. <....>
  
• dd? <....>

Mitigating factors:

• The PATA Maxtor is getting pretty long in the tooth, and I'm actually starting to value and use that F16 install more than my good old standby F11 drive. <....>
• I am completely unwilling to overwrite the F11 install. Most of my current and short-term archived data is living there.
  
• I'm decidedly lazy. I don't want to have to do another complete re-install. <....>
  
• The Hitachi is obviously lazier than I am. Right now, it's doing nothing. <....>
  
• I haven't seriously broken an install in over two weeks now. <....>
  
• The existing partitioning on the Maxtor is a basic boot, /(root), and swap setup, all primary partitions. (Sadly, I didn't build in a separate /home partition.)
  

The Proposed Action Plan:

• Rumor has it that dd can be used to "ghost" the contents of the Maxtor to the Hitachi ...
  
• ... and then the filesystem can be "grown" into the extra empty space.
  
• The Maxtor can then be "retired" to experimenting with the perpetual flow of new fedora vunderborks.

The mounting of the 2.5 in a 3.5 slot is not an issue. I have a roll of 2" packing tape, a fresh bag of cable ties and a big box of rubber bands. <....>

So ...

QTBAs:

• What kinds of pitfalls can I expect to run into here?
• How to prepare for same, and avoid them? (if possible.)
• Will I actually be better off to just byte the big time-filled techno-twinkie and slog my way through a fresh install and download/install all the applications, tweaks, and data into the new Hitachi -- all over again?
• Would I be better off in the long run to forget about the Hitachi, and grab a new ~500+g SATA 3.5 inch drive and use it instead? ie. Will the 2.5 have the needed durability/longevity?
  

Thank you for looking in, and thanks for your insight, input and suggestions.

Originally Posted by Dan

... and 'cuz I'm both cheap and lazy.


The 411

The players:

• An older PATA Maxtor (3.5 desktop type) 120g currently housing my F16 install. (Which was supposed to be a temporary disposable install ... six months ago. <....> )
  
• A currently empty SATA 500g Hitachi (2.5 - notebook type) spare drive laying in a desk drawer. <....>
  
• dd? <....>

Mitigating factors:

• The PATA Maxtor is getting pretty long in the tooth, and I'm actually starting to value and use that F16 install more than my good old standby F11 drive. <....>
• I am completely unwilling to overwrite the F11 install. Most of my current and short-term archived data is living there.
  
• I'm decidedly lazy. I don't want to have to do another complete re-install. <....>
  
• The Hitachi is obviously lazier than I am. Right now, it's doing nothing. <....>
  
• I haven't seriously broken an install in over two weeks now. <....>
  
• The existing partitioning on the Maxtor is a basic boot, /(root), and swap setup, all primary partitions. (Sadly, I didn't build in a separate /home partition.)
  

The Proposed Action Plan:

• Rumor has it that dd can be used to "ghost" the contents of the Maxtor to the Hitachi ...
  
• ... and then the filesystem can be "grown" into the extra empty space.
  
• The Maxtor can then be "retired" to experimenting with the perpetual flow of new fedora vunderborks.

The mounting of the 2.5 in a 3.5 slot is not an issue. I have a roll of 2" packing tape, a fresh bag of cable ties and a big box of rubber bands. <....>

So ...

QTBAs:

• What kinds of pitfalls can I expect to run into here?
• How to prepare for same, and avoid them? (if possible.)
• Will I actually be better off to just byte the big time-filled techno-twinkie and slog my way through a fresh install and download/install all the applications, tweaks, and data into the new Hitachi -- all over again?
• Would I be better off in the long run to forget about the Hitachi, and grab a new ~500+g SATA 3.5 inch drive and use it instead? ie. Will the 2.5 have the needed durability/longevity?
  

Thank you for looking in, and thanks for your insight, input and suggestions.

Use gparted to copy the partition instead (this doesn't apply for that lvm crap ) .

[Dan]

<....> Uhm ... I didn't know you could do that with gparted. (I guess I never looked at it that hard.) That simplifies things. <....>

[Doug G]

If you dd the entire disk image and restore it to the new drive, you will end up with the new drive being an exact clone of the old drive and the remaining space unallocated. You can simply boot off the new drive and then deal with using the additional space by making new partitions, expanding existing partitions, etc.

One possible problem is the disk UUID is copied if you clone the entire drive.

I don't think there are any problems cloning pata to sata.

[Dan]

One possible problem is the disk UUID is copied if you clone the entire drive.

That was one of my concerns.

[Doug G]

Originally Posted by Dan

That was one of my concerns.

I've used entire drive dd fairly often, and never had a problem cloning the UUID, but the drives I replaced were taken out of service and nothing else I use seemed to mind. I could see problems if you left the old drive in service on the network along with the new drive.

[Dan]

They'll both end up not only on the same network ... but likely in the same box.

[Misfit138]

Don't use dd...just use cp -a. dd is unnecessary and clunky for copying the contents of a drive.
Also, why not use human readable disk labels, rather than UUID- namely /dev/disk/by-label/

Recommended reading- https://wiki.archlinux.org/index.php...oning#Using_cp
and https://wiki.archlinux.org/index.php..._device_naming

enjoy

[Dutchy]

Cp isn't fit for copying file systems.
Also with a blocklevel kind of copy like dd the uuids won't change (also, dd is very powerful but I prefer things like clonezilla for this task).
One thing to consider is the place you installed the bootloader to and if it needs to be changed.

[jamielinux]

I've had lots of success doing this to clone a hard drive:

dd if=/dev/sda of=/dev/sdb bs=4096 conv=notrunc

UUIDs will be the same, but if you're going to be reformatting the Maxtor (or at least reformatting each partition), then it'll get new UUIDs anyway and you can carry on using it on the same box.

I wouldn't advise using cp at all, and it can't copy over the MBR anyway so you'll have to use dd for that.

[Misfit138]

I recommend cp -a.

Pros:
*allows for a filesystem change from source to destination e.g. source: ext3 dest: xfs
*allows for easy transition for drives of different sizes, without unnecessarily coping empty sectors
*is generally faster
*will simultaneously defrag the filesystem
*It is arguably harder to destroy an entire drive with a typo

Cons:
*requires subsequent manual installation and configuration of bootloader
*does not clone UUIDs, but I do not recommend using UUID as they are not human readable

I have used cp -a with 100% success for many years for the very purpose of cloning countless filesystems, many in excess of 100GB.

I do not recommend using dd, even with bs=4096, as it will be achingly slow and will mindlessly copy all sectors unnecessarily, hence my description as "clunky".

[errorxp]

I use dd_rescue to create a blind copy of a harddrive.

dd_rescue /dev/sda /dev/sdb

[Dan]

Okay.

Don't let this bag of popcorn fool you, guys. I'm here, I'm awake, I'm paying attention ... and learning.

[Gareth Jones]

I'd go with "cp -a" normally, (the free defrag if it's an old install is nice, and not copying unused blocks speeds things up, also you'll get the optimum FS parameters for the size of partition according to mkfs), but I'm not sure how that plays with SELinux. (I really must learn this SELinux stuff properly one of these days!) The cp manual page claims that cp knows about extended attributes though, and SELinux/ACLs are just special cases of them so it should work. You can set the UUIDs directly when formatting the new file-systems if you want the same ones used on the new partitions (-U option of mkfs.ext*, not sure about other mkfses). You'll have to install GRUB in the MBR though.

Actually, even if you want to image the partitions byte-for-byte, I'd just use "cp orig_dev new_dev" rather than dd, but that's just my taste. I only resort to dd if I actually care about block-sizes, offsets or counts (i.e. hardly ever) – I'd prefer the system to just get on with it rather than me worry about what block-size is most efficient on the hardware concerned... Then enlarge the partitions with gparted or the partitioner of your choice. If you don't use GParted, you'll also have to resize the file-systems with resize2fs, which defaults to the current partition size so doesn't need a size parameter unless you're shrinking the file-system.

[DBelton]

the -a parameter on the cp command tells it to preserve attributes and selinux context.

Normally, cp will set the selinux context to the context of the destination unless you tell it to preserve the original context. The -a parameter is really the same as using -dR --preserve=all.

Edit:

I would still run a complete selinux relabel on the first boot after copying the drive anyway.