• 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!
  • 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.

Xavier12

Regular Pleskian
Hey guys,

We are going to a dedicated server and are changing from one server to another. A part from Plesk migration manager, what would be the easiest way to migrate a complete server backup to a new server, with a new ip, to get Plesk back up and running 100%? We've tried Rsync in the past and it worked fine after using ip configurator for plesk to change to the new ip, but now for some reason when it was processed, Mysql does not want to start and Plesk does not want to run at all.

Please advise as soon as possible, thanks!
 
@Xavier12,

In essence, you should stick with Plesk Migrator (that is available on Plesk 12.5.30 boxes), given the facts that Plesk Migrator

- is rsync based (so there would be not a real advantage of using "manual" rsync)
- is doing a pre-flight check
- allows you to do some test runs and edit some settings (on the target server), before migrating

and a small tip would be: keep all "checkboxes" unchecked and (only) check the checkbox "Only manually selected resellers, clients and domains".

With the before mentioned tip, one can simply bypass all the checks and/or tasks that can be performerd after migration of data (read: this saves some time).

Also, another tip would be:

- migrate data on a subscription basis (read: select a couple of subscriptions and migrate)
- change DNS at the registrar´s DNS management system, in order to point to your new (target) server
- use an appropriate TTL (15 mins to one hour, dependent on the time that it takes to migrate all of the subscriptions)
- re-run the migration and select "mail" and "databases" (not selecting "web content"), in order to have an up-to-date migration at the target server, as soon as DNS propagates

and it might sound somewhat "elaborate", but the above mentioned "method" can work quite fast.

If this method is not fast enough (which can be the case, for many reasons): just do a manual rsync in the background, primarily of web content.

This "manual rsync" can speed up the whole process in two different ways:

- you can shorten the duration of migration processes (related to Plesk Migrator), since specific data (web content) is already on the server, (and)
- you can run the manual rsync for specific subscriptions, while Plesk Migrator is running migration processes for other subscriptions at the same time,

and you can imagine by now why it is relevant to use the "Only manually selected resellers, clients and domains" option.

Anyway, hope the above helps a bit.

By the way, if you have a VPS you could also consider to "restore a snapshot", but I would not recommend that (never!).

Regards.....
 
Hi Trialotto,

Thanks for the detailed update. Would make sense. For the migration, do subscriptions and plans migrate over as well? I remember going over a hurdle when restoring a Plesk installation in the past in this format. I believe it had to do with subscriptions and or plans not migrating as well.

Please advise, thanks.
 
@Xavier12,

What do you mean with "migrate over as well": do I have to read "migrate too" or "migrated well" (in the sense of "ok")?

Migration is fairly neutral with respect to subscriptions/plans: cross-platform and cross-version migration is working rather well (with the exception of some minor bugs, that can be ignored).

Just let me know.

Regards.......
 
Back
Top