DD not working--SUCCESS!

[Jacques B.]

> No, you're taking bytes off and putting them on drives.  Neither drive
> should be mounted.
>
> Matt Flaschen

Further to this, dd is a powerful utility that allows you to write
directly to a device.  Whereas cp, rsync, and other such commands
require a mounted file system.  dd copies from one drive to the other,
oblivious to the actual content.  Just that byte 1 on /dev/sda5 is
\x65, so write \x65 to byte 1 on /dev/sdb6.  Byte 2 on /dev/sda5 is
\x80, so write \x80 to byte 2 on /dev/sdb6.  All this happens at the
physical layer.  Whereas cp for example will look at the information
in the inode to determine where to find the file, and how many bytes
to copy so it requires a file system in order to work.

Even though a drive is not mounted, so long as it is connected
properly dd can read/write to it.  Because it is doing so at the
physical layer...

I realize there may be some information overload going on here.  But
hopefully my analogy of photocopying the book illustrates the danger
of dd'ing a live system.  In some scenarios that would have to be done
(computer forensic investigation of a server that cannot be taken down
for example).  But not in your scenario. Picture a mechanic trying to
work on an engine that is running.  Now imagine trying to rebuild that
engine while it's running.  In the case of copying an entire operating
system and user files as you are doing, dd is rebuilding a complexe
system (granted using a very simple process).  That cannot be done
with any assurance that it will work properly if the system being
copied is running hence in a state of constant change.  It's not like
using rsync or other such tools that work at the file system level and
will place a lock on a file when doing something with it so that it
cannot be changed while it is copying it.

If after everything everybody has told you you still do not consider
dd'ing a live system as a poor and risky practice then nobody will
ever convince you.

Jacques B.