Xaos Master
May 24 2007, 11:03 PM
Hello,
We currently run FedoraCore 2 / Plesk 7.5.4 on an unmanaged remote server.
We wish to upgrade both to FedoraCore 6 / Plesk 8.1.1. on the production server and we would like some feedback on our proposed process.
We propose to,
1. Create new Linux (ext3) partition.
2. Clean install of FedoraCore 6 to new partition.
3. Assuming no problems from step 2, boot to new partition and clean install Plesk 8.1.1.
4. Again, assuming no issues from step 3, use Plesk Migration Manager to transfer Plesk 7.5.4 database to Plesk 8.1.1
5. Test migration and assuming no problems, go live with updated version.
Obviously, we shall have to schedule down-time with our clients and liaise with our hosting service as we do not have physical access to the hardware.
Is this process as (very roughly) outlined viable, or should we be looking at a specific updating tool?
We tried the Plesk 7.5.4 Updater earlier - with disastrous results, i.e. a damaged but still just-workable Plesk installation.
All constructive comments and suggestions would be be appreciated, this is a major project for us and it's our first attempt at a manual upgrade.
Thanks in advance ...
Squire
May 25 2007, 02:48 AM
Those would be the basic steps. Except you need in there somewhere to apply some security measures before you start moving over the domains. eg Set up a firewall, disable direct root login, make sure SSH is up to date, etc, etc. There are other posts around here regarding how to secure a new server, including a couple that are Plesk specific.
You say you have no physical access to the old server. Do you at least have the ability to tweak the DNS for each domain on that machine?
If you do or can talk your current host into pointing the DNS entries on the old server to the new IP as soon as the migration is complete you can limit any downtime due to propagation to basically zero. I've gotten myself into the habit of disabling mail on the old server prior to migration then re-enabling it on the new server once migration is done to keep from having mail hit the old server during the time it takes to complete migration, thus not be transferred to the new server. You'll still want to give everyone a heads up that it'll be happening, but if you can change the DNS on the old server it really shouldn't cost them more than a tiny bit of downtime. They probably won't even notice it if you schedule the migration during night time hours.
Gary Simat
May 25 2007, 08:47 PM
you cannot use the migration manager for same server migration. I suggest you purchase a new server and just do a cross server migration. Also use CentOS and not fedora.
Xaos Master
May 27 2007, 08:07 PM
QUOTE (Gary Simat @ May 26 2007, 02:47 PM)

you cannot use the migration manager for same server migration. I suggest you purchase a new server and just do a cross server migration. Also use CentOS and not fedora.
Thank-you guys, for your replies
A question for/to Gary ... if we installed CentOS to a partition on a 2nd (new) hard-drive and then clean-installed Plesk 8.1.1, could we then migrate the Plesk domain/client database using the Plesk 8.1.1 Migration manager or does the 2nd server need to be an actual separate machine?
Thanks again for your help,
Simon G
Squire
May 28 2007, 04:11 AM
It would need to be a separate machine as far as I know Simon.
But if we're talking about moving stuff to a 2nd hard drive there's actually an easier way to do it than using the migration manager. Just install your O/S and everything on the second drive as normal and also a clean version of Plesk. The key is to make sure the PSA install is the same version number as on your current server drive, which means you may be starting with something less than you want in the end.
Going back to the old drive run the Plesk Backup Utilities to dump everything into a backup file for you. Then restore it onto your New drive. Once you have it there you can then upgrade Plesk on the new drive to whatever version number you want. You've already got a backup to fall back on if needed.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please
click here.