Date: Mon, 13 Mar 2000 10:14:10 -0500 From: "Charles N. Owens" <owensc@enc.edu> To: Ken Bolingbroke <hacker@bolingbroke.com>, freebsd-stable@FreeBSD.ORG Cc: Peter Radcliffe <pir@pir.net> Subject: Re: disk cloning (& a bit of picobsd) Message-ID: <38CD05C2.7159E85@enc.edu> References: <Pine.BSF.4.21.0003100905030.66391-100000@fremont.bolingbroke.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I'm responding to both topics... Ken Bolingbroke wrote: > Redirected from -stable to -questions. > > On Fri, 10 Mar 2000, 'Peter Radcliffe' wrote: > > > Disk cloning with dd is evil. Don't Do That. > > > > My recommendation is to partition the disk as you desire, newfs and mount > > the partitions then use > > cd /new/partition; dump 0f - /original/partition | restore rf - > > Is there a particular reason you say dd is evil for disk cloning? I admin I also am curious as to why use of dd in this way is bad. I've read a number of journal articles that advocate its use in just this way (another source, O'Reilly's new "Unix Backup & Recovery", by W Curtis Preston talks about its flexibility for certain backup/recovery applications). The key thing is to _really_ understand the strengths and weaknesses of whatever tool you're considering... and to do rigorous testing.... > a lab full of machines with various OS flavors. The PCs especially serve > multiple duty running FreeBSD, Linux, or <shame>NT</shame>. When the > machines get trashed, or I have a sudden need for extra machines of a > particular configuration, it would be nice to have a easy way to clone the > disks and restore things. > > As it happens, I do have access to a hardware disk cloner, which is way > cool. But that means I have to A) maintain a master disk for each > configuration, and B) take the drives out of each machine and plug them > into the disk cloner. Both of these are somewhat undesirable. > > So I've been envisioning something where I can maintain compressed master > copies of each configuration on a humonguous disk on the lab server, then > when I want to restore/change a specific machine, I insert a boot floppy > that reads the image off the server and writes it to disk. Bingo, a fresh > new machine, ready to use! This has been done... using FreeBSD as the image server, even. The purpose was to allow a printer company (Lexmark) to efficiently maintain a lab of Win9x systems for print driver testing. See: http://www.usenix.org/publications/library/proceedings/lisa97/10.barnett.html > My initial tests with 'dd if=/dev/rwd1 bs=32k | gzip -9 > /bigslice/fbsd.dsk' then a corresponding 'gzcat /bigslice/fbsd.dsk | dd > of=/dev/rwd1 bs=32k' look promising. And best of all, it's OS-neutral. I > don't have to worry about how to create NT partitions and write to NTFS or > any of that crap. Just clone the whole disk and be done with it. > > So is this bad, evil even? Hah!!! I'd not thought about doing this for my NT servers! Very good! To ensure optimum compression it will in many cases help to initially to dd /dev/zero onto the entire disk before installing the OS onto it. That way when you create the dd image as many of the disk sectors as possible are blank. I have a bunch of NT servers with identical hardware and OS configuration... it would be nice to be able to have _one_ image for all servers... one has to worry about about mucking with the NT SID stuff, which isn't trivial. > And back to that thing about making a boot floppy...is it just me, or does > 3.4-STABLE's source code not build a picobsd 'net' boot floppy? I make > the floppy image, write it to floppy, then boot up on it and the boot > loader craps out with errors I don't recall at the moment. Repeatedly > banging my head on it didn't help a whole lot, altho I noticed that midway > through my attempts, CVSup brought in new stuff that changed the whole > thing somewhat dramatically. I sorta thought -STABLE would be, well, > stable, but doesn't seem to be the case for picobsd... No... not your imagination. (Grrrr) It worked fine back in August but some some stuff has been more recently MFC'd but not properly integrated. Two things, mainly, are broken: * Kernel config files won't build (they're not up to date with the rest of the tree. Bringing in the stock GENERIC config file and tweaking does the trick) * As you point out, the loader stuff doesn't fly. Greg Lehey, I think, pointed out on the -embedded list that you can get around this by removing all files from the floppy's /boot directory except loader. Then create a new loader.rc file with these contents: load kernel load -t mfs_root fs.PICOBSD I have a little script that I run after I build a picobsd image that does this automatically. Works, but, as you said, it would be nice if everything functioned smoothly out of the box (but, as someone may rightly point out, we're free to submit diffs to fix the problem). Here's the silly script... #!/bin/sh echo Okay... now we\'ll toast the loader magic with the echo dumb-but-works stuff... \(Hit ENTER if you\'re sure\) read foo vnconfig -u /dev/rvn0 >/dev/null 2>&1 vnconfig -c /dev/rvn0 picobsd.bin mount /dev/vn0c /mnt rm -r /mnt/boot/* # "bootstuff" contains just loader and loader.rc # cp bootstuff/* /mnt/boot umount /mnt vnconfig -u /dev/rvn0 >/dev/null 2>&1 echo echo Done... picobsd.bin has been toasted. -- ------------------------------------------------------------------------- Charles N. Owens Email: owensc@enc.edu http://www.enc.edu/~owensc Network & Systems Administrator Information Technology Services "Outside of a dog, a book is a man's Eastern Nazarene College best friend. Inside of a dog it's too dark to read." - Groucho Marx ------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38CD05C2.7159E85>