Sent from my iPhone
> On May 13, 2021, at 2:00 AM, SCIENTIFIC-LINUX-USERS automatic digest system > <[email protected]> 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 <[email protected]> > Subject: Re: hard drive cloning > >> On Wed, May 12, 2021 at 12:57 AM Yasha Karant <[email protected]> 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 <[email protected]> > 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 > [email protected] > > 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) > ****************************************************************************
