Moving to a bigger HD, is dump still the best way

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Moving to a bigger HD, is dump still the best way

Bill Chmura-2
I found one of my firewalls has a 4Gig drive.  While it is still
working fine, I am thinking maybe I should remove the 10 year old thing
and maybe move it somewhere a little less stressed).

I googled and faq'd and nothing recent came up, so I was wondering if
this was the best way to move the stuff over.

 * Put in the new drive
 * Boot with cd / floppy
 * Partition new drive with the same layout, but bigger partitions
 * For each, mount old and new and dump from one to the other (per faq)
 * Recreate devices
 * Remove old drive reboot

Does this seem sane?

Thanks
--

Bill Chmura
Director of Internet Technology
Explosivo ITG
Wolcott, CT

p: 860.621.8693
e: [hidden email]
w. http://www.explosivo.com

Reply | Threaded
Open this post in threaded view
|

Re: Moving to a bigger HD, is dump still the best way

Janjaap van Velthooven
On Fri, Jan 06, 2006 at 12:25:25PM -0500, Bill wrote:
> I found one of my firewalls has a 4Gig drive.  While it is still
> working fine, I am thinking maybe I should remove the 10 year old thing
> and maybe move it somewhere a little less stressed).
>
> I googled and faq'd and nothing recent came up, so I was wondering if
> this was the best way to move the stuff over.

I usually use dump for those kind of tasks.

>  * Put in the new drive
>  * Boot with cd / floppy
>  * Partition new drive with the same layout, but bigger partitions
>  * For each, mount old and new and dump from one to the other (per faq)
>  * Recreate devices

I can't imagine any devices that to be recreated.

   * dont forget to installboot(8) the new disk or else it wont boot.

>  * Remove old drive reboot
>
> Does this seem sane?
> Thanks

        Janjaap van Velthooven
--  ________________________________________
   / __/ /_    / ______/ /_  __/ __/ /___  /
  / /_  __/___/_/_  /___  / / __/ /___  / /
 /___/_/_________/_____/_/_/_/_______/_/_/        

Reply | Threaded
Open this post in threaded view
|

Re: Moving to a bigger HD, is dump still the best way

K Kadow
In reply to this post by Bill Chmura-2
On 1/6/06, Bill <[hidden email]> wrote:

> I found one of my firewalls has a 4Gig drive.  While it is still
> working fine, I am thinking maybe I should remove the 10 year old thing
> and maybe move it somewhere a little less stressed).
>
> I googled and faq'd and nothing recent came up, so I was wondering if
> this was the best way to move the stuff over.
>
>  * Put in the new drive
>  * Boot with cd / floppy
>  * Partition new drive with the same layout, but bigger partitions
>  * For each, mount old and new and dump from one to the other (per faq)
>  * Recreate devices
>  * Remove old drive reboot
>
> Does this seem sane?

Yes.

Don't forget to add the boot block, and keep in mind the i386 BIOS
limitations on the root partition.


Kevin

Reply | Threaded
Open this post in threaded view
|

Re: Moving to a bigger HD, is dump still the best way

Joachim Schipper
In reply to this post by Bill Chmura-2
On Fri, Jan 06, 2006 at 12:25:25PM -0500, Bill wrote:

> I found one of my firewalls has a 4Gig drive.  While it is still
> working fine, I am thinking maybe I should remove the 10 year old thing
> and maybe move it somewhere a little less stressed).
>
> I googled and faq'd and nothing recent came up, so I was wondering if
> this was the best way to move the stuff over.
>
>  * Put in the new drive
>  * Boot with cd / floppy
>  * Partition new drive with the same layout, but bigger partitions
>  * For each, mount old and new and dump from one to the other (per faq)
>  * Recreate devices
>  * Remove old drive reboot
>
> Does this seem sane?

Yes, but just softRAIDing with a second drive is pretty good too, and
avoids having to test the new drive too extensively. (It should still be
tested, as you don't want it smoking the entire machine, but it's more
fault-tolerant. Especially if you use different busses...)

Other than that, it works. Be sure to installboot(8), as pointed out by
others.

                Joachim

Reply | Threaded
Open this post in threaded view
|

Re: Moving to a bigger HD, is dump still the best way

Nick Holland
In reply to this post by Bill Chmura-2
Bill wrote:

> I found one of my firewalls has a 4Gig drive.  While it is still
> working fine, I am thinking maybe I should remove the 10 year old thing
> and maybe move it somewhere a little less stressed).
>
> I googled and faq'd and nothing recent came up, so I was wondering if
> this was the best way to move the stuff over.
>
>  * Put in the new drive
>  * Boot with cd / floppy
>  * Partition new drive with the same layout, but bigger partitions

Only do this if you really need it.
Leaving much of your disk unallocated has lots of advantages.  4G is a
lot for a firewall...look at all the people putting firewalls on 256M
and 512M flash media.

If you don't have something to put in them, making partitions bigger
just makes it take longer to reboot after you trip over the power cord.
 If you leave a Big Empty at the end of the disk, you can always create
a new partition there if something actually gets filled.  There's just
no reason to allocate every block of a 40G (or 80G, or 160G) disk to a
partition in a firewall...

Stick your Most Likely to Grow partition at the end of the disk, you can
then use growfs to enlarge it, rather than copying the data.

>  * For each, mount old and new and dump from one to the other (per faq)
>  * Recreate devices
>  * Remove old drive reboot
>
> Does this seem sane?

+reinstall boot blocks.

Just did this today on a system, myself.  Saw your note, read it, and
thought, "...and install boot block".  Saw the reply reminding you to
reinstall boot block.  Did my upgrade, thinking, "don't forget to
install the boot blocks"...of course, I then forgot to install the boot
blocks. :-/

But yes, this process works.  AFTER you remember to install the boot blocks.

ON THE OTHER HAND, if all the machine is is a simple firewall, this is a
really good time to simply re-install from scratch, just as you wanted
it to be, copying over the config as needed.  It will very possibly be
faster to simply install OpenBSD on the new disk, enable PF, copy over
pf.conf, and get to work, rather than manually copying over all the
partitions, one at a time.

Forgetting to install the boot blocks is annoying on some systems. :)

Nick.

Reply | Threaded
Open this post in threaded view
|

Re: Moving to a bigger HD, is dump still the best way

Bill Chmura-2
On Sat, 07 Jan 2006 00:42:18 -0500
Nick Holland <[hidden email]> spake:

> Bill wrote:
> > I found one of my firewalls has a 4Gig drive.  While it is still
> > working fine, I am thinking maybe I should remove the 10 year old thing
> > and maybe move it somewhere a little less stressed).
> >
> > I googled and faq'd and nothing recent came up, so I was wondering if
> > this was the best way to move the stuff over.
> >
> >  * Put in the new drive
> >  * Boot with cd / floppy
> >  * Partition new drive with the same layout, but bigger partitions
>
> Only do this if you really need it.
> Leaving much of your disk unallocated has lots of advantages.  4G is a
> lot for a firewall...look at all the people putting firewalls on 256M
> and 512M flash media.
>
> If you don't have something to put in them, making partitions bigger
> just makes it take longer to reboot after you trip over the power cord.
>  If you leave a Big Empty at the end of the disk, you can always create
> a new partition there if something actually gets filled.  There's just
> no reason to allocate every block of a 40G (or 80G, or 160G) disk to a
> partition in a firewall...
>
> Stick your Most Likely to Grow partition at the end of the disk, you can
> then use growfs to enlarge it, rather than copying the data.
>
> >  * For each, mount old and new and dump from one to the other (per faq)
> >  * Recreate devices
> >  * Remove old drive reboot
> >
> > Does this seem sane?
>
> +reinstall boot blocks.
>
> Just did this today on a system, myself.  Saw your note, read it, and
> thought, "...and install boot block".  Saw the reply reminding you to
> reinstall boot block.  Did my upgrade, thinking, "don't forget to
> install the boot blocks"...of course, I then forgot to install the boot
> blocks. :-/
>
> But yes, this process works.  AFTER you remember to install the boot blocks.
>
> ON THE OTHER HAND, if all the machine is is a simple firewall, this is a
> really good time to simply re-install from scratch, just as you wanted
> it to be, copying over the config as needed.  It will very possibly be
> faster to simply install OpenBSD on the new disk, enable PF, copy over
> pf.conf, and get to work, rather than manually copying over all the
> partitions, one at a time.
>
> Forgetting to install the boot blocks is annoying on some systems. :)
>
> Nick.
>

What was that about boot blocks? :)

I see the wisdom in much of what you are saying.  I would like a bit
more space, but I think your right and I will not use up all the space.

Aside from the practice / experience of doing this under a non-panic
solution I'd probably just do a full install - so I can see your point
there also.

Thanks for all for the comments, suggestions and OPPS to avoid

Bill

Reply | Threaded
Open this post in threaded view
|

Re: Moving to a bigger HD, is dump still the best way <- dump problem

Bill Chmura-2
On Sat, 7 Jan 2006 15:39:20 -0500
Bill <[hidden email]> spake:

> On Sat, 07 Jan 2006 00:42:18 -0500
> Nick Holland <[hidden email]> spake:
>
> > Bill wrote:
> > > I found one of my firewalls has a 4Gig drive.  While it is still
> > > working fine, I am thinking maybe I should remove the 10 year old thing
> > > and maybe move it somewhere a little less stressed).
> > >
> > > I googled and faq'd and nothing recent came up, so I was wondering if
> > > this was the best way to move the stuff over.
> > >
> > >  * Put in the new drive
> > >  * Boot with cd / floppy
> > >  * Partition new drive with the same layout, but bigger partitions
> >
> > Only do this if you really need it.
> > Leaving much of your disk unallocated has lots of advantages.  4G is a
> > lot for a firewall...look at all the people putting firewalls on 256M
> > and 512M flash media.
> >
> > If you don't have something to put in them, making partitions bigger
> > just makes it take longer to reboot after you trip over the power cord.
> >  If you leave a Big Empty at the end of the disk, you can always create
> > a new partition there if something actually gets filled.  There's just
> > no reason to allocate every block of a 40G (or 80G, or 160G) disk to a
> > partition in a firewall...
> >
> > Stick your Most Likely to Grow partition at the end of the disk, you can
> > then use growfs to enlarge it, rather than copying the data.
> >
> > >  * For each, mount old and new and dump from one to the other (per faq)
> > >  * Recreate devices
> > >  * Remove old drive reboot
> > >
> > > Does this seem sane?
> >
> > +reinstall boot blocks.
> >
> > Just did this today on a system, myself.  Saw your note, read it, and
> > thought, "...and install boot block".  Saw the reply reminding you to
> > reinstall boot block.  Did my upgrade, thinking, "don't forget to
> > install the boot blocks"...of course, I then forgot to install the boot
> > blocks. :-/
> >
> > But yes, this process works.  AFTER you remember to install the boot blocks.
> >
> > ON THE OTHER HAND, if all the machine is is a simple firewall, this is a
> > really good time to simply re-install from scratch, just as you wanted
> > it to be, copying over the config as needed.  It will very possibly be
> > faster to simply install OpenBSD on the new disk, enable PF, copy over
> > pf.conf, and get to work, rather than manually copying over all the
> > partitions, one at a time.
> >
> > Forgetting to install the boot blocks is annoying on some systems. :)
> >
> > Nick.
> >
>
> What was that about boot blocks? :)
>
> I see the wisdom in much of what you are saying.  I would like a bit
> more space, but I think your right and I will not use up all the space.
>
> Aside from the practice / experience of doing this under a non-panic
> solution I'd probably just do a full install - so I can see your point
> there also.
>
> Thanks for all for the comments, suggestions and OPPS to avoid
>

Haha, and I thought it would be simple.  I had a few problems, but they
were easy enough to work through.  I am having a bit of a problem now
that I am not sure what to do...

I have so far:
 * Installed the new drive (wd1 is the new one, wd0 is the old)
 * Booted a 3.8 cd
 * fdisk'd it
 * disklabel'd the partitions
(only making them slightly bigger than before)
 * newfs'd each of them
 * made some new devices for wd1 in /dev (with MAKEDEV wd1)
 * mounted the old volumes (/mnt/oldr, oldv, oldu for root, var, usr)
 * mounted the new volumes (/mnt/newr, newvm newu for root, var, usr)

Now here is what I did then...

# cd /mnt/newr
# ../oldr/sbin/dump 0af - /mnt/oldr | restore rf -

(the old drive is also openbsd 3.8)

This worked like a charm for the root fs
Then I tried the var and I got a slew of errors about the disk being
full. But its the /dev/rd* drive thats full.

I am guessing its the "-" part of it.  Is it because the restore is not
grabbing it as fast as the dump is putting it there?

So then i tried booting the cd and then using cp - Rp but got a bunch
of operation not supported errors.

What is the best way to move this data?  I found some writings saying
dump over other ways, but The FAQ says to use cpio...

Would this be it from the source directory?
find -xv . | cpio -pv /mnt/newuser

I've never done anything with cpio before, so I tried it some and it
"looks" like it has all the rights and ownership the same...  But is
this sane / safe?

BTW, I am doing all this from the boot cd.

Any advice is deeply appreciated!

Reply | Threaded
Open this post in threaded view
|

Re: Moving to a bigger HD, is dump still the best way <- dump problem

Bill Chmura-2
On Mon, 9 Jan 2006 01:40:19 -0500
Bill <[hidden email]> spake:

> On Sat, 7 Jan 2006 15:39:20 -0500
> Bill <[hidden email]> spake:
>
> > On Sat, 07 Jan 2006 00:42:18 -0500
> > Nick Holland <[hidden email]> spake:
> >
> > > Bill wrote:
> > > > I found one of my firewalls has a 4Gig drive.  While it is still
> > > > working fine, I am thinking maybe I should remove the 10 year old thing
> > > > and maybe move it somewhere a little less stressed).
> > > >
> > > > I googled and faq'd and nothing recent came up, so I was wondering if
> > > > this was the best way to move the stuff over.
> > > >
> > > >  * Put in the new drive
> > > >  * Boot with cd / floppy
> > > >  * Partition new drive with the same layout, but bigger partitions
> > >
> > > Only do this if you really need it.
> > > Leaving much of your disk unallocated has lots of advantages.  4G is a
> > > lot for a firewall...look at all the people putting firewalls on 256M
> > > and 512M flash media.
> > >
> > > If you don't have something to put in them, making partitions bigger
> > > just makes it take longer to reboot after you trip over the power cord.
> > >  If you leave a Big Empty at the end of the disk, you can always create
> > > a new partition there if something actually gets filled.  There's just
> > > no reason to allocate every block of a 40G (or 80G, or 160G) disk to a
> > > partition in a firewall...
> > >
> > > Stick your Most Likely to Grow partition at the end of the disk, you can
> > > then use growfs to enlarge it, rather than copying the data.
> > >
> > > >  * For each, mount old and new and dump from one to the other (per faq)
> > > >  * Recreate devices
> > > >  * Remove old drive reboot
> > > >
> > > > Does this seem sane?
> > >
> > > +reinstall boot blocks.
> > >
> > > Just did this today on a system, myself.  Saw your note, read it, and
> > > thought, "...and install boot block".  Saw the reply reminding you to
> > > reinstall boot block.  Did my upgrade, thinking, "don't forget to
> > > install the boot blocks"...of course, I then forgot to install the boot
> > > blocks. :-/
> > >
> > > But yes, this process works.  AFTER you remember to install the boot blocks.
> > >
> > > ON THE OTHER HAND, if all the machine is is a simple firewall, this is a
> > > really good time to simply re-install from scratch, just as you wanted
> > > it to be, copying over the config as needed.  It will very possibly be
> > > faster to simply install OpenBSD on the new disk, enable PF, copy over
> > > pf.conf, and get to work, rather than manually copying over all the
> > > partitions, one at a time.
> > >
> > > Forgetting to install the boot blocks is annoying on some systems. :)
> > >
> > > Nick.
> > >
> >
> > What was that about boot blocks? :)
> >
> > I see the wisdom in much of what you are saying.  I would like a bit
> > more space, but I think your right and I will not use up all the space.
> >
> > Aside from the practice / experience of doing this under a non-panic
> > solution I'd probably just do a full install - so I can see your point
> > there also.
> >
> > Thanks for all for the comments, suggestions and OPPS to avoid
> >
>
> Haha, and I thought it would be simple.  I had a few problems, but they
> were easy enough to work through.  I am having a bit of a problem now
> that I am not sure what to do...
>
> I have so far:
>  * Installed the new drive (wd1 is the new one, wd0 is the old)
>  * Booted a 3.8 cd
>  * fdisk'd it
>  * disklabel'd the partitions
> (only making them slightly bigger than before)
>  * newfs'd each of them
>  * made some new devices for wd1 in /dev (with MAKEDEV wd1)
>  * mounted the old volumes (/mnt/oldr, oldv, oldu for root, var, usr)
>  * mounted the new volumes (/mnt/newr, newvm newu for root, var, usr)
>
> Now here is what I did then...
>
> # cd /mnt/newr
> # ../oldr/sbin/dump 0af - /mnt/oldr | restore rf -
>
> (the old drive is also openbsd 3.8)
>
> This worked like a charm for the root fs
> Then I tried the var and I got a slew of errors about the disk being
> full. But its the /dev/rd* drive thats full.
>
> I am guessing its the "-" part of it.  Is it because the restore is not
> grabbing it as fast as the dump is putting it there?
>
> So then i tried booting the cd and then using cp - Rp but got a bunch
> of operation not supported errors.
>
> What is the best way to move this data?  I found some writings saying
> dump over other ways, but The FAQ says to use cpio...
>
> Would this be it from the source directory?
> find -xv . | cpio -pv /mnt/newuser
>
> I've never done anything with cpio before, so I tried it some and it
> "looks" like it has all the rights and ownership the same...  But is
> this sane / safe?
>
> BTW, I am doing all this from the boot cd.
>
> Any advice is deeply appreciated!

sorry, change that to a

find -xv . | cpio -pdum /mnt/newuser

and sometimes v :)

Its more the find I am concerned with

Reply | Threaded
Open this post in threaded view
|

Re: Moving to a bigger HD, is dump still the best way <- dump problem

Nick Holland
In reply to this post by Bill Chmura-2
Bill wrote:
...

> Now here is what I did then...
>
> # cd /mnt/newr
> # ../oldr/sbin/dump 0af - /mnt/oldr | restore rf -
>
> (the old drive is also openbsd 3.8)
>
> This worked like a charm for the root fs
> Then I tried the var and I got a slew of errors about the disk being
> full. But its the /dev/rd* drive thats full.
>
> I am guessing its the "-" part of it.  Is it because the restore is not
> grabbing it as fast as the dump is putting it there?
...
I don't have time to verify the error that I'm pretty sure you are
making, but you are deviating from the FAQ's instructions, in a way that
I'm sure you think doesn't matter, but I'm pretty sure it does.

Nick.

Reply | Threaded
Open this post in threaded view
|

Re: Moving to a bigger HD, is dump still the best way <- dump problem

Hannah Schroeter
In reply to this post by Bill Chmura-2
Hello!

On Mon, Jan 09, 2006 at 01:40:19AM -0500, Bill wrote:
>[...]

>Now here is what I did then...

># cd /mnt/newr
># ../oldr/sbin/dump 0af - /mnt/oldr | restore rf -

>(the old drive is also openbsd 3.8)

>This worked like a charm for the root fs
>Then I tried the var and I got a slew of errors about the disk being
>full. But its the /dev/rd* drive thats full.

dump/restore need some space in /tmp. Just mount a mfs to /tmp so
that that doesn't fill up the initial ramdisk.

When I move to another disk, I boot from the old one to single user,
mount the new one unter /mnt and do the dump/restore for all partitions.
I just call mount /tmp manually, /etc/fstab has an entry for an mfs
based /tmp on my boxen anyway.

>[...]

Kind regards,

Hannah.

Reply | Threaded
Open this post in threaded view
|

Re: Moving to a bigger HD, is dump still the best way <- dump problem

Todd C. Miller
In message <[hidden email]>
        so spake Hannah Schroeter (hannah):

> dump/restore need some space in /tmp. Just mount a mfs to /tmp so
> that that doesn't fill up the initial ramdisk.

Or just point the TMPDIR environment variable to a mounted partition
with enough space.

 - todd

Reply | Threaded
Open this post in threaded view
|

Re: Moving to a bigger HD, is dump still the best way

Han Boetes
In reply to this post by Bill Chmura-2
I recently had to migrate my HD for another reason, and I wrote it
all down:

  http://www.xs4all.nl/~hanb/documents/hd-migration


# Han

Reply | Threaded
Open this post in threaded view
|

Re: Moving to a bigger HD, is dump still the best way

Hannah Schroeter
Hi!

On Mon, Jan 09, 2006 at 05:22:47PM +0059, Han Boetes wrote:
>I recently had to migrate my HD for another reason, and I wrote it
>all down:

>  http://www.xs4all.nl/~hanb/documents/hd-migration

I think async + softdep as mount option doesn't make sense.

And I still think the dump/restore combo will be faster than any other
way.

And mounting -u the *old* filesystems noatime would make things faster
if you still prefer or need to use pax/cpio/cp -R/... (e.g. if you have
different partitioning, so that dump/restore won't work).

Still, thanks for writing documents like this which might help people
see how to combine the basic (and well-documented) tools of the OS for
typical tasks.

># Han

Kind regards,

Hannah.