Question about Moving C5 site to new host
Permalink
So we were having a lot of down-time issues with our current host provider so we have now purchased hosting through a different company.
What I want to understand is how it works to move a site while the site is in use. For instance, if I back up all my files and load them onto the new server and get it working good on the new one and then have my domains transfer over and such, it can take hours to a couple of days to do all that. At that point, how do I make sure I don't lose any registered users that have registered on my site in the day or so while I was transferring everything over. If I just do a fresh backup/install of the database will that do it, or are there other files that contain this kind of info?
I just want to make sure I have my ducks in a row BEFORE I dive in and accidentally mess everything up.
Thanks,
~Kari
What I want to understand is how it works to move a site while the site is in use. For instance, if I back up all my files and load them onto the new server and get it working good on the new one and then have my domains transfer over and such, it can take hours to a couple of days to do all that. At that point, how do I make sure I don't lose any registered users that have registered on my site in the day or so while I was transferring everything over. If I just do a fresh backup/install of the database will that do it, or are there other files that contain this kind of info?
I just want to make sure I have my ducks in a row BEFORE I dive in and accidentally mess everything up.
Thanks,
~Kari
If you need to keep your data in sync with minimal downtime, probably using a centralized database during the DNS update would be a good solution. Then after you're sure all the DNS servers have updated, you could change the database to local one for your new server.
This way you would have downtime in two spots:
1. When you initially setup the "shared DB" you'll need to put your site down to minimize data loss when you switch to the centralized DB (initial => centralized)
2. When you finally move to the final DB, the same downtime there (centralized => final)
Other options would include setting up rsyncing process but that is hard with relational databases (although it's doable with the correct amount of budget, e.g. whitehouse.gov might want to do this).
Best,
Antti / Mainio
EDIT: And with both options you also need to setup your old server to run a cron script e.g. every minute to sync any new files in the /files/ dir to the new server.
EDIT2: Just other thought that came to my mind regarding to the "centralized DB" option: actually you could even minimize your downtime even further from there if you just moved the DB straight to your new server. Then you would allow remote access to that DB for the old server during the DNS update phase. Then when DNS is updated over the world, only thing you'd need just to do is disable the remote access to the DB which wouldn't cause any downtime.
This way you would have downtime in two spots:
1. When you initially setup the "shared DB" you'll need to put your site down to minimize data loss when you switch to the centralized DB (initial => centralized)
2. When you finally move to the final DB, the same downtime there (centralized => final)
Other options would include setting up rsyncing process but that is hard with relational databases (although it's doable with the correct amount of budget, e.g. whitehouse.gov might want to do this).
Best,
Antti / Mainio
EDIT: And with both options you also need to setup your old server to run a cron script e.g. every minute to sync any new files in the /files/ dir to the new server.
EDIT2: Just other thought that came to my mind regarding to the "centralized DB" option: actually you could even minimize your downtime even further from there if you just moved the DB straight to your new server. Then you would allow remote access to that DB for the old server during the DNS update phase. Then when DNS is updated over the world, only thing you'd need just to do is disable the remote access to the DB which wouldn't cause any downtime.
And by the way I just answered like this because you asked how you can do that.
Usually it's not a big deal if the site appears to be "down" for an hour or two so if this was a case of mine, I'd just setup an index.html for the old site to state "the DNS is updating please check again in few hours". So I believe this is similar what citytech answered above.
Usually it's not a big deal if the site appears to be "down" for an hour or two so if this was a case of mine, I'd just setup an index.html for the old site to state "the DNS is updating please check again in few hours". So I believe this is similar what citytech answered above.
Thanks for your response. That does help me. There is another side of this same question still not fully answered though. So I'm talking about setting up this site to make sure it works and all, (we'll call the day I backup and load all my files and current db to my new server "Day 1"), and then a day or two later I'm ready to go through with the dns switch... (Say "Day 3") I still don't know what I have to do to get just the users that have come in since "Day 1"- like I asked above, is the data for them only in the database, or are there system files I will still need to backup again on "Day 3"
Again, in this situation I'm saying that I, as the sole web editor, will make zero changes to the "old" website during the time I'm setting up the new server - the only thing I'm worried about transferring over are any new users that came to my site since "Day 1".
Thank you!
Again, in this situation I'm saying that I, as the sole web editor, will make zero changes to the "old" website during the time I'm setting up the new server - the only thing I'm worried about transferring over are any new users that came to my site since "Day 1".
Thank you!
If you have an option to set the old site completely down I would do like this:
1. Set the old site down (e.g. c5 maintenance mode or .htaccess writing or pointing requests to other location on that server)
2. At this phase copy the whole DB and /files to your new server
3. Setup the DNS and wait for them to update
If you don't have the option to set the old site down, I would still set that down for that couple of minutes it takes you to transfer the DB to the new server and then setup the old site to use the new DB as well (my previous post about allowing remote access for the old server to the new DB).
So to be even clearer: once you're ready to do DNS change, at that time you'll need to make sure your new site's DB and /files folder are up-to-date, thus you'd want to copy any new changes to them to the new site once you're ready to do the update.
1. Set the old site down (e.g. c5 maintenance mode or .htaccess writing or pointing requests to other location on that server)
2. At this phase copy the whole DB and /files to your new server
3. Setup the DNS and wait for them to update
If you don't have the option to set the old site down, I would still set that down for that couple of minutes it takes you to transfer the DB to the new server and then setup the old site to use the new DB as well (my previous post about allowing remote access for the old server to the new DB).
So to be even clearer: once you're ready to do DNS change, at that time you'll need to make sure your new site's DB and /files folder are up-to-date, thus you'd want to copy any new changes to them to the new site once you're ready to do the update.
Ok, that makes sense. I guess I didn't get that part the first time.
Thanks.
Thanks.
This is the process that I've followed to move a live site from one hosting company to other.
Citytech