• Introducing WebPros Cloud - a fully managed infrastructure platform purpose-built to simplify the deployment of WebPros products !  WebPros Cloud enables you to easily deliver WebPros solutions — without the complexity of managing the infrastructure.
    Join the pilot program today!
  • Support for BIND DNS has been removed from Plesk for Windows due to security and maintenance risks.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS.

Input Migrator waits for backups. Suggest it be the other way around.

websavers

Regular Pleskian
When running a Plesk Migration task, if an existing Plesk Backup runs on the source server, the migration utility sits there waiting for that backup to complete prior to starting the migration. Worse yet, if you're in the middle of a migration of an entire server, it batches the migration tasks, usually in groups of 5 domains, meaning Plesk Migrator can get stuck in the middle of the migration if a backup is started on the source (either manually or on a set schedule) mid-way through the migration, thus delaying the migration considerably.

Rather than the migration utility waiting for backups to complete, I suggest that when a migration is in progress, all backups be put on hold until the migration has completed.
 
This is a good point. I think the reason for this behavior is that Migrator and Backup are the same software. Have you checked that you have an "unlimited" number of threads allowed for backups in backup manager? This could be one reason why an existing pmm process keeps another one from running.
 
This is a good point. I think the reason for this behavior is that Migrator and Backup are the same software. Have you checked that you have an "unlimited" number of threads allowed for backups in backup manager? This could be one reason why an existing pmm process keeps another one from running.
Good thinking. It's set to 1 to keep load down during normal usage. This was my last migration where this is likely to be an issue for some time, but will definitely try increasing that value for future cases.

If that value really does affect the migration, I think perhaps the migration manager should auto increase that value to at least 1/2 the number of cores on the box prior to beginning the migration, then set it back to the original value when it's done.
 
Back
Top