At Sat, 30 Jul 2011 14:19:40 -0500 CentOS mailing list <centos@centos.org> wrote:
> > On 7/30/11 12:30 PM, Robert Heller wrote: > > At Sat, 30 Jul 2011 11:51:04 -0400 CentOS mailing list<centos@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 Yes. But it is *less* dangerious and less weird to copy the file systems using proper file system disk-to-disk copy tool (eg dump/restore or tar or cpio or the like), and then do the necessary grub-install or lilo or whatever bootloader install step. Over or under copying with dd is either a disaster or confusing, to a newbie: "why did dd crash copying from my 500G WD disk to my new 500G Seagate disk? How do I get access to the rest of my 1TB disk after I dd my 500G disk to it?". Also, dd can be a total disaster copying a *live, mounted* file system. While there are warning about dump and live file systems, tar or cpio are safe for use with a live, mounted file system. Sometimes it is easier or necessary to do this cloning with a live system (idealy in single user mode). > 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 > lesmikes...@gmail.com > > > > > _______________________________________________ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos > > -- Robert Heller -- 978-544-6933 / hel...@deepsoft.com Deepwoods Software -- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
