Cloning Hard Drive

yankeenewbie · 07-06-2017, 04:17 PM

Can't seem to find the excellent post from mlp68 but here are some questions raised by it:

1. I certainly want a bootable clone--that's the whole point of this "backup". So yes, please, please provide more info on "chroot to the new root partition and make it bootable there".

2. I assume that the material between the "quote" text is to be typed as shown?

3. In your para 5 you discuss "using fdisk or parted" Not sure what "parted" means but I suspect a typo. Also, of course the disk is bigger than 2GB in which case I assume the command as given is correct.

4. Don't understand the "dry run" concept. If the "-n" operator is inserted, what happens, and why is this a "dry run?" If the purpose is to check that the process delivers the intended layout do you then erase it and do it again without the -n? Seems cumbersome but I am sure this is because I don't understand what's going on.

5. Please give more on cloning to a destination drive which is a different size. "just a few keystrokes to accomplish that layout interactively" is what I do not understand.

IsaacKuo · 07-06-2017, 05:03 PM

Quote:

Originally Posted by rknichols

If you use dd to copy an active read/write filesystem, what you get is an image of what you would have if you yanked the power plug on the running system.** There may be partially written open files, inodes using space but with no link in any directory, block usage bitmaps that are not consistent with the blocks actually claimed by inodes, and various other inconsistencies in the filesystem metadata. It's probably nothing that a quick preen by fsck can't patch up, but it's a rather foolish way to clone a system.

**Somewhat worse than that, really, since the dd operation takes significant time, so there can be inconsistencies between parts of the filesystem that were copied earlier and parts that had subsequent changes that were seen later in the operation.

Yes, definitely worse! dd on a large drive can take hours. So, a file might be written to tracks that dd already passed by, as well as tracks that dd has not yet passed. The journal thinks one thing but the actual sector data is just wrong.

I would never trust something backed up that way. I use dd for backups all the time, but never with any of the relevant partitions mounted. Since I have a lot of NFS and RAMBOOT boot options, I'll typically boot off the network or to a tmpfs root so I can do backups with dd and no mounted partitions. But I also have a couple USB drives to boot off of. I actually don't have any recent liveCDs ... they're so sluggish and slow, and too many of my computers have flakey optical drives for them to be so useful really.

That said, when I do OS tarballs for RAMBOOT, I do indeed do a tarball of the OS while it's "live". This is different from dd, because the files it balls up will at least be in a consistent state. But the process takes time so there is still the potential for some files to be created which other things expect but tar has already passed. I just try to do the tarball when not much stuff is going on to minimize the risk.

AwesomeMachine · 07-06-2017, 05:33 PM

Quote:

Originally Posted by rknichols

If you use dd to copy an active read/write filesystem, what you get is an image of what you would have if you yanked the power plug on the running system.** There may be partially written open files, inodes using space but with no link in any directory, block usage bitmaps that are not consistent with the blocks actually claimed by inodes, and various other inconsistencies in the filesystem metadata. It's probably nothing that a quick preen by fsck can't patch up, but it's a rather foolish way to clone a system.

**Somewhat worse than that, really, since the dd operation takes significant time, so there can be inconsistencies between parts of the filesystem that were copied earlier and parts that had subsequent changes that were seen later in the operation.

The major concern I have with using dd on a live system relates to future developments in *nix operating systems; developments that may introduce serious problems in the use of dd on live systems.

Already there are certain encryption schemes that render data unreadable if the encrypted volume is open and imaged from a live system. That may be a feature by some estimations, but for someone using an image as a back-up, it could spell disaster.

Therefore, I err on the side of caution and advise that, except in the event of the need for live forensic capture, dd imaging be done on cold drives.