Debian Server hardware upgrade questions

[drewb0y]

My current ISPConfig3 server is on an Intel Pentium 4 system with 2 80GB SATA drives configured in LVM as one big drive.
(I mostly did this just to see how it worked, and because debian would see the software RAID as 2 devices and not the RAID 0 I wanted.)

So that is where I am at now. I have a Dual AMD Opteron server coming next week. It will have 2 250GB SATA drives, and 12GB RAM when I have it all assembled.

So my questions are, how easy or difficult would it be to transfer everything from the P4 system to the AMD?

What steps would you take? Other than network drivers, what other problems will I encounter?

I do have a daily backup running using the back-res script posted here.

[falko]

You can try to create an image of the current system (e.g. with CloneZilla, Ghost4Linux, or SystemImager) and restore the image on the new system.

http://www.howtoforge.com/cloning-li...-clonezilla-se
http://www.howtoforge.com/back_up_re...th_ghost4linux
http://www.howtoforge.com/how-to-bac...h-systemimager

[drewb0y]

I was considering that method actually. Or I could also do a fresh install and then try out my backups by actually doing a restore of everything to the new installation. I guess the only major concern is that the kernel may need to be different. The existing was installed using the i386 and for a dual processor AMD should be using AMD-x64. I will try it a couple of different ways and report back which worked the best.

Thanks again

[drewb0y]

The one thing I am concerned about if I do a clone of the drive is the new system will not be using a kernel that can really use the dual processors. It will still be 32 bit.

Which leaves me with 2 options I guess, each with their own questions.

1. Create a new server (64 bit) and then copy over everything from the backups. If I do this, will I need to worry about old 32 bit binaries from the
backups overwriting the new 64bit binaries?

2. Create a new server and then make it a slave of old server, then promote it. I can see where this would work, but I think it would only be copying over all the standard ispconfig databases and configs but none of my modifications.

Method 1 would potentially be less complicated, and I wouldn't have to worry about missing anything if my backups have all that is needed. Method 2 would be more fun and good practice, but I may have to re-institute any modifications I have made from stock.

I think I will have to consider the pros an cons of each option some more before I commit to either. (And read up in the manual on Master & slave operations) Thanks for your help and ideas on this one.

I guess the main thing I wonder at this point is, am I making the 32 bit versus 64 bit thing a bigger issue than it should be?

[sjau]

if you're not under any time pressure, why not setup the new serve with 64 bit and then migrate ISPConfig to it... that way you get more experience doing that.

The problem with 32bit is that you can only address 4 GB ram in there. Although some distros provide PAE which ehances the 32bit addressing to 34bit which means that you can use more than 4 GB ram however each process will still be bound to 4gb at max.

As you have 12 GB on the new machine, it would be a shame not to put it at good use.

[drewb0y]

I finally got around to upgrading. I ended up doing a clean install of Debian Squeeze 64 bit with Ispconfig 3.0.3.2.

I copied over the old /var/vmail directory and imported only specific tables from the dbispconfig database. Also copied over the roundcube database.

The tables that I imported from the mysql dump for dbispconfig were

client
mail_domain
mail_forwarding
mail_user
remote_user
spamfilter_users
spamfilter_wblist

Other than a few hiccups in various configurations it has gone fairly smoothly.

[astinsan]

I have always done it that way... The only time it is a issue is if you deviate from a stock install dramatically and even then it is still easier to just do a fresh install then copy only data over.

Maybe a good tutorial could come out of this to automate migrations.... I have often wondered how one would do this in a large scale operation.