First, a discussion:
The issue of the internal backup not being suitable is still under some doubt in my mind and I think it is still possible. I will explain why:
When it is run, and you have selected messages (you must! for a migration), it writes out an XML file with all the details of the various records in the database (settings, domains, individual message details such as location, flags etc) and then Zips this XML file along with a data backup (copy) of the messages using 7Zip. Now, unless there is something hard-coded in the program that says "upon reaching a limit of X then stop/error" (which I doubt there is) I cant see why there should be an upper limit on anything other than OS-level filesize limits or disk space. The process is simply no different than if you were performing the option manually from OS level.
You have to be aware that for diskspace you will need at least enough space to make exactly one full replication of your current data directory (on whatever backup destination disk you are choosing) due to the 'copy' of the data prior to it being compressed PLUS enough space to then hold a compress of it (I guess the safest estimation would be to allow double of the current data directory.
eg,
DATA = 17gb
BACKUP DESTINATION will need:
copy = 17gb
+ Zip = (no more than) 17gb
TOTAL 34GB
(i reality perhaps the compress could be 20% less therefore only 13.6 (= 30.6gb total)
Now why do I mention all this above? Well because there is no other way of doing the migration. In order for a data restore WITH message details to be performed on the new system you WILL NEED that XML file with the message details in it. And unfortunately there is a contentious issue about this on the forum because it
seems (suggested by one of the developers) that without the messages included it sill simply wipe out your current data directory (on your destination install)
viewtopic.php?p=173859#p173859
SUMMARY:
You only have 2 options.
(A)
Your method would be:
1, BACKUP settings + account + Messages
WITH COMPRESSION
2, copy the backup file over to new server
3, Fresh install of HMS
4, do FULL RESTORE from the copied backup file.
nb: you wonderful rsync of data across Im afraid was a waste of time because upon doing a restore it will be deleted automatically.
I repeat MAKE SURE you do the the backup WITH MESSAGES and
WITH COMPRESSION. Otherwise the whole restore of messages will fail.
I see no reason why this method should not be successful although the time taken is quite lengthy (mainly due to the 7Z compression period of the messages).
(B)
The other alternatives:
Of course you could install MySQL on the new server for the sole purpose of running HMS and then you could simply use a MySQLdump and restore of the database and use you wonderfully rsynced message copy. Any quicker from the other method? Well, you do have to download and install MySQL, configure, and make sure it doesnt conflict with your MS SQL (would it??) :\
IN ALL CASES, irrespective of what method you choose... make sure you are installing the
SAME VERSION OF HMS on the new server for restore as was used on the old server for backup. (You can do HMS upgrade of programs after restore if you wish)
(The good thing is that because you are migrating to a new server you have the ability to abort and try a different method from scratch if it goes wrong without losing your original installation)
