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
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users