On 7/30/11 12:30 PM, Robert Heller wrote: > At Sat, 30 Jul 2011 11:51:04 -0400 CentOS mailing list<centos at centos.org> wrote: > >> >> On Saturday, July 30, 2011 11:18:34 AM Robert Heller wrote: >>> dd can be problematic if the target and source disks are different >>> (sizes, geometry, etc.), since dd will do a literal sector-by-sector >>> copy, which is not generally advisable (and why o why to people *keep* >>> suggesting it? -- it is really a misuse of dd, unless you *really* know >>> what you are doing). >> >> Geometry on an LBA device should not be an issue. If it is an issue, that is a bug, since it is impossible to specify the actual geometry of the disk, even if the manufacturer makes that information available due to varying numbers of sectors per track across the platters. CHS geometry is an archaic thing. >> >> For direct clones dd and its variants work well, and get data that isn't in any filesystem or partition (boot loaders, in particular, often use the space before the first partition on the disk). The default upstream EL6.1 install leaves a full megabyte in front of the first partition; some bootloaders and other utilities use this space. >> >> Things like Dell's MediaDirect, for instance..... and that's but one example. Restore partitions (not just for Windows; Dell systems with Ubuntu preinstalled have them, and extended MBR boot sectors to handle them (LBA 3 is a common place to put the 'extended' boot loader for such things)). >> >> And that's part of the reason I'll use dd or a variant (ddrescue or dd_rescue, etc) if doing a clone to a disk of the same size or larger. Then I can resize partitions as needed for the larger disk using any one of a number of tools for the job. > > Presumably you '*really* know what you are doing'. I would recogmend > *against* dd or a variant for a newbie, who is likely to get him or > herself into various sorts of trouble (yes, with modern LBA devices, > geometry is not going to be a problem) -- there was a thread not too > long ago about someone who was cloning SSD devices with dd and having > various problems. If the destination disk is larger (or worse > smaller), dd can cause 'problems' -- if larger, there will be unused > parts of the disk requiring some sort of post hacking (futzing with the > partition table, fun with resize2fs, etc.), if smaller (even by the odd > cylinder's worth of sectors or so -- after all a 500G Seagate disk > might have *exactly* the same number of sectors/blocks as a 500G WD or > Fujitzu disk), well, opps! > > Also: dd can be *slow* with a large disk that is nowhere near full. It > can be a waste of time, etc. to copy 400G of empty sectors, when all > you really needed to copy was 100G worth of used file system space. dd > will also preserve all of the 'warts' of the file system > (fragmentation, deleted files, directories that have grown huge from > having lots of files that have since been deleted, etc.). dump/restore, > tar, etc. don't do that. Dump/restore, tar, also won't make the target disk bootable and you'll need to know an assortment of cruft to do that manually. Clonezilla uses sort of an intermediate approach, making partitions and copying with partclone (with dd as a fallback for unknown partition types), then doing the grub install cruft for you. One other thing that might do all the grunge work right is 'ReaR'. http://rear.sourceforge.net/. It builds a bootable iso with the tools from your running system that knows how to reconstruct the filesystem layout and restore a backup (of various sorts) on it. It knows more about raid than clonezilla and might even get combinations of lvm and raid right. Not sure if it works on 6.x yet, but I think it is in epel for 5.x at least. It is intended to get a backup of a working system up quickly on a replacement but it should work for cloning too. --- Les Mikesell lesmikesell at gmail.com