I thought I would take the opportunity to remind everyone of the importance of backups. We had a very bad incident last week with a past client - Backpacking Queensland - where their hosting company has somehow been corrupted and they have lost their entire site - at this stage it would also appear they have lost the backup of the site also (we don’t know why this is; whether the backup was not being done properly or whether the backup has truly been corrupted as their main server has).

Unfortunately for Backpacking Queensland Xebidy had no ongoing relationship with them and so we were not holding any backups either, however, we do have the last beta version before the site went live and we were able to resurrect this on our own hosting solution. We will do our best to assist them in rebuilding their site as fast as possible.

Mat has also been able to build a script which retrieved all the page which Google had indexed and from there we are also hoping that we will be able to rebuild many of the pages this week.

Regardless the important point of this post is to ensure that either your IT staff or you hosting company are doing a backup properly. It is a very wise measure to test these backups regularly also. It is only when something has gone wrong do people actually go to their backup an find that this was not set properly or that something else was wrong with it.

We are Xebidy have certainly taken this opportunity to do a review of our own internal processes for out code and are setting up new measures. Make sure you are not the next to be caught out!

We have had an absolute comedy of errors getting Backpacking Queensland live over the last month - all that could have been avoided by a semblance of a helpful hosting company - unfortunately BQ used Web Central in Australia.

Firstly, it started well over a month ago when we contacted them regarding setting up the new site. We had all the FTP details and simply wanted to engage them in conversation regarding the hosting platform. When we enquired about Backpacking Queensland we were told that Web Central no longer hosted them and that they had moved away 2 years ago.

After nearly two weeks going back and forward with BQ, Tourism Queensland, Web Central and the previous developers it was found out that yes they do host the site and that the hosting contract actually is under the name Queensland Backpacking. Obviously really, seeing as they have a number of other domains names also registered there.

Once in and what should have been rolling we required an upgrade of the PHP version from 4.1 to 5.2. We communicate this with Web Central and are told that this is not a problem all the 2006 servers have PHP 5.2 and it would just be a case of moving this over, no cost. At the same time we also bring to light some of the other requirements, memory requirements, access to the cpanel and mod-rewrites. We wait a week - nothing happens. On chasing up WEb Central we discover that as their web developers we are not allowed to authorise this upgrade.

No problem, the guys at Gate 7 - the marketing company for Backpacking Queensland (and incidentally the place where the Web Central invoices are sent) authorises the upgrade and we wait a week. Nothing happens so we chase up Web Central again and are told that Gate 7 are not allowed to authorise the upgrade, only Tourism Queensland are allowed to authorise.

Finally, authorisation is organised and supposedly the upgrade is queued for 24 hours. Well over a week later and numerous phone calls and broken promises (such as - it will be done in an hour) an upgrade takes place - to PHP 5.0!

Back to the drawing board - fortunately, we have everything in emails saying that 5.2 is standard, no problem, blah blah blah.

Finally, the upgrade happens and when we log into the ftp site with the details given we get a Karate site sharing the same hosting. “We can see this is happening, but we don’t know why”. Get that sorted and their servers continually (read once every hour) lock us out of the FTP access. Only way around this is to lodge a ticket (the help service actually went down at one stage) and wait for it to be fixed. This must have happened at least three or four times - and all the time Alison at Gate 7 is continually on the phone to them trying to get resolution. The guys at Gate 7 have been amazing.

So, at about lunch time it looked like everything is sorted. We go to do a DB Build and there is no mod-rewrites enabled on the server and there can’t be because they are using IIS6. What a drama! It is not over yet - but this has been the worst and most unhelpful hosting experience of mine and the crews life and collectively we must have completed over 100 deployments.

We are now in the hunt for a better solution - fast!