Facebook
Twitter
Upgrades of Plesk (like 8.6 to 9.x) are known to cause a lot of work and problems, possible server outages and so on.
As as migration to a new machine was planned anyway, I decided to handle this (hardware and software migration including OS migration to OpenSuse 11) in one step.
The setup of the new system including the manual additions to the mail handling (spamassassin handling, use of rbls and clamav early in processing, so that a reject of the mail in case of problems is possible (instead of accepting it and then bouncing it)) worked fine.
But the data (configuration and content from Plesk 8.6 to Plesk 9.2.2 turned out to be a real problem.
The first attempts with the backup manager and pre9-convert failed.
Even after removing the signature envelope and correcting some fields reported as having a wrong content (shouldn't the conversion tool do that?!) the 9.2.2 backup manager reported "Wrong content" and I had neither the time nor the intent to dig in the deep of the logfiles for the possible reason.
To avoid a manual "from scratch" configuration (and simply copying user data) as well as an upgrade of the running old system with 8.6 (which would not guarantee, that the data migration to the new system would then work flawlessly), further attempts were performed with the migration manager.
As a sidenote, the user data is quite big, the whole data has a size of 16+ GB. But that shouldn't be a problem in my eyes and is also not that surprisingly. Plesk can handle many domains and should therefore be able to handle such amounts of data.
The first automatic attempts failed, data was migrated partial and at a certain point, even Plesk refused to work. Luckily, I had a backup of the initial PSA database so I could reset Plesk back to the installation state. I found no other tool or way to reinitialize Plesk and to delete/reset all config data. As Plesk is preinstalled on the system, a complete reinstall is somewhat risky and costs only time.
After this, I tried the manual dump as described here and in the KB.
That worked quite well for most of the mail data, but for the majority of the web data, it again failed.
I then migrated user by user.
And here a perhaps important hint for others.
Although the migration policy was set to "overwrite exisiting data from backup", this will ONLY work for objects in the PSA database. If for any reason ftp/web-accounts (in /etc/passwd) or databases/database-users (in mysql) with the same name exist, the migration will fail. The logfile is somewhat unreadable in a text editor and looking to the migration policy, the error of a duplicate user/database is strange.
This cannot be solved from the web interface, it requires manual correction on system level (passwd) or with database tools (mysql).
I have the impression that this happened during the migration of the manual dump and that users/databases were created and an error occured before the Plesk database was updated.
Also the web migration manager showed problems, it could turn (with a exclusive assigned IP) into an endless loop reporting a conflict, but not allowing a resolution of that (the exclusive IP was properly assigned to the correct domain).
Overall, the migration manager and the whole migration process needs in my eyes much more effort BEFORE RELEASING A NEW MAJOR VERSION.
Otherwise it creates the impression that Parallels focusses on new users and does not care at all over existing users and the systems Plesk is running on.
I was close to search for migration tools to other management interfaces to avoid the trouble with Plesk updates once and for ever.
This is a pity as Plesk has a nice and user-friendly interface making it easier for the normal user to achieve proper results.
As as migration to a new machine was planned anyway, I decided to handle this (hardware and software migration including OS migration to OpenSuse 11) in one step.
The setup of the new system including the manual additions to the mail handling (spamassassin handling, use of rbls and clamav early in processing, so that a reject of the mail in case of problems is possible (instead of accepting it and then bouncing it)) worked fine.
But the data (configuration and content from Plesk 8.6 to Plesk 9.2.2 turned out to be a real problem.
The first attempts with the backup manager and pre9-convert failed.
Even after removing the signature envelope and correcting some fields reported as having a wrong content (shouldn't the conversion tool do that?!) the 9.2.2 backup manager reported "Wrong content" and I had neither the time nor the intent to dig in the deep of the logfiles for the possible reason.
To avoid a manual "from scratch" configuration (and simply copying user data) as well as an upgrade of the running old system with 8.6 (which would not guarantee, that the data migration to the new system would then work flawlessly), further attempts were performed with the migration manager.
As a sidenote, the user data is quite big, the whole data has a size of 16+ GB. But that shouldn't be a problem in my eyes and is also not that surprisingly. Plesk can handle many domains and should therefore be able to handle such amounts of data.
The first automatic attempts failed, data was migrated partial and at a certain point, even Plesk refused to work. Luckily, I had a backup of the initial PSA database so I could reset Plesk back to the installation state. I found no other tool or way to reinitialize Plesk and to delete/reset all config data. As Plesk is preinstalled on the system, a complete reinstall is somewhat risky and costs only time.
After this, I tried the manual dump as described here and in the KB.
That worked quite well for most of the mail data, but for the majority of the web data, it again failed.
I then migrated user by user.
And here a perhaps important hint for others.
Although the migration policy was set to "overwrite exisiting data from backup", this will ONLY work for objects in the PSA database. If for any reason ftp/web-accounts (in /etc/passwd) or databases/database-users (in mysql) with the same name exist, the migration will fail. The logfile is somewhat unreadable in a text editor and looking to the migration policy, the error of a duplicate user/database is strange.
This cannot be solved from the web interface, it requires manual correction on system level (passwd) or with database tools (mysql).
I have the impression that this happened during the migration of the manual dump and that users/databases were created and an error occured before the Plesk database was updated.
Also the web migration manager showed problems, it could turn (with a exclusive assigned IP) into an endless loop reporting a conflict, but not allowing a resolution of that (the exclusive IP was properly assigned to the correct domain).
Overall, the migration manager and the whole migration process needs in my eyes much more effort BEFORE RELEASING A NEW MAJOR VERSION.
Otherwise it creates the impression that Parallels focusses on new users and does not care at all over existing users and the systems Plesk is running on.
I was close to search for migration tools to other management interfaces to avoid the trouble with Plesk updates once and for ever.
This is a pity as Plesk has a nice and user-friendly interface making it easier for the normal user to achieve proper results.