• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • We are looking for U.S.-based freelancer or agency working with SEO or WordPress for a quick 30-min interviews to gather feedback on XOVI, a successful German SEO tool we’re looking to launch in the U.S.
    If you qualify and participate, you’ll receive a $30 Amazon gift card as a thank-you. Please apply here. Thanks for helping shape a better SEO product for agencies!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    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. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

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