I'd like to replace a server with a new box and new OS and migrate the old ISPConfig to the new box using the Migration tool. that requires both servers be on the network at the same time. I'd like to have the new server get the old server's IP address when done. Is it a non-trivial thing to just change the IP address of the server after all the install and configuration stuff is done, but before the migration? Is it better to change said IP address via the ISPConfig interface (if that's even possible) or just from within the OS? Does ISPConfig retain that IP address anywhere that it will need to be changed later? will it self-recognize it's changed and update itself accordingly? is it better to change the both server's IPs before or after the migration? I'll clearly have to take the old server offline prior to the migration (I think, so it's not missing new data during the transfer). Maybe its best to set the new server to a temp IP, change the old server to another temp IP, do the migration, change the new server to the original IP, and it'll all be happy? I've not had to do this before, but keeping the IP seems like the easiest considering all the other changes elsewhere that will need to be made to accommodate the new server otherwise. Thanks.
If you let the sites listen on "*" on the new server, changing the IP after the migration is no problem. You can add it to the ISPConfig UI after, but don't use ISPConfig for the network config itself. I'd change the IP after the migration. You can do a data resync after the first migration run. What I usally do is this: - First migration tool run - Resync data with migration tool - If that resync takes long (e.g. you did it hours/days after the first run of the tool), run a resync immediately after - Immediately after the resync, shutdown services (apache2/nginx, postfix, dovecot) - Resync immediately. - Enable a proxy to route traffic from the old server to the new server. After, create the network config, bring down the interface on the old server, and bring it up on the new server. This is the easiest way to migrate without data loss and without too much downtime. There are better ways with no downtime, but they usually require more time put into it, for most of my use cases it doesn't matter if the services are down for a few minutes if necessary.
can I get some rough idea of how long it takes to migrate a domain - say it has 200MB of web data and 1 email account with 200MB of emails? i did check and the domains to be moved are all set for an IP address of "*", so looks like that will be easy enough. Just to clarify, is it safe to assume that the tool essentially rsyncs (used loosely) data between the two servers, so the first run will take a while, but subsequent runs will only copy new data? also, does the tool do just one domain at a time, a selectable group, or all domains at once? is it a command-line tool, or part of the ISPConfig interface? Thanks for the info
It highly depends on the speed of your servers, the load of the source system at the time of migration, and the speed of the connection between them. So the speed is very individual for your situation and one can't make a general assumption about it. The tool migrates (imports) the config via REST calls over https, then the new system processes them to create the required config files and then the tool moves the data via rsync. When using --resync option on subsequent runs, only data gets migrated again with rsync. As rysnc is capable of incrementally copying data, a subsequent run can be very fast. I've seen resync run times from under a minute for a system with about 80 mail accounts and about 60 GB of email data.
okay, so revisiting this post, as I still haven't gotten around to getting this done. I just downloaded the latest 3.1 manual, hoping that something from my earlier copy had been clarified, but it hasn't, so i'm going to ask for clarification. Mirror Server Setup, Page 64 - at the bottom of the page, it's giving instructions to perform on Server1, and on Page 65, we end up at the end of the Master-Slave configuration setup (still on Server1). The next paragraph starts on converting that to a Master-Master configuration, and the instructions have not told us to change servers, or indicated which server we should be on. However, it would appear the slaveuser2 commands should be done on Server2, but the instructions don't indicate we should switch to Server2 until after those slaveuser1 instructions are given. So am I correct that the slaveuser1 instructions should be done on Server2 (since the slaveuser2 instructions were done on Server1)? and on the topic of Mirror Setup in general - I assume this is intended for backup/failover/redundancy purposes only. I also assume that the rsync should be one-directional, and that Server2 should not be used as a live server while Server1 is alive (seems like that would require a 2-directional rsync, which seems problematic). The description of the mirror setup talks about how it could be used, but doesn't talk about how it shouldn't be used. Thanks. [edit: typo]
