Re: hard drive cloning
Correct, the "old" disk now mounted as a usb drive would have a UUID which would conflict with the "new" system disk. However, this is easily solved by changing the UUID on the now-usb disk to something new before your mount it. # tune2fs -U random /dev/sdc1 is just one way to do so. -- Alec Habig University of Minnesota Duluth Dept. of Physics and Astronomy aha...@umn.edu https://urldefense.proofpoint.com/v2/url?u=http-3A__neutrino.d.umn.edu_-7Ehabig_=DwIBAw=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=V1toaJR6UZOrLXFCXkOKFUs3vt3qJ0AfrhAXl8CyADI=5WPjGE0HAhpimXd1UWsdnNEXCG9R_Zzq226OaxK_rRo=
Re: hard drive cloning
On Wed, May 12, 2021 at 12:57 AM Yasha Karant wrote: > > Quoting: > > Many open source and commercial cloning tools will do a *much* faster > and more efficient duplicate. End excerpt. > > I assume faster and efficient is by comparison to a drive cloning device > with two slots, one for the source, and the other target (clone). If > so, which cloning tools do you recommend, either licensed for free or > for fee? Do these run on a single drive system, cloning the internal > single drive to an external USB raw device (e.g., /dev/foo but not > mounted)? A long time ago I would use dd from the drive to be cloned to > the target, both appearing as /dev but neither mounted (so that the > images would be "static" and fixed). 20 years ago, I did it myself with bash scripts and kickstart files. That allowed me to mount a hard drive of a new OS image, tarball the contents of the file system, exclude bulky and unnecessary components like various /var/cache/ directory contents or log files, and exclude swap space. The resulting tarball was not only vastly, vastly smaller, but could be expanded, chrooted into, and operations like "yum update" or other configuration tuning applied to generate new deployable OS images. Basically, I wrote a lot of the structure of docker by hand more than 20 years ago. My predecessor had been burning raw disk images, and zero-ing and burning alternative disk images for larger disks, which was... well, let's say "not efficient and took at least 20 times as long". > As for the "hilarity", I have done this -- carefully -- pre-UUID when > the external clone would appear as /dev/blah /dev/blah1 /dev/blah2 with > /dev/blah"i" being the i-th partition and /dev/blah the entire drive > including any hard-boot sectors or likewise "reserved" (visible under > gparted or the text terminal equivalent). Say /dev/blah1 was /usr, the > mount for /dev/blah1 to avoid hilarity might be /dev/usbblah1 , and the > like. Well, yeah. It can get a bit adventuresome when alternative kernels re-order the hard drives. and drive /dev/sda, /dev/sdb, /dev/sdc, etc. swap numbering. It's why I prefer UUID or even file system labels.
Re: hard drive cloning
Quoting: Many open source and commercial cloning tools will do a *much* faster and more efficient duplicate. End excerpt. I assume faster and efficient is by comparison to a drive cloning device with two slots, one for the source, and the other target (clone). If so, which cloning tools do you recommend, either licensed for free or for fee? Do these run on a single drive system, cloning the internal single drive to an external USB raw device (e.g., /dev/foo but not mounted)? A long time ago I would use dd from the drive to be cloned to the target, both appearing as /dev but neither mounted (so that the images would be "static" and fixed). As for the "hilarity", I have done this -- carefully -- pre-UUID when the external clone would appear as /dev/blah /dev/blah1 /dev/blah2 with /dev/blah"i" being the i-th partition and /dev/blah the entire drive including any hard-boot sectors or likewise "reserved" (visible under gparted or the text terminal equivalent). Say /dev/blah1 was /usr, the mount for /dev/blah1 to avoid hilarity might be /dev/usbblah1 , and the like. On 5/11/21 9:39 PM, Nico Kadel-Garcia wrote: On Tue, May 11, 2021 at 11:01 PM Yasha Karant wrote: I want to reduce the booting time interval and other disc access time interval. I have a 2 TByte SSD drive that has the same physical form factor as 2 Tbyte rotating media hard drive. I also have a device that will accept each drive and make a "bit by bit" copy from the source to target drive. Never assume that this will work, because hard drive manufacturers cannot count. i.e, whether a "2 TB drive" is actually 2^41 bits in size depends on how much space is being used for error correction, bad sectors, and the like. Many open source and commercial cloning tools will do a *much* faster and more efficient duplicate. The current drive is the conventional harddrive. May I clone the harddrive onto the bare SSD drive and then install, or will the machine fail to boot/run because of UUID descriptors? Will these clone or not? Most of the file systems in each partition are Linux XFS. As long as /etc/fstab sees matching UUID's or even filesystem labels, you should be OK in that sense. It's when you mount them both physically on the same hardware at the same time that hilarity can and will ensue.
Re: hard drive cloning
On Tue, May 11, 2021 at 11:01 PM Yasha Karant wrote: > > I want to reduce the booting time interval and other disc access time > interval. I have a 2 TByte SSD drive that has the same physical form > factor as 2 Tbyte rotating media hard drive. I also have a device that > will accept each drive and make a "bit by bit" copy from the source to > target drive. Never assume that this will work, because hard drive manufacturers cannot count. i.e, whether a "2 TB drive" is actually 2^41 bits in size depends on how much space is being used for error correction, bad sectors, and the like. Many open source and commercial cloning tools will do a *much* faster and more efficient duplicate. > The current drive is the conventional harddrive. May I clone the > harddrive onto the bare SSD drive and then install, or will the machine > fail to boot/run because of UUID descriptors? Will these clone or not? > Most of the file systems in each partition are Linux XFS. As long as /etc/fstab sees matching UUID's or even filesystem labels, you should be OK in that sense. It's when you mount them both physically on the same hardware at the same time that hilarity can and will ensue.
Re: hard drive cloning
Before the UUID method was introduced, cloning was not an issue. This brings up a second issue. Assume that the cloning works using a hardware cloning device -- that has worked before between different vendor's physical hard drives of the nominally same capacity or that worked by cloning a smaller drive onto a larger drive and then formatting the "unformatted" larger portion, etc. (I have done this both with EIDE and SATA drives -- and SCSI long ago on rack-mounted systems.) What happens if one attempts to use the "old" drive in a, say, SATA to USB adapter that normally would allow a SATA drive to mount as a USB device? As the internal harddrive and the USB mounted external hard drive have the same UUIDs (clones), there would be a conflict. (This approach did work before UUIDs, even with the same named partitions -- one manually mounted a /usr partition on the external drive under a mount point such as /usrusb, and the like -- new mount points for, say, /dev/sdc1 that had the same name -- /usr -- as /dev/sda1.) Is there any similar "trick" for mounting an external hard drive via a USB interface (or any other such interface to a different standard) even though nominally each has the same "identifier", now a UUID? On 5/11/21 8:34 PM, Alec Habig wrote: If you clone the whole thing using a lowlevel tool, say "dd": it will also clone the UUIDs. In your case, if you plan on removing the old disk before booting up with the new disk, that means it should just happily "wake up" in its new disk and never know the difference. On the other hand, if you're trying to clone partitions around onto new disks this way without pulling the old disk out (trying to expand your storage), then the duplicate UUIDs cause you trouble, because you'd have devices with the same UUID. You can generate new UUIDs if this is the case, by temporarily addressing things using hardware addresses instead. I've done this using similar disks (replacing failing drives) and it worked fine. But, I'm not sure if the differences in low-level geometry/blocksizes between different technology disks could cause a problem. I suppose it can't hurt to try: you can always reformat the new disk if it doesn't work.
Re: hard drive cloning
If you clone the whole thing using a lowlevel tool, say "dd": it will also clone the UUIDs. In your case, if you plan on removing the old disk before booting up with the new disk, that means it should just happily "wake up" in its new disk and never know the difference. On the other hand, if you're trying to clone partitions around onto new disks this way without pulling the old disk out (trying to expand your storage), then the duplicate UUIDs cause you trouble, because you'd have devices with the same UUID. You can generate new UUIDs if this is the case, by temporarily addressing things using hardware addresses instead. I've done this using similar disks (replacing failing drives) and it worked fine. But, I'm not sure if the differences in low-level geometry/blocksizes between different technology disks could cause a problem. I suppose it can't hurt to try: you can always reformat the new disk if it doesn't work. -- Alec Habig University of Minnesota Duluth Dept. of Physics and Astronomy aha...@umn.edu https://urldefense.proofpoint.com/v2/url?u=http-3A__neutrino.d.umn.edu_-7Ehabig_=DwIBAw=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=aTI04QiwYwL5FAiBUAkMdUQuFOGFmznVGqe2mvxW9pY=Om1zMT_zxu5HQQuUYbfw2kJy4b_960ullxhb1xd81Mc=
