Dear all,
The migration & transfer tool and the possibility to re-sync after an initial migration are great. I am currently using it to configure and test a new server while the old one is still running, doing re-syncs once in a while to keep the new server up-to-date, thoroughly check some things on it manually, and to keep the amount of data small that will need to be transferred on the final re-sync before going live with the new server.
While doing this, I discovered an issue that might be easy to fix: When doing a re-sync, ALL files under /var/qmail/mailnames/{domainname} get a new "change time" as reported by stat, even if they (and all their stat attributes) are not modified. I suspect the reason is a command like
(or a similar blanket command) that is run by the migration re-sync at the end of the transfer, which is a no-op for many files (if, e.g., for the command above, a file is already owned by the correct user) but resets all the change times to the current time.
This behavior is problematic if the change time is used to detect changed files for incremental backup purposes (as is also done by the native Plesk backup), since the complete mailboxes will be backed up after every migration re-sync. This could be easily avoided if the chown (or whatever causes the updated change time) is only applied to files for which it is necessary.
Just for curiosity: For the website data under /var/www/vhost/{domainname}, the issue is not present, so apparently no blanket command with the side effect of updating change time is executed. So the behavior is also slightly inconsistent.
Best regards,
Philip
The migration & transfer tool and the possibility to re-sync after an initial migration are great. I am currently using it to configure and test a new server while the old one is still running, doing re-syncs once in a while to keep the new server up-to-date, thoroughly check some things on it manually, and to keep the amount of data small that will need to be transferred on the final re-sync before going live with the new server.
While doing this, I discovered an issue that might be easy to fix: When doing a re-sync, ALL files under /var/qmail/mailnames/{domainname} get a new "change time" as reported by stat, even if they (and all their stat attributes) are not modified. I suspect the reason is a command like
Code:
chown -R popuser:popuser /var/qmail/mailnames/{domainname}
This behavior is problematic if the change time is used to detect changed files for incremental backup purposes (as is also done by the native Plesk backup), since the complete mailboxes will be backed up after every migration re-sync. This could be easily avoided if the chown (or whatever causes the updated change time) is only applied to files for which it is necessary.
Just for curiosity: For the website data under /var/www/vhost/{domainname}, the issue is not present, so apparently no blanket command with the side effect of updating change time is executed. So the behavior is also slightly inconsistent.
Best regards,
Philip