Thread: What to do if your website goes down, backup plan

How about thinking of ways to prevent this from happening in the future?

Activate 2 hosting accounts on 2 separate providers. Make sure the providers are not just reselling space form the same datacenter. Basically get a hosting account in a datacenter in Texas and one in Connecticut.

Next on your domain registration list the nameservers as follows:

ns.nameservers-of-1st-provider.com
ns.nameservers-of-2nd-provider.com

This way if the first provider goes down your website and email will still be accessible. Any requests made for your website will first try the first nameserver which it will notice is down. It will then redirect the requester to the 2nd nameserver (the 2nd provider).

davet, I love your thinking, very good advice.

Wow, I never thought of that - nice advice Davet.

Another suggestion is to use a domain registrar like enom.com which include free DNS services with your domain registration... and always use their DNS servers, not the hosting provider's DNS. It's much easier to switch an A RECORD to point to a new host than it is to update nameservers. Changing nameservers on a domain registration can take 24 hours for the domain to propagate. If you use the DNS service that comes with your registrar you would simply change the A RECORD (& MX if you're using email) to point to the new host. The change takes effect within about an hour, sometimes minutes.

Get a better web hosting provider. That what I would do if it kepted on going down. If a site goes down often then it will lose alot of its value and traffic and money.

@Davet: Intriguing idea but how do you solve the problem of keeping the 2 different servers in sync with each other?
For example, if I post a new blog post, it will go into the database at provider #1 but provider #2 will not have that post in it's database.

If your hosts support remote mysql connections... you could setup a daily cron (autotask) to do a mysql dump (backup) & then restore it to the secondary mysql database/host. But this may leave you with duplicate posts every time you do the restore. I'm not positive on that until i test it. But if it did you could always have the cron delete the secondary mysql database, activate the database and then do the restore. This would only work if your secondary host supports command line mysql database creations.

This concept would update your blog content on the secondary host daily, not in real time.

It's possible, but would take some extra work & testing to set it up properly.

Originally Posted by davet

If your hosts support remote mysql connections... you could setup a daily cron (autotask) to do a mysql dump (backup) & then restore it to the secondary mysql database/host. But this may leave you with duplicate posts every time you do the restore. I'm not positive on that until i test it. But if it did you could always have the cron delete the secondary mysql database, activate the database and then do the restore. This would only work if your secondary host supports command line mysql database creations.

This concept would update your blog content on the secondary host daily, not in real time.

It's possible, but would take some extra work & testing to set it up properly.

Something like this would have to be done for the files too, since they may change while working on them, but I think you're on to something pretty cool here. As long as there isn't a lot of bandwidth taken, the more anal of us could change the cron job to every hour and that's a pretty robust system. It might even be worth getting 2 VPS systems in different datacentres and offering this as an addon to regular hosting services.

I'd like my servers setup as true clustered servers. I sadly have not worked on that yet, I however have started working with Cpanels dns cluster feature recently.
It allows me to use both my cpanel servers for name servers, should someone hit server A and it be slow or not get a responce for the name server it will hit server B for the info. This however does not help if the server the site is on is actually down.

Hopefully in the future clustering technology will be a bit easier for the common webmaster to implement.

Anyone with any experience on clustering servers?....

Originally Posted by Zap

Something like this would have to be done for the files too, since they may change while working on them, but I think you're on to something pretty cool here. As long as there isn't a lot of bandwidth taken, the more anal of us could change the cron job to every hour and that's a pretty robust system. It might even be worth getting 2 VPS systems in different datacentres and offering this as an addon to regular hosting services.

As for the files, you could setup a cron to FTP files from Host A to Host B. As far as running a cron hourly, you'd have to check with your host first. A typical shared hosting account is only allowed to run cron once daily. But you're right about the VPS, that or a dedicated server would be the way to go.

I've offered redundant services to customers before but many of them turn it down since they feel their site shouldn't be going down in the first place. They feel paying for an additional service because of problems with our uptime isn't justfiable. Many of them feel they shouldn't have to pay for reduandcy since we do have uptime guarantees but as everyone well knows problems do happen from time to time. Setting up redundancy to protect against a single point of failure is definitely a smart thing to do if you want true 100% uptime.

But that too still won't protect against performance issues. For example, if you only were using shared hosting accounts and another customer on the server was abusing it, you'd still be able to get to Host A, it would just be very slow. The redundancy wouldn't kick in until Host A was completely unreachable.

There's also MySQL reliability to think of. Let's say shared Host A's MySQL service goes down because another customer on the server is overloading it. The server at Host A would still be reachable but your blog would be down since MySQL isn't running an longer due to the abuse. The redundancy would not kick in since Host A's server is still technically reachable.

VPS or dedicated would decrease your downtime due to performance issues.

Redundancy would decrease your site's downtime if your primary site was completely unreachable.

Yeah. Most places offer a 99.9% uptime guarantee.
When you do the math, that's still 0.72 hours of downtime, each and every month.

Originally Posted by davet

If your hosts support remote mysql connections... you could setup a daily cron (autotask) to do a mysql dump (backup) & then restore it to the secondary mysql database/host. But this may leave you with duplicate posts every time you do the restore. I'm not positive on that until i test it. But if it did you could always have the cron delete the secondary mysql database, activate the database and then do the restore. This would only work if your secondary host supports command line mysql database creations.

This concept would update your blog content on the secondary host daily, not in real time.

It's possible, but would take some extra work & testing to set it up properly.

That will not work. If server1 goes down and your users posts start getting submitted to server2, there would be various threads and posts missing that is not in server2 yet, but is in server1. The posts that are in server 1 that is not in server2 has already used the available unique database table id's that has not been used in server2 yet. So if you then dump the server1's data into server2's database it will not go in as you will have different posts with duplicate id's as the new posts that are done in server 2 will use the unique ids that have already been used in server 1. Hope you get what I mean here. lol

The only way you can really do this is by some how making everything get submitted to both servers databases at the same time.

You will have to use the server1 as the main database which normally gets used and updated and you probably will have to then also connect to server2's database which can be done just like server1, but I think you would have to use the ip address of each server instead of the web address when it comes to connecting to each database. You will then probably have to open one database connection, submit the data, close that database connection and then open the next database connection, submit the data and then also close that database connection. Keep repeating it this way.

Not 100% sure if this is the best way though, but I would imagin it would work.

Originally Posted by john933

That will not work. If server1 goes down and your users posts start getting submitted to server2, there would be various threads and posts missing that is not in server2 yet, but is in server1. The posts that are in server 1 that is not in server2 has already used the available unique database table id's that has not been used in server2 yet. So if you then dump the server1's data into server2's database it will not go in as you will have different posts with duplicate id's as the new posts that are done in server 2 will use the unique ids that have already been used in server 1. Hope you get what I mean here. lol

The only way you can really do this is by some how making everything get submitted to both servers databases at the same time.

You will have to use the server1 as the main database which normally gets used and updated and you probably will have to then also connect to server2's database which can be done just like server1, but I think you would have to use the ip address of each server instead of the web address when it comes to connecting to each database. You will then probably have to open one database connection, submit the data, close that database connection and then open the next database connection, submit the data and then also close that database connection. Keep repeating it this way.

Not 100% sure if this is the best way though, but I would imagine it would work.

Yes I see what you mean. It's not a fool proof plan and was only a suggestion for static sites. It would work for MySQL as far as protecting against severe outages. Instead of having a day of downtime you would at least have a backup plan. You might lose some posts here and there but at least your site would be up instead of twiddling your thumbs waiting on your host to bring your site back online.

If there was downtime on Host A, you would basically need to know when Host A went down so you could then dump HOST B's mysql data back to Host A when it's back online.

MySQL does support redundant databases, but none of the blogging or forum software is setup to support it as far as I now.

It shouldn't be too expensive to get some programming guru to alter Wordpress (the blog of choice by a landslide) code to accomodate this.
And, this plan has the added advantage of zero downtime when switching web hosts because you can do one server at a time.

(I'm starting to think there might be some decent money to be made in this idea.)

I think my idea is good because you only have to connect to server1 when grabbing information, but to add information to the database then you have to connect to server1 and server2. This surely should be able to be done via your database connection scripts and a little modification in each script that connects to each database to add the data. Doing it this way may slightly slow down the adding of data as the same data has to be added to 2 databases at nearly the same time, but if one server goes down then you have the other server for backup and no posts or other information will be lost.

Another important thing is that you have 2 copies of your whole database. In other words you will have your full database data on 2 servers meaning that you will always have a backup if one server crashes and lose all your data you still have your database on the other server so no data is lost there either.

While the idea is to provide redundant service, it is not really viable for shared hosting given it would require quite a bit of programming on the website owners end before you would be able to attain the desired effect.

You could use RSYNC to continuously backup only those files and databases that are modified, however, as above, if the server goes down during a transfer, your out of luck.

This type of solution is a more viable solution if your using multiple VPS or Dedicated servers, even clusters.

Good advice Thanks for sharing. But if a person having a limited budget to run a webdite then it might be difficult to setup to hosting accounts isnt it. hy not use the hosting company uses daily backups like as hostingzoom.com.

Originally Posted by Muneeb2Good

Good advice Thanks for sharing. But if a person having a limited budget to run a webdite then it might be difficult to setup to hosting accounts isnt it. hy not use the hosting company uses daily backups like as hostingzoom.com.

It's been proven time and time again that we can't depend on our web host to save us. In some cases, the web host is the problem.

Hint: If I were you, I'd get my sites off of Hosting Zoom REALLY QUICKLY!
I used to host with them. NEVER AGAIN!

Instead, a webmaster has to take matters into their own hands to ensure that they have backups of all their websites. Don't store them on the web server, either. That is not enough. You need to have local copies of your sites on your computer at home. That way, if your web host goes out of business or starts locking up your websites for some stupid reason (as with Hosting Zoom), then you are prepared to jump to another web host and take everything with you on a moment's notice.

Thanks!

I didn't really know what they are for. I'll have to try this out, it's annoying when hosting goes down for a bit. Is there a way to somehow get an automated backup of your main host, and put it on your secondary host? That way if your main host goes down, the backup host has the exact same files to make sure it keeps running smoothly.

Thanks.. I'd thought about that and wondered how to go about it.

Originally Posted by rochow

Is there a way to somehow get an automated backup of your main host, and put it on your secondary host? That way if your main host goes down, the backup host has the exact same files to make sure it keeps running smoothly.

There is, implementing it however is a different story. It also is much easier if you have a static page, compared to one that relies on a ever changing database.

Originally Posted by grim

There is, implementing it however is a different story. It also is much easier if you have a static page, compared to one that relies on a ever changing database.

Directory? Will have lots of static pages, but has the database. Is paid and only has PR 2 at the moment, so not expecting submissions anytime soon

Would you use a chronjob? Or do I just have no idea :suicide_anim:

I've never done it tbh, you need to cluster from what I know. A directory however I could see running a backup server that only showed the approved sites. When you approve sites if you could tweak the directory script to write to an external data base. It could be done I'm sure, however way out of my realm of knowledge.

Originally Posted by grim

I've never done it tbh, you need to cluster from what I know. A directory however I could see running a backup server that only showed the approved sites. When you approve sites if you could tweak the directory script to write to an external data base. It could be done I'm sure, however way out of my realm of knowledge.

I got lost from the word cluster, so I think my directory will just have to deal with it if my hosting goes down!