Migrating from Plesk 7.5.4(Fedora) to 8.2(Centos5)

[MacRonin]

I am getting ready to migrate from one physical server to another(at the same provider). My old system is 7.5.4 (Fedora Core) and the new one will be 8.2(Centos 5). I am looking for any tips or hints that might help keep this as simple as possible. I know that in the past there have been problems with the migration manager, and was wondering/hoping that it is currently stable enough to handle the majority of the transfer

Most of the sites I have on the server are dynamic content. With approx one half being handled by perl scripts(std not mod_perl) and the other half php sites most using Drupal as the CMS. The perl sites have very little content on site and primarily do remote inquiries and redisplay the data returned via XML. The php/Drupal sites have the data stored locally in MySQL databases. I also serve the DNS from this server.

How well is the migration tool handling the movement of the Plesk domain definitions, html/perl/php content and the associated databases? If I have made any modifications to any server config files(like php or apache), I assume that I will have to recreate them manually. I also just added an SSL certifcate which I assume that I will have to re-request.

 

[realaaa@]

basing on my experience Plesk for Unix to Plesk for Unix migrations are the best case, usually almost everything is properly migrated, because the structure is very similar.

How it works in general:

1) migration agent collects data from source host, it collects everything which is stored in Plesk database -> all manual changes to configuration files will not be migrated, only Plesk-stored settings will be transferred. Another example - it will only migrate databases which were created from Plesk.

the data is represented in form of XML description of all entities and lots of tar.gz archives

2) then migration manager transfers all files to the destination host.

3) then migration manager starts deployment of all objects according to the XML description and the IP mapping which is provided by user. Deployment is done by creating entities via Plesk CLI and unpacking archives/restoring databases.

So, all domains and their associated files/databases/mailboxes will be migrated exactly as they are to the new Plesk host. SSL certs should also be migrated, they are stored in Plesk database.

What you should make sure of:

1) that you have the latest available migration manager installed on the destination host, this is very important.
2) that you have enough disk space on both hosts.
3) that SSH connnection can be established between hosts.
4) that you don't have similar domains/clients on the destination hosts, in this case migration manager wil refuse to restore content for matching entities.

Out of the question that it's better to test things first on some test server, because it's quite possible that you will hit some problem during the migration.

Even in case of the problem during the migration it will not affect you current production server, i.e. the source host, because migration manager does not stop any services on the source host (data is collected via perl scripts without stopping anything) and does not delete anything from the source host. So you will have the opportunity to analyze what is causing the problem, restart the migration if needed, etc, etc.

What you should also be aware of - migration manager is not capable to sync data after the migration, so if some data will not be included into the archives that are generated by migration manager on the source host then you will need to grab new files manually. This usually happens with e-mail, i.e. some new messages arrive during the migration process and there is no way to transfer them with the migration manager after the restoration is finished on the destination host, people usually use tools like rsync to synchronize such data.

 

[MacRonin]

Thanks for the feedback realaaa. I had heard enough bad things about the migration manager in the past(It's been a while) that I wasn't sure what I might be getting into. It sounds like they might have the simple case of unix with Plesk to Unix with Plesk under control.

Since it is setup to handle environments other than just Plesk (for import), I'm guessing that it doesn't use the Plesk(psadump from web page) for the data backup. For some reason the dump/backup util skips the last step(reactivating the domain) for most of my domains. It appears to run the backup(file created, start and stop email sent) but usually doesn't reactivate the domain that was just backed-up. If I restart Apache thinks are OK. Unfortunately this means no automated backups for me :-(

 

[realaaa@]

> I had heard enough bad things about the migration

This is usually because people under-estimate migrations - those are actually not trivial operations, and failure can happen during any step of it.

I can say that almost always there are some problems during migrations, sometimes more severe, sometimes less, so you should be ready for problems.

The good thing about it is that there is a possibiltiy to redo the migration as many times as needed until all problems are revealed and it is known how to fix/avoid them, and only then you can do the migration last time, change the DNS and shut down the source server.

> Since it is setup to handle environments other than just Plesk (for import)
> I'm guessing that it doesn't use the Plesk(psadump from web page) for the data
> backup.

Since Plesk 8 the the backup manager is based on the migration manager, i.e. the backup is the data collection by the agent on the localhost and the restoration from backup is just those data restoration.

Before Plesk 8 backup/restore was powered by another, python-based engine which was actually doing the same, that's why it was decided to switch to migration manager engine.

> For some reason the dump/backup util skips the last step(reactivating the domain) for most of my domains.

This is a bug, sounds familiar - happens on Plesk 7.5?

It is either fixed already in the latter version of Plesk then you have or it is not reported yet - so you should first try to update to the latest patch level and if it doesn't help just apply to support with detailed bugreport or e-mail [email protected] directly.