SCIENTIFIC-LINUX-USERS Archives

May 2021

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Nico Kadel-Garcia <[log in to unmask]>
Reply To:
Nico Kadel-Garcia <[log in to unmask]>
Date:
Wed, 12 May 2021 08:57:41 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (41 lines)
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.

ATOM RSS1 RSS2