[SOLVED] Migration Fails to move databases with error

[trialotto]

First off, let me summarize what is and isn't happening.

What IS happening:
The domain, IP assignment (no matter if shared or dedicated) and DNS records are all migrated successfully. The DNS is correctly reformatted to the target server's DNS Template, it even revises the SPF record correctly.

What ISN'T happening:
Everything else. No site content, no aliases, no mail accounts and no databases. The whole process pretty much stops after the domain is retrieved and the IP and DNS are assigned. NOTHING happens after that.




There are no <ip_address> xml tags at all in the entire debug log.
However, I did notice something I thought was strange. Look at this xml:

=|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client|||<?xml version='1.0' encoding='utf-8'?>
=|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client|||<packet version="1.6.6.0">
=|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client|||  <webspace>
=|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client|||    <get>
=|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client|||      <result>
=|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client|||        <status>ok</status>
=|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client|||        <filter-id>xxxdomain.com</filter-id>
=|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client|||        <id>4</id>
=|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client|||        <data>
=|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client|||          <gen_info>
=|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client|||...
=|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client|||            <outgoing-messages-mbox-limit>default</outgoing-messages-mbox-limit>
=|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client|||            <outgoing-messages-domain-limit>default</outgoing-messages-domain-limit>
=|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client|||            <outgoing-messages-subscription-limit>default</outgoing-messages-subscription-limit>
=|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client|||            <outgoing-messages-enable-sendmail>default</outgoing-messages-enable-sendmail>
=|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client|||          </mail>
=|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client|||        </data>
=|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client|||      </result>
=|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client|||    </get>
=|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client|||  </webspace>
=|2015-11-10_10:08:12,758|D|MT|core.utils.common.http_xml_client|||</packet>

There is a </mail> closing tag but no <mail> opening tag. Shouldn't there be a <mail> opening tag?


This only shows the domain I entered manually to set up my own nameservers.

Mail (and everything else) works fine for domains that are set up from scratch. This is an issue with the Migrator. I even tried to do a simple backup from the source server and restore on the target server to move some domains and, although it does move the databases and some mailboxes (it doesn't move all of them for some reason) it breaks your ability to delete some mailboxes and has a few other problems with aliases.

To be honest, I have had so many issues with a very straightforward clean install of Plesk 12.5 on a brand new server that I am starting to feel that version 12.5 isn't ready for production. I have spent 2 weeks fixing issues that are all over the Odin forums that many people are having too. It has so many bugs that I have had to solve, I don't trust it to function correctly when I take it to production. Perhaps it should still be in beta. I may re-image the server and use 12.0.18 until 12.5 is truly finished.

@KirkM,

With respect to some of the issues you have mentioned, the following (general) work-arounds can be provided:

a) when migrating across versions, everything should be migrated, even though some (or more) error notifications can occur.

I did some tests with the migration manager and, in most cases:

- multiple issues were reported, but most of the issues can be safely ignored,
- an issue with the assigned IP occurred (note: the assigned IP was blank in the migration process, very similar to the issue you reported, but not exactly equivalent).

Some simple work-arounds seem to exist:

- rerun the migration process for one domain (and retry if the issue IP address occurs again), OR
- start with one domain, OR
- re-assign the IP address on the new server (the target server in the migration process).

For some strange reason, all the above work-arounds did result in a proper migration of data (with reported issues, that can be safely ignored)

b) when migrating across versions AND using a new server:

- install Plesk 12.0.18 on the new server,
- migrate using the migration manager (i.e. from 12.0.18 to another 12.0.18 installation)
- on the target server in the migration process, upgrade Plesk to 12.5.30 afterwards

and this should not be resulting in any issue.

c) when mostly migrating WordPress sites:

- create a fresh install of Plesk 12.5.30 on the new server,
- install a "clean" WordPress instance on the new Plesk 12.5.30 server,
- use "Migrate DB" and "Migrate Media" plugins for WordPress, in order to migrate the whole WordPress site (from a Plesk 12.0.18 to a Plesk 12.5.30 install)

and repeat the process for each WordPress site (note that this process only takes a couple of minutes per site).

Why would you want to migrate WordPress sites manually? In most cases, the WordPress databases are not migrated properly or not migrated at all.

d) the most obvious work-around:

- migrate all databases manually (simply exporting and importing of databases, even though "simply" is an understatement)
- rsync all data to the new server (inlcuding mailbox data)

and having said that, one should be aware that this "obvious work-around" is very error-prone. Just use the other methods, if they work for you.

Regards.....

 

[trialotto]

@KirkM

I can't do an entire server backup and restore because I have to do them in small groups to coordinate the eCommerce stores needing to be closed during the migration and the sites on which I have active data management systems in place so my licensees have to have their admin access taken offline. This all has to be coordinated in small bits.

Just as I had imagined, you are very likely to be experiencing non-standard migration issues, but issues related to WordPress or other eCommerce platforms.

Can you confirm that you are referring to WordPress based eCommerce?

When confirmed, I can make my tips to migrate more concrete (and that can do no harm).

Regards

 

[KirkM]

@trialotto
Thanks very much for your suggestions. So at least we can pretty much confirm that the Plesk Migrator (and by some measures backup / restore method) does not work if trying to go from 12.0.18 to 12.5.

Some simple work-arounds seem to exist:

- rerun the migration process for one domain (and retry if the issue IP address occurs again)

Have done that over and over. Fails the same way.

- start with one domain,

Tried that many times. Fails.

- re-assign the IP address on the new server (the target server in the migration process)

Also tried that. Fails.

b) when migrating across versions AND using a new server:

- install Plesk 12.0.18 on the new server,
- migrate using the migration manager (i.e. from 12.0.18 to another 12.0.18 installation)

This is what I am now considering, and will just stay with 12.0.18 for another 6 or 8 months until the migration and other issues are smoothed out with MU's.

- on the target server in the migration process, upgrade Plesk to 12.5.30 afterwards

That is absolutely terrifying. I can't possibly risk doing an in-place upgrade of the panel while in production and I can't move anyone to the new server without shutting them down during the process.

Here's the situation:
- My clients are active eCommerce (none of them are Wordpress), active custom data management systems (NOT CMS websites, backend data administration for enterprise) and also a bunch of Wordpress blog sites.

- There can be no activity from these clients during the move or that data input will be lost. So, they will have to be taken gracefully offline, moved quickly and re-pointed to the new name servers to put them back online. I temporarily lower TTL to one hour for two days prior to migration in the SOA so they are back up very quickly.

- They all can't be shut down at once and all can't be moved at once because I have to arrange with each client when they want the downtime to occur. They are all very particular with that and all want different days of the week at different times for minimal disruption of their business and I completely understand and accommodate them. It is a non-negotiable part of my client customer service policy.

- If I migrate them one-by-one from the current production server to the new one, they have to be immediately put online, especially the eCommerce sites. This means that there is no way to move everyone all at once "offline", test, upgrade the panel and then put them all online if everything is OK. It needs to be much more individual, quick, efficient and precise so their downtime is minimized and accommodates THEIR schedule, not mine (and certainly not flaws in the software I choose to utilize).

- So, if I moved everyone this way to the new server on 12.0.18, and it is fully in production and the panel upgrade to 12.5 breaks the server (this happened to me back in the PP 9 & 10 days), then everyone is out of business until I can fix it. It could be a considerable amount of time. That might put me out of business.

- Moving them manually, piece-by-piece is just not acceptable nor practical. One of my enterprise data systems clients has a couple of hundred databases with dozens of tables in each one containing millions of records. Doing DB dumps / restores of all of my clients would take so long that Plesk Panel Version 13 would probably come out before I was done. That just isn't going to happen.

At this point, even though 12.5 has some great new features that I REALLY want to utilize, it is not a good upgrade for any users like me who have to migrate clients from another server using 12.0.18 (or any earlier version, I would assume). I would guess that is a pretty large chunk of Plesk's user base. It may be fine for setting up a server and domains from scratch or if you are brave enough to to an in-place upgrade of a production server. Neither of those describe my situation so I guess I will have to settle on 12.0.18 for now on the new server. I will achieve 2 goals out of 3: new, faster hardware and the latest OS. No hat trick this time around.

 

[Alexey Baturin]

This only shows the domain I entered manually to set up my own nameservers.

That is very strange, there should be domains that you migrated, unless you removed them from the target server.

There are no <ip_address> xml tags at all in the entire debug log.
However, I did notice something I thought was strange. Look at this xml:

There is a </mail> closing tag but no <mail> opening tag. Shouldn't there be a <mail> opening tag?

Panel Migrator does not put full API requests/responses to debug.log to keep it readable: it replaces large parts of requests/responses with "...", that's why there is no closing tag, and that's why I don't see <ip_address> node, which I expected to see.

To enable full logging and check what's actually going on,
1. Edit

/usr/local/psa/var/modules/panel-migrator/sessions/<session-id>/config.ini

file, add "log-message-context-length = 0" to "[GLOBAL]" section, so it looks like:

[GLOBAL]
source-type = "plesk"
target-type = "plesk"
source-servers = "source"
session-dir = "<your-session-id>"
skip-log-priority-check = true
skip-migrator-updates = true
skip-set-session-directory-permissions = true
use-separate-log = true
# here it is:
log-message-context-length = 0

[plesk]
ip = "<your-target-server-ip>"
os = "unix"

<continued with other options>

2. Run the migration tool from CLI:

/usr/local/psa/admin/sbin/modules/panel-migrator/plesk-migrator 'transfer-accounts' '/usr/local/psa/var/modules/panel-migrator/sessions/<session-id>/config.ini' '--migration-list' '/usr/local/psa/var/modules/panel-migrator/sessions/<session-id>/migration-list'

3. Check debug.log again at

/usr/local/psa/var/modules/panel-migrator/sessions/<session-id>/debug.log

 

[Alexey Baturin]

So at least we can pretty much confirm that the Plesk Migrator (and by some measures backup / restore method) does not work if trying to go from 12.0.18 to 12.5.

As for me, it seems to be an issue on the target server side, regardless of the source panel and version. But the reasons are still unclear...
Do you consider providing access to Odin team to investigate the issue?

 

[trialotto]

@KirkM

In reaction to the statement

That is absolutely terrifying. I can't possibly risk doing an in-place upgrade of the panel while in production and I can't move anyone to the new server without shutting them down during the process.

I can add that you do not have to be afraid of anything: the new target server simply is a mirror of the old server, with the target server only activated after migration is succesfull.

In short, as long as you migrate data and do not point DNS to the target server, no harm can be done. Just a process of mirroring.

I will react to the other statements, per statement. Also read the final hints and suggestions afterwards.

- My clients are active eCommerce (none of them are Wordpress), active custom data management systems (NOT CMS websites, backend data administration for enterprise) and also a bunch of Wordpress blog sites.

In essence, rsyncing the whole server to the new target server will resolve many issues.

A manual database migration than can be executed, that is not that difficult AND should not cause any downtime.

- There can be no activity from these clients during the move or that data input will be lost. So, they will have to be taken gracefully offline, moved quickly and re-pointed to the new name servers to put them back online. I temporarily lower TTL to one hour for two days prior to migration in the SOA so they are back up very quickly.

During the rsync process AND the (manual) database migration process, one can leave the domains online, without any downtime.

It certainly is not necessary to fiddle with DNS and TTL.

- They all can't be shut down at once and all can't be moved at once because I have to arrange with each client when they want the downtime to occur. They are all very particular with that and all want different days of the week at different times for minimal disruption of their business and I completely understand and accommodate them. It is a non-negotiable part of my client customer service policy.

Again, all the domains can be migrated without any downtime, i.e. without having the necessity to shut them down.

All the domains on the old server can be simply online, when executing the migration processes.

- If I migrate them one-by-one from the current production server to the new one, they have to be immediately put online, especially the eCommerce sites. This means that there is no way to move everyone all at once "offline", test, upgrade the panel and then put them all online if everything is OK. It needs to be much more individual, quick, efficient and precise so their downtime is minimized and accommodates THEIR schedule, not mine (and certainly not flaws in the software I choose to utilize).

No, this is only the case in some very exceptional cases.

Normally, one would have domains registered at the registrar, pointing DNS to a specific server.

If you have Plesk configured to act as the primary nameserver, it still is not necessary that downtime is present: just add some A and other records (pointing to the old server) in the DNS zones, maintained at domain registrar.

In some exceptional exceptional cases, the addition of A and other records is not possible, only then you have a problem of (minor) downtime.

Anyway, rsyncing all data and migration of all databases to the new server does not have to cause downtime, if Plesk is configured as the primary nameserver:

a) copy all data, files and databases to the target server,

b) create proper DNS zones and DNS/SOA templates,

c) point the records at the domain registrar (pointing to the nameservers) to the IPs of the new target server

and that is all.

No downtime, simply a change of server, at the moment all DNS is propagated.

- So, if I moved everyone this way to the new server on 12.0.18, and it is fully in production and the panel upgrade to 12.5 breaks the server (this happened to me back in the PP 9 & 10 days), then everyone is out of business until I can fix it. It could be a considerable amount of time. That might put me out of business.

Again, for many reasons, there is the necessity of creating a MIRROR at the new target server, with the mirror only activated if everything works fine.

No issues of downtime and/or dataloss on the old server, just a risk of one or two "problems" on the target server (that is not yet active).

- Moving them manually, piece-by-piece is just not acceptable nor practical. One of my enterprise data systems clients has a couple of hundred databases with dozens of tables in each one containing millions of records. Doing DB dumps / restores of all of my clients would take so long that Plesk Panel Version 13 would probably come out before I was done. That just isn't going to happen.

Really, it is the most fast method: rsync really pumps data very fast to the target server (without the performance overhead caused by the migration manager).

The database migration process is simply a process of some minutes, one can migrate all databases at once, if desired (this is not adviceable though).

In short, your argument is not really valid. Just try to execute a trial run with rsync and you will know what I mean.

At this point, even though 12.5 has some great new features that I REALLY want to utilize, it is not a good upgrade for any users like me who have to migrate clients from another server using 12.0.18 (or any earlier version, I would assume). I would guess that is a pretty large chunk of Plesk's user base. It may be fine for setting up a server and domains from scratch or if you are brave enough to to an in-place upgrade of a production server. Neither of those describe my situation so I guess I will have to settle on 12.0.18 for now on the new server. I will achieve 2 goals out of 3: new, faster hardware and the latest OS. No hat trick this time around.

Really, to be honest, be aware of the following:

- faster hardware is not a solution, with the only exception of adding SSD drives: everything else is just an indication that hardware is not used properly or optimally. Note that a Plesk installation can survive perfectly on very old servers, even with a couple of hundred MBs. Speed and performance of servers are often the result of proper config settings and proper tools for maintenance of the server.

- the latest OS: upgrading to CentOS 7.1.x is asking for issues. In fact, most of the issues with Plesk are reported for CentOS systems, being the result of (on the one hand) the lack of experience of specific users with the recommended CentOS system and (on the other hand) the intricate and relatively complex structure of CentOS (as compared to Ubuntu, for example), requiring Odin Team to "adapt" Plesk to CentOS. Furthermore, it can not be expected that all Plesk related bugs and issues are resolved for CentOS 7.1.x systems.

In my humble opinion, try to redefine your goals: first of all, give highest priority to Plesk and Plesk upgrades, since that is the part that drives customer revenue.

Regards....

 

[Alexey Baturin]

Really, it is the most fast method: rsync really pumps data very fast to the target server (without the performance overhead caused by the migration manager).

Actually, Plesk Migrator uses rsync to copy web files and mail messages for Linux servers. But additionally it recreates all objects and web configuration, like addon domains, aliases, mailboxes, etc, so no manual work is required.
Also, to reduce downtime, I would recommend the following advanced process:
1. First, you perform full migration with Plesk Migrator.
2. Then you check that all sites work properly on the target server, there are no issues with another OS/Hardware, etc.
3. Then you use "copy-content" CLI command of Plesk Migrator: it uses rsync again, and it works fast, as rsync copies only changed files.
4. Then, you perform a switch at the DNS.

But anyway, we have another kind of trouble in that thread which completely blocks migration of a particular configuration for unknown reasons, and we need to sort it out first.

 

[trialotto]

@Alexey Baturin,

Plesk Migrator is something completely different than Plesk Migration Manager. Do not use Plesk Migrator, unless you are planning a cross-platform migration.

Some remarks about your post:

- Plesk Migration Manager uses rsync, but is much slower than using rsync directly from the command line (with or without archiving the files),
- the "copy-content" CLI command is not useful, when having the pure rsync command (note: this command will not simply do some rsyncing of files between servers)

In addition, it is not very likely that some other "kind of trouble" (as you described it) exists and it is not useful to investigate: if any issue is present, it is present on the old server.

Just use a new target server with a fresh and clean install of Plesk (being version 12.0.18 or 12.5.30).

Anyway, a simple manual migration of files (with rsync) and databases (sql dumps) would cost less time than the discussion on this forum.

Regards....

 

[KirkM]

Yes, there is a core issue we are getting away from.

First, I want to say that I really do appreciate the time and effort that @Alexey and @trialotto are putting into this.

However, there are a few things I would like to point out before I give up on this and just move hardware with everything staying as-is.

1. The point of the Panel in the first place is so users like me can focus on running a business without having to be a linux guru. When you start having to use CLI to perform functions you licensed the panel to do through a GUI, it isn't working.

2. Of course I want to help with the product as a user, but not by having my production server used as a testing sandbox. This should be done in a comprehensive testing environment at Odin. This common scenario should have been tested thoroughly before release and the issue discovered and fixed before release.

The 12.5 product doesn't work for my needs - particularly ease of use, the purpose of a panel in the first place. Odin is now aware that there is a problem with the migrator tool and can now go back to their testing environment to work on a solution for a future MU.

Thank you again for both of your time. I need to get back to business instead of fighting this panel. I'm sure 12.5 will be really nice a little farther down the road.

 

[Aleksey Filatev]

Anyway, a simple manual migration of files (with rsync) and databases (sql dumps) would cost less time than the discussion on this forum.

I could not agree with you. If you want to migrate one domain - yes, it will be easy, but for migration of 10 or 100 domains you need to automate the migration process. Plesk Migrator was designed for this purposes.

- Plesk Migration Manager uses rsync, but is much slower than using rsync directly from the command line (with or without archiving the files),
- the "copy-content" CLI command is not useful, when having the pure rsync command (note: this command will not simply do some rsyncing of files between servers)

Plesk Migrator has a feature to detect whether rsync compression needed. It considers network speed, CPU and memory utilization, content type (text or binary), etc. Also it has ability to force rsync compression via config.ini:

[GLOBAL]
rsync-additional-args = "-z"
...

The 12.5 product doesn't work for my needs - particularly ease of use, the purpose of a panel in the first place. Odin is now aware that there is a problem with the migrator tool and can now go back to their testing environment to work on a solution for a future MU.

I completely agree with you and apologize for any inconvenience and wasted time. Our team is ready to solve an issue which you faced. We will be very appreciated if you provide us content of migration session for investigation and reproducing on our testing environment. Could you please contact me privately?

 

[trialotto]

Yes, there is a core issue we are getting away from.

First, I want to say that I really do appreciate the time and effort that @Alexey and @trialotto are putting into this.

However, there are a few things I would like to point out before I give up on this and just move hardware with everything staying as-is.

1. The point of the Panel in the first place is so users like me can focus on running a business without having to be a linux guru. When you start having to use CLI to perform functions you licensed the panel to do through a GUI, it isn't working.

2. Of course I want to help with the product as a user, but not by having my production server used as a testing sandbox. This should be done in a comprehensive testing environment at Odin. This common scenario should have been tested thoroughly before release and the issue discovered and fixed before release.

The 12.5 product doesn't work for my needs - particularly ease of use, the purpose of a panel in the first place. Odin is now aware that there is a problem with the migrator tool and can now go back to their testing environment to work on a solution for a future MU.

Thank you again for both of your time. I need to get back to business instead of fighting this panel. I'm sure 12.5 will be really nice a little farther down the road.

In my humble opinion, it is a good decision to wait with the 12.5.30 implentation. Note that your conclusion is also a good advice for others.

Regards

 

[trialotto]

@Aleksey Filatev,

You stated

I could not agree with you. If you want to migrate one domain - yes, it will be easy, but for migration of 10 or 100 domains you need to automate the migration process. Plesk Migrator was designed for this purposes.

and this really concerns to separate issues.

Yes, it is preferred to use automation in migration of multiple domains, although it is not strictly necessary.

Yes, Plesk Migration Manager is an "automated" solution.

No, Plesk Migration Manager is not really an optimal solution, in the sense that it is unnecessary slow.

And my remark was just concerning "time" involved, with both plain rsync and Plesk Migration Manager (i.e. an augmented rsync process) able to migrate whole servers in the time spend on this forum, discussing the issues with the migration manager.

Hence, a subtle nuance.

You also stated

Plesk Migrator has a feature to detect whether rsync compression needed. It considers network speed, CPU and memory utilization, content type (text or binary), etc. Also it has ability to force rsync compression via config.ini:

and this exactly one of the reasons why a process from Plesk Migration Manager is very slow, with those reasons being (amongst other)

a) rsync compression is not "good practice" and will consume a lot of time and resources (disk space, RAM and CPU),

b) Plesk Migration Manager is just archiving the relevant files (before rsyncing), making rsync compression rather obsolete,

c) Plesk Migration Manager is just archiving the relevant files in tar or gz (before rsyncing), while the rsync -a option (i.e. "archive" option) is a better alternative,

d) rsync has really no need to check network speed, CPU and such, just run the command, as the available bandwidth will automatically limit the file transfer,

and so on.

Really, the Plesk Migration Manager process is (in brief)

- archiving all files to migrate (i.e. in essence creating a backup)
- rsyncing the archive, with some really unnessary options set (i.e. migrating a backup file, with an unnecessary overload of options, slowing the process down)
- on the target server: receiving the migrated data and extracting it (i.e. essentially restoring a backup)
- optionally, on the target server: checking for issues

and it is directly clear that

1) the whole rsync process can be abbreviated, by using a plain rsync command, AND

2) transferring a backup file (by ftp or rsync) and/or restoring a remote backup file (i.e. with the ftp directory on the target server) also does the trick.

In short, it must be clear that migration with the Plesk Migration Manager is not the best method of migration, it is unnecessary slow.

Also note that Plesk recommends to use the command line tools in the case of mass migrations, so Odin Team must be aware of all the above.

Finally, you stated (in response to KirkM)

I completely agree with you and apologize for any inconvenience and wasted time. Our team is ready to solve an issue which you faced. We will be very appreciated if you provide us content of migration session for investigation and reproducing on our testing environment. Could you please contact me privately?

and I must add that the migration manager processes have been buggy from the start on, in every Plesk version.

In essence, Odin Team should not only focus on the exceptional case of KirkM (it really is exceptional), but also investigate potential improvements in the Plesk Migration Manager.

The Plesk Migration Manager simply will not do the trick, if it is only able to migrate a limited number of domains (i.e. when it is unsuitable for mass migration).

To give some feedback to start with:

a) backport the incremental file backup process to Plesk 12.0.18,

b) do not use archives when migrating, use a rsync based process involving (only) incremental files.

Hope the above helps and if you have question, just start a conversation.

Kind regards....

 

[Alexey Baturin]

a) rsync compression is not "good practice" and will consume a lot of time and resources (disk space, RAM and CPU),

It depends. If network is slow, server is fast and there are many text files, rsync compression is good. If network is fast, server is loaded and there are binary files, rsync is definitely bad.

b) do not use archives when migrating, use a rsync based process involving (only) incremental files.

That's exactly how Plesk Migrator copies web and mail content in 12.5.

 

[trialotto]

It depends. If network is slow, server is fast and there are many text files, rsync compression is good. If network is fast, server is loaded and there are binary files, rsync is definitely bad.


That's exactly how Plesk Migrator copies web and mail content in 12.5.

@Alexey Baturin,

Finally, you have the Odin Team badge, as I already had assumed.

First of all, try to run the migration process with Plesk Migration Manager AND plain rsync and time both processes.

You will notice that the plain rsync is much faster, irregardless of bandwidth and/or hardware.

Second, rsyncing mail content is a solution, but it is and always will be a questionable solution.

Sure, it is possible, but there are some issues, certainly when it is part of a larger migration (i.e. migration of more data). Potential downtime is only one of them.

Why not using the common mail migration scripts for migrating mail????

Try larch, for instance (and this allows to take the mail migration out of the migration manager processes, which improves speed/performance significantly).

Third, if I am not mistaken, the plesk migration manager is still archiving the incremental files in a .gz file.

Fourth and final, fact remains that Plesk Migration Manager is always slower than a plain rsync.

This fact is mind-boggling, since one should and could expect that a rsync based migration method, as used by Plesk Migration Manager, is not much slower than plain rsync.

Awaiting your reaction!

Kind regards...

 

[Alexey Baturin]

Second, rsyncing mail content is a solution, but it is and always will be a questionable solution.

Sure, it is possible, but there are some issues, certainly when it is part of a larger migration (i.e. migration of more data). Potential downtime is only one of them.

Why not using the common mail migration scripts for migrating mail????

Try larch, for instance (and this allows to take the mail migration out of the migration manager processes, which improves speed/performance significantly).

rsync for mail works very fast and reliable, with practically no overhead. It allows the second sync to work super fast, to avoid downtime and lost mail messages.
What do you mean by the common mail migration scripts?
Also, Plesk Migrator allows to run several migration actions in parallel. For example at the same time we can have addon domains to be created for the first subscription, mail content copied with rsync for the second subscription, and database tables restored for the third subscription.

Third, if I am not mistaken, the plesk migration manager is still archiving the incremental files in a .gz file.

Fourth and final, fact remains that Plesk Migration Manager is always slower than a plain rsync.

No, no incremental files. Just plain "rsync -a <SOURCE-IP>:/var/www/vhosts/example.com /var/www/vhosts/example.com". You could try to migrate and check debug.log to see that.
And of course Plesk Migrator will be always slower that plain rsync. Because additionally to running rsync, it automatically transfers resellers and customers (with all contact data), subscriptions, addon domains, subdomains, aliases, scripting settings, mailboxes, databases (with content), database users, and so on.

Please note that I always speak about Plesk Migrator shipped as Plesk extension in Plesk 12.5, not Plesk Migration Manager from Plesk 12.0.

 

[KirkM]

Our team is ready to solve an issue which you faced. We will be very appreciated if you provide us content of migration session for investigation and reproducing on our testing environment. Could you please contact me privately?

This has to be one of the most perfect responses in this entire thread and speaks volumes to me. It is the way I treat my customers and, in my opinion, the ONLY way to do business.

I can not overstate my appreciation for your positive attitude and efforts to address issues with the Panel so they can be corrected. I will contact you privately and hopefully it can get sorted out.

I also want to commend you for actively and knowledgeably correcting false assumptions posted regarding the panel so that the public has accurate information about the product.

 

[trialotto]

This has to be one of the most perfect responses in this entire thread and speaks volumes to me. It is the way I treat my customers and, in my opinion, the ONLY way to do business.

I can not overstate my appreciation for your positive attitude and efforts to address issues with the Panel so they can be corrected. I will contact you privately and hopefully it can get sorted out.

I also want to commend you for actively and knowledgeably correcting false assumptions posted regarding the panel so that the public has accurate information about the product.

@KirkM,

Do not get too much hope, do not expect too much.

The bug you have encountered and some other bugs AND the solution thereof has already been reported by many users and/or Product Experts, sometimes years ago.

It simply is not a guarantee that your issues get fixed by a micro-update.

Furthermore, the likely conclusion of Odin Team will be: issue cannot be replicated. Bug fix will not be issued.

Regards....

 

[trialotto]

@Alexey Baturin,

To be honest, your last post is humbug.

First of all, please read the rsync manuals and developer documentation.

Second, a question like "what common mail migration scripts?" should not be asked by a member of Odin Team.

Just Google my suggestion "larch" and you will find some documentation concerning the larch command line tool, allowing for very fast and easy (mass) mail migration, without any downtime on the source server and/or the target server, whilst still having the ability to run it as a background process.

Sure, I have to be honest: an asynchroneous rsync process of mailboxes will work just fine, no worries there (except for the problem that the Plesk Migration Manager can cause some issues when migrating mail data from differtent types of mail servers and/or mail server setups).

Third and most important: you stated

Please note that I always speak about Plesk Migrator shipped as Plesk extension in Plesk 12.5, not Plesk Migration Manager from Plesk 12.0.

and why are you, as member of the Odin Team, referring to the Plesk Migrator extension (!), if the original threadstarter KirkM (rather obviously) uses Plesk Migration Manager and reports an issue encountered with that Plesk Migration Manager??????

Remember, the threadstarter uses a Plesk 12.0.18 on the source server.

To be honest, I can continue with some comments that can be considered to be "bashing", but I will not.

It is just a specific way of giving feedback, to be summarized as:

- read the facts, between the lines of the original post by the threadstarter,
- read the intended question, since questions are asked, but not always the right questions are asked,
- isolate the issue on hand and resolve it.

To be more precise: KirkM (and many others) have tried to migrate across 12.0.18 en 12.5.30 Plesk versions and failed miserably, due to incompatability of migration managers in the two Plesk releases, as such a bug that should have been identified and patched, before Plesk 12.5.30 was released.

In short, when can Plesk customers expect the two versions of Plesk migration managers to be working flawlessly together?

Regards.....

 

[KirkM]

Do not get too much hope, do not expect too much.

The bug you have encountered and some other bugs AND the solution thereof has already been reported by many users and/or Product Experts, sometimes years ago.

It simply is not a guarantee that your issues get fixed by a micro-update.

Furthermore, the likely conclusion of Odin Team will be: issue cannot be replicated. Bug fix will not be issued.

Perhaps, but until that happens, and as long as the Odin Team is engaged and responding, I prefer to keep a little more positive attitude and let them prove my optimistic perspective wrong. Assuming failure only guarantees it.

Regards...

 

[trialotto]

@KirkM,

Glad that you are optimistic.

In reality, one can be optimistic, but one also has to be realistic: in the past, I have sent or proposed solutions for common problems, encountered by many Plesk Customers.

Some of them are still to be implemented, even after more than five years and even after having spoken to the persons responsible within the Odin Team.

That is really some food for thought, isn´t it?

And by the way, in the past I would have been glad to the migration for free, so you can focus on your business without any downtime.

In the present, I seem to have adjusted to the common statement of Odin that certain parts of development policy remain the same.

That is, the policy of "eyes and ears shut for bug reporting" and I sincerely hope that the change of this policy is still "work in progress in the background".

Anyway, no harm done in waiting: you just wait for a bug fix of the incompatability of the migrations managers in Plesk 12.0.18 and 12.5.30.

In the meantime, I will use the bug fixes we already have released on our servers.

Regards....