FAST Plesk Migration/Upgrade paths: Any Ideas ?

[tactics]

I'm trying to figure out the best way to migrate a plesk installation from one server to another with the shortest possible downtime while ensuring source and destination server are consistent.

I'll describe my current situation below, but I believe these questions are interesting to everybody wanting to migrate a plesk server.

So this is my situation :

- I've got a RH9 server with Plesk 7.5.3
- I need to upgrade it to RHEL 3.4 for several reasons (not in the least: bugfixes and recent packages)
- I don't want to upgrade the OS on-the-fly, at least I haven't seen anybody recommending this.
- I want to keep downtime very limited (much more than an hour downtime is unacceptable, even at night)

So thought to migrate in three steps (spread over three nights):

- migrate from production server to a temporary server;
- reinstall production server with new software
-migrate from temporary to production again.

Problems:
- A psadump takes about 2 hours: resulting in a 12GB zipped backup.

- I tried restore: it took over 8 hours on a fast test machine. (restoring data takes 2 hours, checking and fixing another
6 hours !)

- I need to shutdown FTP and Plesk Admin between start of backup and end of restore (over 10 hours).

- I need to manually migrate databases again after restore because they have changed during those 10 hours

- I need to migrate mail again for same reasons.

- In the end it also seems a problem to simply swap machines as I want the IP address to be the same on both machines (I switch the cable so both machines are never online at the same time) because of router issues (different MAC address, same IP...)

- If I change the IP, I need to change DNS entries which again causes problems of clients connecting to both machines at the same time (ns record ttl).

-----

Thus, the question should be clear: what migration paths are other admins using, what tricks do you use to minimize downtime and maximize consistency between source and destination server ?

 

[Cranky]

The quickest solution using psadump (IF you have a fast network connection between the existing server, and temporary server) is to let Plesk stop all services on source server, run a simultaneous backup/restore so that there's no spare time wasted, and use --no-internal-zip flag with gzip also disabled. This will increase data transfer between the two servers, but the CPU won't be killed by the intensive compression/decompression processes.

psadump/psarestore is slow, there's no doubt about that, but *usually* it works fine.

 

[tactics]

Thanks for you input Cranky !

I have considered this, but this would still leave me with a downtime of 8 hours straight, right ? I guess you can see this is intollerable to most of our customers. Business users need 100% uptime during working hours, while all other users are using their websites/ftp/mail during all other periods.

There should be a solution that takes only a very limited downtime, right ?

I'm thinking: moving data to a 3th server (should take no more than a few minutes as where using Gbit networks everywhere) and only migrating configuration from 1st to 2nd server ?

Additional ideas ? Anybody ?

 

[Cranky]

Hi,

The only way to guarantee a truly consistent migration of all data is to live with the downtime. With --no-internal-zip and --do-not-dump-logs (if you can live without logs being transferred) enabled, and gzip disabled, you should see an improvement in the speed particularly on a GigE network, but downtime is inevitable.

I'm not sure about your customers, but in general ours are sympathetic and happy enough to live with the downtime if it means a higher level of service afterwards, and as long as we give enough time. This is my situation though, you may well be different and I respect that.

A well planned migration should minimise downtime, just make sure you notify your clients well in advance.