Site Contingency and Redundancy

Today's post will cover contingency and redundancy, of which we've learned the hard way over time running TorrentFries. Backups are crucial to a holistic approach on contingency and redundancy, but there’s more. By the way, I’m OnionRings, the “fellow admin and general Linux and security geek.”

If you’re just beginning a site, hardware redundancy isn’t possible since you will likely have a shared or dedicated server host, but there are a few other areas of redundancy to think about. Attack issues of redundancy and weaknesses before they occur and in the order of likelihood. In the case of TorrentFries, the most likely thing to happen is for a host to get a copyright infringement notice.

Selecting a host that’s least likely to take fright in a copyright notice is the best choice to reduce risk of downtime, but that can be difficult to know right away. We’ve often asked our hosts what their policy on copyright material was before moving to them. Usually they are happy to take your money up until they receive a notice.

In the past, a host has given us 12 hours notice to remove material before the server would be shut off. That might sound like a lot of time, but when they issue them at 5 am in your time zone, it could be a few hours before you even notice the warning. At that point, you need a new host quickly. Therefore, select a host or two that would be sufficient while you have the time to research it and before you get a takedown notice. It can take days for a hosting company to get you login credentials much less the time it takes to research your best option. Plan ahead.

TorrentFries was once put out of commission after receiving an infringement notice while our host and the domain registrar were the same company. In that case, we were locked from our account and couldn’t even redirect our domain to the new server we purchased. So if uptime means anything to you, register your domain with a different company than you host with.

Short of having an expensive hot spare server wasting CPU cycles somewhere, there are other ways to mitigate risks of takedown. Parceling out the server’s work to subdomains that reside on different hosts is one way to achieve better contingency. In this case, put the tracker announce and scrapes on a separate server than the main site so the tracker doesn’t go down if the main site is taken down. Leveraging this technique can be a handy method to keep staff communications up during downtime where forums, email, or Jabber are critical. If set up with some thought, your database latency won’t take a huge hit and purchasing a couple cheaper servers might be only slightly more expensive than buying one powerful server.

Finally, there’s quite a bit of rework involved in installing and configuring software each time you move to a new server if you’re on a VPS or dedicated server. Even though I’m a Linux geek, I have to look up some things that I don’t use everyday. It’s nice to have a list of the tutorials you’ll be using or a checklist of the things that need to be done starting from disabling root SSH login and ending with the final tweaks in Apache or MySQL configurations. If you’re savvy enough, write up a bash script to handle all those dull tasks.

Hopefully your site will learn from some of our mistakes and you’ll be able to keep your uptime positive.