Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 14 Feb 2006 07:47:38 -0600
From:      Kevin Kinsey <kdk@daleco.biz>
To:        freebsd-questions@freebsd.org
Cc:        Giorgos Keramidas <keramida@ceid.upatras.gr>
Subject:   Re: Using dd to Make a Clone of a Drive
Message-ID:  <43F1DF7A.7000504@daleco.biz>
In-Reply-To: <43EBE2F8.8000501@daleco.biz>
References:  <200602092036.k19KaIhn086956@dc.cis.okstate.edu>	<20060209220123.GA4751@flame.pc> <43EBE2F8.8000501@daleco.biz>

next in thread | previous in thread | raw e-mail | index | archive | help
Kevin Kinsey wrote:

> Giorgos Keramidas wrote:
>
>> On 2006-02-09 14:36, Martin McCormick <martin@dc.cis.okstate.edu> wrote:
>>  
>>
>>>     After installing FreeBSD5.4, the ISC dhcp server and ISC bind
>>> on a hard drive, I wanted to clone that drive to a second drive so as
>>> to generate a second server, using what I had already installed as a
>>> template.  I used the following command:
>>>
>>> dd if=/dev/da0 of=/dev/da1 bs=512
>>>
>>>     It turns out that dd defaults to 512-byte blocks so I didn't
>>> really need the bs=512, but I am not sure I haven't made some other
>>> type of mistake.  The dd command has been running for about 4 hours on
>>> a very fast system, with a 1-gig processor, 1 gig of RAM and two 31-GB
>>> drives.  One would think it should have finished by now, but it is
>>> still running.  Is this a valid method of copying the entire contents
>>> of one drive to another?  Thank you.
>>>   
>>
>>
>> Bah!  That's too slow for my taste.  I would usually go for a newfs,
>> dump, and restore option.  For instance, to create a copy of /usr on a
>> second disk:
>>
>>    newfs -U /dev/ad1s1a
>>    mount /dev/ad1s1a /mnt
>>    dump -0 -a -L /usr | ( cd /mnt ; restore ruvf - )
>>
>> Copying with dd(1) is not as fast :)
>>  
>>
> Sorry to butt in --- but I'm needing to start cloning too.  Looks
> like a winner to me ... wouldn't this have the added advantage
> of making "same size and geometry" (cf. Erik Trulsson, 4 hours ago,
> this thread) less relevant?
>
> As long as the "new" slice had enough space, geometry shouldn't
> matter to dump|restore ....  <?>
>
> Kevin Kinsey


Just for the archives:

Giorgios' solution is very nice, but needs the "-f" option and another
"-" to work properly AFAICT, both from experience and from reading
dump(8):

          dump -0 -a -L -f - /usr | (cd /mnt ; restore ruvf - )

If you don't include "-f" (for "file") and "-" (for "stdout"), then your
command will fail with:

          DUMP: Cannot open output "/dev/sa0"

    unless you actually have a tape drive, as, of course, any
experienced user could have told you would happen, if
not when they read the incorrect command line, then when
they saw, previously:

          DUMP: Dumping snapshot of /dev/$somedisk to /dev/sa0


I used the strategy above to clone a working installation of
Wine and a rather obscure Win32 program from a 20 GB IDE
HDD to an 8GB drive with good success after attempts to
"re-create" a similar installation manually had failed, presumably
because something in re: Wine had changed in the interim,
though we've been unable to establish this as fact.

So, I've adopted dump(8) and restore(8) for disk cloning as
a result of this experience.  Next step: moving to dump|restore
for my home-brew backup routines....

HTH Someone,

Kevin Kinsey

-- 
Heisenberg may have slept here





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43F1DF7A.7000504>