Taken verbatim from a post to email@example.com from December 2001, found here. Triple check parameters and think before running dd on a mounted disk.
Shouldn’t be run on a live disk, so here’s an alternative.
WARNING: This will also clone the disk UID. Which means that if fstab mounts the disk by UID instead of device, as it does by default for OpenBSD 5.0+, it might mount the wrong disk. Also, running this on a live system will leave the clone in an unclean state, as it wasn’t and will not be unmounted, in addition to other obvious problems. Which means that if you do this remotely and reboot without (someone) pulling out the clone, you’re likely screwed. Disk UID can be changed with disklabel(8), see the “i” command.
Timothy, Here's something we do from time to time, solving the very problem you describe. This technique DOES NOT require that the target drive (the clone) have any file system or partition information at all. Only that it be a raw formatted drive, ready to be written.. This saves tons of time! 1. Assuming the new disk is "identical" to the master, run 'disklabel <master_disk>' to get the size info for the raw disk (partition 'c'). Here's an example from one of my SCSI disk systems: % disklabel sd0 <cr> # using MBR partition 3: type A6 off 32 (0x20) size 2097120 (0x1fffe0) # /dev/rsd0c: type: SCSI disk: SCSI disk label: DK319H-18WS flags: bytes/sector: 512 <---- Used for cloning parameter sectors/track: 226 tracks/cylinder: 20 sectors/cylinder: 4520 <---- Used for cloning parameter cylinders: 7931 <---- used for cloning parameter total sectors: 35970860 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # microseconds track-to-track seek: 0 # microseconds drivedata: 0 16 partitions: # size offset fstype [fsize bsize cpg] a: 131048 32 4.2BSD 1024 8192 16 # (Cyl. 0*- 28) b: 1048640 131080 swap # (Cyl. 29 - 260) c: 35970860 0 unused 0 0 # (Cyl. 0 - 7958*) d: 262160 1179720 4.2BSD 1024 8192 16 # (Cyl. 261 - 318) e: 34528980 1441880 4.2BSD 1024 8192 16 # (Cyl. 319 - 7958*) % 2. Using the sectors/cylinder: parameter (above) as a "blocks per copy" value for the "dd" utility will allow for a clean; no overrun/underun transfer of data from one disk to the other. Notice the sectors/track:, the tracks/cylinder: and sectors/cylinder: values on your master disk. My own experience is that copying anything less than 128 blocks at a time is not too efficient, so the sectors/cylinder: value (above..for my disk) fits the bill. The total number of cylinders: is a convenient value to use as a COUNT value with the "dd" utility to determine just how much data to copy. 3. Now, armed with these "COUNT -and- sectors/cylinder" values, I can clone the master disk to the target disk. In my example (below) the master disk is SCSI disk 0 (sd0) and the target clone drive is SCSI disk 1 (sd1). I use the raw device node of each to eliminate any notion of "file system" in favor of a pure, raw copy. Also, I use the values learned about these two identical disks to control and limit the copy so there is no overrun or round off error (perhaps leaving some sectors un-copied). And, (very important) the "bs" (block size in bytes) value must be a multiple of the native disk block size; hence the 512x multiplier. Example: +----------- bytes/sector value / +------- sectors/cylinder value / / % dd if=/dev/rsd0c of=/dev/rsd1c bs=512x4520 count=7931 <cr> / total cyliders to copy value -----+ This technique has been used many - many times, for SCSI and IDE drives. It is predicated on the notion that both devices are otherwise identical. It does a block for block copy, at HIGH SPEED - from one disk to another. Interestingly, the "dd" utility will show you some useful statistics after the copy is completed, including the bytes/sec computation. In a test case yesterday, I was able to clone a 9GB SCSI drive in 500 seconds. You *could* have a larger disk as the target, with different geometry and it would work...although the copy efficiency might be lower. The resulting cloned drive will, however, appear to be identical to the master. For the most part...modern SCSI & IDE drives hide the actual sector by sector mapping on a physical disk...even re-mapping bad blocks to reserved locations to achieve factory specs. This occurs even on otherwise identical devices; from the same production run... Randy Lewis, RTMX timuel wrote: > > Hello, > > I`m a 'newbie' to this list, so I pre-emtively apologize for any lack of > etiquitte specific to this list. > > I`m looking for a *fast* way to clone my OpenBSD2.9 disks so that I can keep a > master set 'up my sleeve' in case of emergency. I`m working with SparcI`s and > SparcII`s here and don`t have the time for compilation, and installation of custom > software etc. if (god forbid) a drive or two should go on me ... which has been > happening ALOT around my work recently. Right now I`m doing a (VERY) basic installation, > overlaying my partitions, hanging the drives off the back of another machine, mounting > them and "find . | cpio -pdmv `ing" and it seems to be taking almost as long as doing a > fresh install. > > Any suggestions would be greatly appreciated. > > Thanks in advance. > > -- > Timothy G. Wesemann