Upgrading from 6.3 to 7.1 -- how dangerous?

[Matthew Seaman]

Glen Barber wrote:
> On Sun, Apr 19, 2009 at 1:06 PM, John Almberg <jalmberg at identry.com> wrote:
>> I need to upgrade a live, production server from 6.3 to 7.1. I can't afford
>> to have any troubles with this server. I have Absolute FreeBSD and a few
>> other BSD books, and the upgrade process looks fairly straightforward.
>> That's the theory...
> 
> Wise man (who I won't name to keep his identity private) once said:
> "In theory, there is no difference between practice and theory.  In
> practice, there is."
> 
>> Real world question: how scared should I be?

I've done several 6.x to 7.x upgrades on live systems.  There are some tricky
bits, but once you have been through the process it's fairly routine.

One big gotcha is that in oder to upgrade all the ports, you first need to
make sure that the software you're using and any dependencies it has are all
up to date too.  For portmaster this is not a problem, as it is a shell script
with no dependencies except on the base system.  For portupgrade, you should 
delete portupgrade and all of it's dependencies (some or all of: ruby, ruby-bdb,
bdb, openssl -- depending on your configuration choices) and then reinstall
by:

   # cd /usr/ports/port-mgmt/portupgrade
   # make install

>> I've thought about setting up a dummy server, just to practice on. Is this a
>> good idea? Or am I just a nervous Nellie?
>>
> 
> Get a test box to do this on first. :)

Absolutely.  A dummy run before the real thing is a really good idea.

One great benefit of using a test server is that you can also use it as
a package building machine (assuming it's the same CPU architecture of course).
Being able to upgrade all the installed software by installing pre-compiled
and tested packages will a) save you a lot of time when you have to have your
production server out of action to work on it and b) it lets you discover all
those little glitches and tweaks that you will need to deal with *before* you
have to do it for real.

If you do have a spare server with appropriate capabilities, one approach 
that you might consider is building a duplicate upgraded system image on the
spare machine and then simply swapping hard drives with your production box.
That is probably about the minimum time impact on production service[*] for
you to do this sort of upgrade and it has the really useful benefit that
there is a simple back-out path should things not work out.  Just swap the
old disks back in.

	Cheers,

	Matthew

[*] Well, modulo time required for disks to resynchronise if you're using
mirroring and can't swap both halves of the mirror simultaneously.  For the
whole RAID 1 thing to be effective your server /should/ run pretty much
normally while this is going on though.

-- 
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                  Kent, CT11 9PW

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20090419/dad0a24f/signature.pgp