Archive for July, 2011

Why your backup attempts fail in cPanel and other control panel systems – your files can be the problem.

I’ve had the idea to write about this subject a few months ago, and left it on a post it on my desk. Luckily, I have just seen it and didn’t want to throw it away without posting something about it.

In these days, every single web host promises you that your data is safe and that they will backup your site every X days. While this is true, it’s not 100% sure.

Backup systems can fail (they do fail). What if? What if it fails for you?
What if your blog gets hacked, and there’s no backup to restore it from?

Did you even think about that scenario? It happens to hundreds of people. Why shouldn’t it happen to you?

No one is special in technology. It can fail for everyone (look at NASA for example, technology fails for them too). If you care about your website (and your email) you should back it up at least once a month, or once a week if you update it too often.

Most control panels out there will offer you an easy and convenient way of generating/downloading full backups for your website. This should be a 20 minute operation (between the generation and downloading).
Now here’s the tricky part  -  and also why many webmasters do not download a backup of their site every month or every week:

Your site is too large!

I have been a consultant in this industry for a long time, and I know for a fact that most websites do not use over 500M to run, in any circumstances. The problem here is, that webmasters neglect the “file sharing” problem.

You’re given 5GB or 10GB to host files, so you intend to use them for file storage. After all, it’s what you’re paying for, right? Not really.

It’s complicated to talk about it. Web hosts offer that to compete with each other. It’s a normal marketing strategy. A responsible webmaster will not use nowhere near that because having 10GB in files on a site will ruin any self-backup attempt by the website owner.

There are other ways of storing your files online. Let’s say you are a Disc Jockey and want to share your “sets” with everyone. Your main web hosting account is certainly not the best place to upload your files to.

Sure, it’s nice to have a link attached to your set such as djrocknroll.com/setxxx.mp3 but this will add inconveniences to you, such as not being able to generate a backup without a headache, or without having to wait 6 hours for it.

I rarely point at a problem without providing an option to evade it, so here’s what I recommend:

If you need to host files (large files), setup a separate hosting account and use a subdomain for it. For example, files.yoursite.com. Your web host will know how to do this for you. That way, you can separately backup both your files and your site, without having one interfering with the other.

Please note that I am not referring to subdomains. A Subdomain is usually hosted within the same user home directory, so this will not do any good. Ideally, a separate account is recommended.

If you have a reseller or a multi-site account, you can take advantage of it by creating a new account just for the purpose of storing your files. If you do not have this possibility and cannot afford a new account at your current host, you can always find a cheaper web host just to deal with your “downloadable” files. Assuming that your email and website content is more important than your files, you should always make sure that your main hosting account is clean. Never use more room than you need to.

That way, you will be able to generate/download backups every time, with no delays or hiccups. This is valid for almost every control panel system. Whether it’s cPanel, Plesk, DirectAdmin or anything else… if your account is flooded with files, the instant backups will not work as you expect.

Using Windows’ “hosts” file to avoid downtime when switching web hosts

I do have a lot of people asking me what’s the best way to transfer their website from a web host to another without any downtime. While I think this is almost impossible (at least coherently and without anyone noticing it), there are a few tricks that you can use to minimize the downtime.

One of them is to use the Windows HOSTS file to prepare everything at the new web host.
The HOSTS file, is a basic text file that allows you to override your DNS server settings. By having a web address in there, you will make your PC ignore any DNS Resolution (it won’t even try to resolve the address) – Instead, it will use the IP Address you supply in the HOSTS file.

Think of that file as a “God Mode” in DNS.
Whatever you wrote there, will be the absolute path for a given domain name.

So, when you’re moving to a new web host this becomes handy, because you can simply make your PC resolve your URL to the new web hosts’ IP address, without having to change your domains’ nameservers. The advantage here is that you will be able to preview your site *exactly* as it will be functioning at the new location without risking a DNS change; along with its side-effects if it goes wrong (having to change it back to the previous host because it’s not working as expected, etc).

 

So let’s say you’re moving from WEBHOST1 to WEBHOST2.
The very first thing you must do is to find out your website’s new IP address.

This is an information that is usually sent to you by the new web hosting provider through a “Welcome Email” along with other useful technical notes about the new account. If this isn’t the case, simply ask your web host (WEBHOST2) what your IP address will be.

Once you have that information, you can move on to the next step – editing the HOSTS file.
By default, on a standard setup; the HOSTS file is located at the following location:

Windows 95, Windows 98 and Windows ME: C:\Windows\Hosts
Windows NT/2000: C:\WINNT\system32\drivers\etc\hosts
Windows XP: C:\Windows\system32\drivers\etc\hosts
Windows Vista and Windows 7: C:\Windows\System32\drivers\etc **

 

** Under Windows Vista and Windows 7, you will need to open this file using the option “Run as Administrator” in order to prevent issues when saving your file. (you won’t be able to save the modified file if you do not use this option)

Since this file has no extension, you will most likely be asked which program to use to deal with the file. Select NOTEPAD or WORDPAD as an alternative.
Once you open it, you should have the following (or at least similar) text:

# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a ‘#’ symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host
 
127.0.0.1 localhost

 

On Windows Vista/Windows 7, you might be missing the 127.0.0.1 entry.
This is because both Operating Systems do not need such line there, the localhost entry is handled by the DNS client directly.

You will instead see a few extra lines replacing the first entry, such as:

# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost

Moving on, let’s say your domain name is “myblog.com” and your new web hosting IP address is 74.74.74.74 – where is the entries you would need to add to this file:

 

74.74.74.74 myblog.com

74.74.74.74 www.myblog.com

So, to summarize, you would have a file similar to this one:

# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a ‘#’ symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host

74.74.74.74 myblog.com

74.74.74.74 www.myblog.com

This will order your PC to not even try to resolve the domain name, but to use the IP you specified instead. Once you save this file, your domain should start to point to the new IP immediately. If you want to make sure it’s happening, a good way to do it is by performing a PING test on your domain.

To do so, just open a new Command Prompt window (by going to Programs/All Programs –> Accessories –> Command Prompt), and typing the following command:

ping www.myblog.com

Then wait for the output. If you get the new IP address, that means you’re ready.
Upload your website to the new host, restore any databases you need to have working and test it on your PC. The best part is that no one will notice any flaws on the new host – only you will be able to see them, as the rest of the world will still be using the current/old host to retrieve your content.

Once you’re fully satisfied with what you see on your domain, you can safely change your nameservers (pointing them to the ones you have been provided by WEBHOST2) without risking anything – because you have tested it all beforehand.

IMPORTANT NOTE:  Once you are satisfied with the results and are ready to change the nameservers, make sure you remove those 2 lines from your HOSTS file. You will no longer need them, and having them there can cause problems in the future (for example if for any reason your web host has to change your IP address… This seems unlikely but it isn’t. There are many valid reasons to change your IP, such as installing a SSL Certificate!)