Jump to content

01-12-21: I'm Moving The Site Tonight


Eric
 Share

Recommended Posts

  • Administrators

I am going to move the site to the new server tonight, starting at approximately midnight. The changeover won't take more than an hour.

The first thing I will change is where the domain DNS will point. If you are trying to reach the site in around that time, you will likely end up at the new server before the site comes up. If so, you will see a message to that effect. If that occurs, you are good to go. You just have to give me a little time to bring up the site.

Once the site has been migrated, I will put up a message on the old server letting everyone who is still being directed to that server know that the changeover has occurred. I will leave some instructions covering what to do if you are still being directed to the old location. Almost all of the time, simply restarting your computer will square you away. If it doesn't, restarting your router and then your computer will fix things in all but a small handful of instances. Anyway, I will include my personal email so that anyone who has trouble can contact me directly.

For people who do not visit the site that late anyway, you will almost certainly be pointed to the new location tomorrow. If you are not normally on the site so late, tonight would probably not be the best time to start, unless you just want to be among the first to mark the new territory. Just keep in mind that you may have to do something to clear your DNS cache, so you can get to the new site. Like I said above, a restart usually is all that is needed. One of the settings for DNS is 'TTL' (Time To Live). That setting tells your computers how long the lookup info they have for my domain name is good for. After that time, your system should request a fresh lookup and will get the new information. I have been runnig that reduced TTL time for a couple of weeks. Having a short TTL setting will greatly reduce the number of people who have trouble finding the new site.

There are many highly technical issues involved with this changeover, but all that stuff happens behind the scenes. This should be a very simple transition for all of you. Most of you will probably not even notice that it has occurred. Like I said, I will leave some simple instructions for those that have any trouble and you will have my contact info. See you on the other side.

  • Like 2
  • Thanks 4
Link to comment
Share on other sites

4 hours ago, Batesmotel said:

We’ll need to speak to our wives. 

Can't!  Took mine to dinner tonight and plied her with too much Scotch.  So she is sleeping it off while murmuring apologies and promises to be a better wife.

Which is what my plan was directed to in the first place........  Yeah, I'm devious and mean. 

  • Like 1
  • Haha 3
Link to comment
Share on other sites

  • Administrators
Just now, crockett said:

Are you pointing the forum software on the older server to the SQL database on the new server via IP, in order to prevent content being lost?

I'll be turning the site off, dumping the database and transferring it. Trying to straddle two servers can be a PITA. Since both servers are hosted with the same webhost, the transfer speeds are very fast. The changeover will be quick.

Link to comment
Share on other sites

Just now, Eric said:

I'll be turning the site off, dumping the database and transferring it. Trying to straddle two servers can be a PITA. Since both servers are hosted with the same webhost, the transfer speeds are very fast. The changeover will be quick.

Makes sense, keeping it simple...

I should move my company's shop on a new server, but that will require updating EVERYTHING from apache to SQL, the shop software, a bunch of modules that all run on old PHP versions only, new interfaces, no thank you.

My long established IT rule: "Never stop a running system!" lol I had my fair share of through the night sessions, chatting nonstop with the guys in the data center, trying to work with freelancers simultaneously in different time zones, all in an effort to be done and up running again at 7 AM Eastern.

Good luck!

 

Link to comment
Share on other sites

19 minutes ago, janice6 said:

Can't!  Took mine to dinner tonight and plied her with too much Scotch.  So she is sleeping it off while murmuring apologies and promises to be a better wife.

Which is what my plan was directed to in the first place........  Yeah, I'm devious and mean. 

You are recording this,,,,,,,,,,,,,,,,right?

  • Haha 2
Link to comment
Share on other sites

  • Administrators
10 minutes ago, crockett said:

Makes sense, keeping it simple...

I should move my company's shop on a new server, but that will require updating EVERYTHING from apache to SQL, the shop software, a bunch of modules that all run on old PHP versions only, new interfaces, no thank you.

My long established IT rule: "Never stop a running system!" lol I had my fair share of through the night sessions, chatting nonstop with the guys in the data center, trying to work with freelancers simultaneously in different time zones, all in an effort to be done and up running again at 7 AM Eastern.

Good luck!

 

Server changeovers can be hairy on long-established systems. They become like that closet that is a few years past cleaning out without at least a partial cave-in and a couple animal bites. I think in your case, I would start updating services incrementally by version (Rather than just trying to jump to the newest rev) on the old server until you bring the box up to date, before migrating, Maybe transfer all the content to the new server as-is and keep that box as a hot standby, in case the old server shits the bed. When you get the old box up to date successfully, you can wipe the new box, set it up again and effect the transfer.

  • Like 1
Link to comment
Share on other sites

24 minutes ago, Eric said:

Server changeovers can be hairy on long-established systems. They become like that closet that is a few years past cleaning out without at least a partial cave-in and a couple animal bites. I think in your case, I would start updating services incrementally by version (Rather than just trying to jump to the newest rev) on the old server until you bring the box up to date, before migrating, Maybe transfer all the content to the new server as-is and keep that box as a hot standby, in case the old server shits the bed. When you get the old box up to date successfully, you can wipe the new box, set it up again and effect the transfer.

 

Ha, I wish that would be possible. I played through that chain 3 years ago. The shop software is not being patched anymore, for a while now, which is the biggest issue, so I'm forced to use the new version. And that requires the latest PHP and apache version. And those need much better hardware to run on. The shop has 7 or 8 modules installed from different companies, many of them written on old PHP versions that are long deemed unsafe. And at least 2 of those come from companies that are now obsolete, so I will have to write them myself or hire freelancers. I worked with freelancers from the US, Germany, Russia, Ukraine and India. In 90% of all cases it was a disaster and I ended up fixing their hardcoded crap. When I checked the last time, I wasn't able to update anything without running into said domino effect. Keep in mind, that all this is sitting on crappy Plesk. If I would update anything through Plesk, NOTHING would work anymore.

So I'm running incremental backups every night, and when the server gets hacked, I find the hole, patch it on the backup, and remove any foreign code by cloning / reconstructing the entire HD from the backup server. This happens about once every other year and takes me half a night.

Edited by crockett
  • Sad 1
Link to comment
Share on other sites

  • Administrators
8 minutes ago, crockett said:

 

Ha, I wish that would be possible. I played through that chain 3 years ago. The shop software is not being patched anymore, for a while now, which is the biggest issue, so I'm forced to use the new version. And that requires the latest PHP and apache version. And those need much better hardware to run on. The shop has 7 or 8 modules installed from different companies, many of them written on old PHP versions that are long deemed unsafe. And at least 2 of those come from companies that are now obsolete, so I will have to write them myself or hire freelancers. I worked with freelancers from the US, Germany, Russia, Ukraine and India. In 90% of all cases it was a disaster and I ended up fixing their hardcoded crap. When I checked the last time, I wasn't able to update anything without running into said domino effect. Keep in mind, that all this is sitting on crappy Plesk. If I would update everything through Plesk, NOTHING would work anymore.

So I'm running incremental backups every night, and when the server gets hacked, I find the hole, patch it on the backup, and remove any foreign code by cloning / reconstructing the entire HD from the backup server. This happens about once every other year and takes me half a night.

Sounds like a mess. I really hate Plesk, BTW. I have a different admin front end on my server, for convenience sake, but I do most of my work from the command line.

Anyway, I hope you have a good firewall parked in front of that box. One thing I would do (If you are not already) is use a geoip database to block every country that doesn't require access to your system. There isn't much server overhead using geoip. Good luck with it.

Link to comment
Share on other sites

  • Eric unpinned this topic
  • Eric unfeatured this topic

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Please Donate To TBS

    Please donate to TBS.
    Your support is needed and it is greatly appreciated.
×
×
  • Create New...