Plesk Migration Advice

[chrismcb]

Hi all,

I'm moving two servers to new platforms with the same OS and Plesk versions (6.5 and 11.5 respectively).

I've performed a test migration which has taken almost 6 hours to complete and am looking to reduce this time.

Is there anything anyone can suggest to do this?


My plan was to disable the httpd and qmail services while this transfer took place, but this is just too long to be down for.

Alternatively, I could perform a full migration earlier than expected, disable FTP to ensure no files are changed and then manually migrate only the database and mail directories while the services are down.


Anyone have any experience in keeping the downtime as close to zero as possible whilst ensuring all data is retained?

[chrismcb]

OK, I've been looking further into it and thought I'd keep this thread updated for posterity.

Dumping the mysql databases (excluding the Plesk and mySQL specific ones), zipping it, transferring, unzipping and importing works perfectly and can be done in just a few minutes.

Old server

Code: Select all

# mysqldump --user=admin --password=`cat /etc/psa/.psa.shadow` --host=localhost --databases [DATABASE NAMES IN HERE, SEPARATED WITH A SPACE] > /tmp/migration.sql
# cd /tmp
# zip migration.zip migration.sql

...transfer how you wish...

New server

Code: Select all

# unzip /tmp/migration.zip
# mysql -uadmin -p`cat /etc/psa/.psa.shadow` < /tmp/migration.sql

The method I was planning to use for migrating the mail used Plesk's Backup Manager and the following code:

Code: Select all

/usr/local/psa/bin/pleskbackup server --only-mail --output-file=/tmp/mail.dump -v

This works fine and completes OK.
I then copy that to the new server and try:

Code: Select all

/usr/local/psa/bin/pleskrestore --restore /tmp/mail.dump -level server

Which fails with:

Code: Select all

Unable to resolve all conflicts

Plesk's forums then suggest going into the Backup Manager page in the panel to continue.
It shows the backup listed in there and allows you to restore it, however it then asks to map IP addresses, as the migration manager does.
The problem is, there are no IPs left to map, since the initial migration has used them - it will not simply use the current data.

Has anyone had any experience in this?

Alternatively, would a zip->transfer->unzip of /var/qmail/mailnames be sufficient?

[chrismcb]

Further research has led me to an article which talks about moving the mail dirs specifically:

http://major.io/2007/01/27/moving-mail- ... k-servers/

From this, I have adapted it slightly to backup all users mailboxes:

Code: Select all

tar -pczf mail.tar.gz /var/qmail/mailnames/*/*/Maildir/cur /var/qmail/mailnames/*/*/Maildir/new /var/qmail/mailnames/*/*/Maildir/tmp

It can then be copied to the new server and:

Code: Select all

tar -pxzf mail.tar.gz
yes | cp -rf /tmp/var/qmail/mailnames/* /var/qmail/mailnames
chown popuser:popuser /var/qmail/mailnames/*/*/Maildir/cur --from=root:root
chown popuser:popuser /var/qmail/mailnames/*/*/Maildir/new --from=root:root
chown popuser:popuser /var/qmail/mailnames/*/*/Maildir/tmp --from=root:root

The archive contains absolute file reference and, despite using the -p flag, permissions are not kept

Questions

• Is this process acceptable? Is there anything I'm missing here?
• There are other files within the maildir directories, are they specifically required?
  • @attachments (dir - empty)
  • courierimapkeywords (dir - empty)
  • courierimapuiddb
  • courierimapsubscribed
  • courierpop3dsizelist
  • maildirsize

Bear in mind that a full migration would have occurred a few hours earlier, this is just to catch the stragglers, so the above files will already be there, but may not be 100% up to date, depending on traffic.

Thanks