From owner-freebsd-questions Sat May 1 9:13: 9 1999 Delivered-To: freebsd-questions@freebsd.org Received: from hecate.webcom.com (hecate.webcom.com [209.1.28.39]) by hub.freebsd.org (Postfix) with ESMTP id 4EF5014FE9 for ; Sat, 1 May 1999 09:13:06 -0700 (PDT) (envelope-from graeme@echidna.com) Received: from eresh.webcom.com (eresh.webcom.com [209.1.28.49]) by hecate.webcom.com (8.9.1/8.9.1) with SMTP id KAA09993; Sat, 1 May 1999 10:13:01 -0700 Received: from [204.143.69.29] by inanna.webcom.com (WebCom SMTP 1.2.1) with SMTP id 31578791; Sat May 01 09:09 PDT 1999 Message-Id: <372B5239.149D@echidna.com> Date: Sat, 01 May 1999 12:12:57 -0700 From: Graeme Tait Organization: Echidna X-Mailer: Mozilla 2.02 (Win16; I) Mime-Version: 1.0 To: gkshenaut@ucdavis.edu, freebsd-questions@freebsd.org Cc: info@boatbooks.com Subject: Re: Moving OS to a new disk References: <199904301825.LAA04796@deal1.bogs.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greg Shenaut wrote: > > If you have two drives with identical geometry, then you can just > use dd(1) to copy the exact source drive to the exact destination > drive. You should use the device nodes that mean "the whole raw > device, including all fdisk and bsd partitions". I do this with > a tape drive intermediate step to clone systems in our lab, which > all include a DOS partition as well as the BSD stuff. You shouldn't > have to change boot blocks or labels or partition tables or anything > else--the new disk will be an exact clone of the original. > > In my case, since the clones are ending up in different machines, > I have a short list of changes to make in /etc/rc.conf and a few > fixes of bugs that revealed themselves after I made the master > tape, but you shouldn't even have to do that, if you are just > replacing a flaky drive in the same system. > > I would suggest doing this in single user mode and just after > a "sync", to cut down on the problems that fsck will find when > you boot the new disk: to fsck, it will seem as if you just > turned off the machine at the point the copy was made. I used dd if=/dev/rda0 of=/dev/rda1 from single user mode with the master disk being mounted read-only for safety (both to prevent overwriting it accidentally, and avoid problems from any writes made by the OS to the source filesystems during the dd transfer). This worked fine, and is a lot easier than setting up multiple partitions, newfs-ing, dump/restoring, etc., and (FWIW) it preserves file flags which dump and tar don't. I have a couple of questions, though: (1) I had to mount the target disk read/write for dd to execute. Is the following appropriate with a virgin disk? mount /dev/da1 /mnt (2) The transfer rate was about 3MB/s. The disks concerned (Seagate Cheetahs) are capable of much more. Would increasing the block size used by dd from the default 512 bytes be legal and appropriate? If so, how should the block size be chosen (multiple of 1024? max. value?). > As for making backups, you *always* should make backups, but > there is no great risk in this procedure, because you aren't > altering the source disk. Unless, perchance, you mistakenly type something like dd if=/dev/rda1 of=/dev/rda0 I've disklabelled the wrong disk this way, in spite of reading over the command three times before hitting enter. -- Graeme Tait - Echidna To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message