> 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.
