Sent from my iPhone
> On May 13, 2021, at 2:00 AM, SCIENTIFIC-LINUX-USERS automatic digest system <[log in to unmask]> wrote:
>
> There are 2 messages totaling 78 lines in this issue.
>
> Topics of the day:
>
> 1. hard drive cloning (2)
>
> ----------------------------------------------------------------------
>
> Date: Wed, 12 May 2021 08:57:41 -0400
> From: Nico Kadel-Garcia <[log in to unmask]>
> Subject: Re: hard drive cloning
>
>> On Wed, May 12, 2021 at 12:57 AM Yasha Karant <[log in to unmask]> 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.
>
> ------------------------------
>
> Date: Wed, 12 May 2021 09:22:04 -0500
> From: Alec Habig <[log in to unmask]>
> Subject: 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
> [log in to unmask]
> https://urldefense.proofpoint.com/v2/url?u=http-3A__neutrino.d.umn.edu_-7Ehabig_&d=DwIBAw&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=V1toaJR6UZOrLXFCXkOKFUs3vt3qJ0AfrhAXl8CyADI&s=5WPjGE0HAhpimXd1UWsdnNEXCG9R_Zzq226OaxK_rRo&e=
>
> ------------------------------
>
> End of SCIENTIFIC-LINUX-USERS Digest - 11 May 2021 to 12 May 2021 (#2021-52)
> ****************************************************************************
|
