On 2020-04-23 07:56, R C wrote:
well, you can do it with dd, but the details are tricky at times.


You are not just "cloning" a disk, like you used to copy a disk. I drive has multiple things, like an MBR, and

partitions and such. Most of the time to just clone a disk, copy it if you will, works, but what one should really

do is copy partitions, figure out how big they need to be. And then there's things like layout etc etc.


What clonezilla etc do, is use the same stuff, pretty much dd, except they have some "logic" in their software on how

why mess with installing that when core utilities and a bit of bash can do the same.


to copy those partitions, MBR/fat and all that. Some drives don't care about alignment for example, and work not that

optimal, others might not work like that.

A "fail safe" way to do it is use sync or so.  There are different ways to do that though.  If you do not want to "hammer"

the drive that is failing, you still create an img/iso, mount that and then create a disk by partitioning/formating it, and after

that you use the mounted image with sync or so to move the files to your new disk.


dd works really well for copying devices, especially if they are the same or very similar, or for copying a device to a file/iso/img

or from an "image file" to a CD/DVD or SSD memory. Mostly used for RapsberryPi and such.

dd is just a tool, very versatile and powerful, but as with all tools, you need to know the details on how to use it and for what.

Bravo. I'm horrified reading recommendations to use dd for cloning files on storage devices. dd copies fragmented files as is so you are messing new drive for performance issues from the get go.

The best use for dd is in computer forensics and virtualization environments for the same purpose or "deep troubleshooting" to find out why a VM has issues.

I mentioned rsync to be one of the best and most effective utilities for cloning locally or remotely in my experience. One option "--dry-run" allows you to see what will happen without making a big mistake if you are not careful.

There is another way to copy/clone files I learned in my Sun OS/Solaris days.

Drive 1, /dev/sdb mounted /tmp/disk1
Drive 2, /dev/sdc mounted /tmp/disk2

(cd /tmp/disk1; tar cfp - *) | (cd /tmp/disk2; tar xvf -)

* assumes all directories but you can just name a few for the process.

tar utility was always on all Unix systems, rsync was not. There is one more utility worth mentioning: cpio You can change file ownership during file copy/clone process which is some times necessary.

I miss days when utilities mt and rmt were needed for files manipulation! It's magic to watch tape reels spin one way or the other. No silly G-code needed to spin reels or have the drive suck tape into vacuum chambers ;-)

--
Rafael Skodlar


_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to