I’ve regularly returned to this LaCie drive over the last year and a half, because it housed some unessential data for which I had no back-up of. I’ve always hoped I could one day find a way to get at it again.

So, I returned to the unit again a few days ago, expecting another bout of brief head-scratching, followed by consignment of the device to the cupboard until the next time my curiosity auto-piqued.

This time, I decided to completely dismantled the thing. Why worry about rendering void an expired guarantee?

I thought I’d been hearing the drives spin up during my irregular tests over the last eighteen months, but what I’d actually been hearing turns out to have been the sizzling of the power adapter block. Seriously, up close, it sounded like bacon being fried, but from a distance, the sound was inseparable from that of spinning drives. Anyway, the drives themselves, as it turned out, were silent when I put my ear next to them. A good sign, to be sure.

I hadn’t previously suspected the power supply, because the blue light on the front of the drive housing was illuminated, as were the LAN lights at the back. This obviously meant that the drive was receiving electricity, at which point I ruled out the power supply as the possible cause of the problem. That left only the hard drives themselves and if those were buggered, well, game over, right?

A quick Google search now revealed many more similarly broken drive units than when I had first looked for others afflicted with this ailment back in June of 2008. Lo and behold, many people reported the same sizzling power supply problem, and the fact that the unit hadn’t completely shuffled off its mortal coil, but merely declined to the point that it could now power only the lights on the casing, not spin up the discs inside. Another very good sign!

I wish I had realised earlier that it was only the power supply at fault. I hadn’t even contacted LaCie at the time, believing the unit to be no longer under guarantee, its being just over a year in my possession. I also didn’t realise that a power supply unit could partially die and then stabilise at some drastically suboptimal level, the way many LaCie units apparently have.

It turns out that LaCie actually offered a two year guarantee on units back then (in Europe, at least), so I should have contacted them. If nothing else, they would have replaced the drive.

More likely, they would have known what was wrong and just supplied me with a new power supply free of charge. More fool me for not looking into it.

Incidentally, in case you run into a similar problem, you should be aware that LaCie currently offers a three year guarantee on new drive units.

I opened a ticket with LaCie, but they were adamant that they wouldn’t help me, because the drive is all of 2½ years old now. My retort that it had died when it was only one year old cut no ice with them.

I would have liked them to demonstrate a little more understanding, particularly in view of the fact that so many other users’ drives have had exactly the same problem, but they’re obviously not that kind of company. Some manufacturers will bend over backwards to help any customer with a problem, whether the unit is still under guarantee or not — just in the name of good customer service — but that’s only some companies; not LaCie.

Now almost certain that only a faulty power supply was standing between me and my old data, I bit the bullet and ordered a replacement from the LaCie Web site. At least they actually sell the accessory on-line. I had half expected it to not even be separately available, which would have been a problem, because it has a strange, proprietary four pin connector that meant no-one else’s adapter could be substituted in its place. Why do companies do this? I’m unpleasantly reminded of the 1001 different charger connectors that Nokia mobile phones have sported over the last fifteen years.

Anyway, for around €40 plus postage, I ordered a new 57W adapter. To LaCie’s credit, they did at least send it promptly.

Once it arrived, I plugged in the unit and, sure enough, the drives span up again.

A switch port mirroring and tcpdump session was required to figure out which IP address the thing was attempting to latch onto, and then I was able to log in and configure the drive again.

With that done, I took it down to the equipment cupboard and connected it to the UPS and core switch.

The next twelve hours saw the ReadyNAS pulling 56 Gb of data off the LaCie, where it’s now better protected against the vagaries of cheap consumer electrical goods.

I feel pretty daft for having remained in the dark for so long about such a trivial problem and its equally trivial fix, particularly as it ended up costing me not only time without my data, but also money for a new power supply.

I was even wrong about this being a single drive unit. Opening it up revealed two 320 Gb drives, not the single 640 Gb drive I was expecting to find.

The irony is that I currently actually need a USB drive for the purpose of back-up, but this one can only be connected over Ethernet. I wouldn’t really mind, but I have to mount this drive over CIFS, which is less than ideal on an almost exclusively UNIX-like network (and especially when you consider that the LaCie unit actually uses XFS internally). The drive has a USB port, but annoyingly, it can function only as a USB host, which means that you can connect other devices and have the LaCie present them for use, but you can’t make the LaCie subordinate to another device that is serving as a USB host.

Since I’ve already got two ReadyNAS units in the house, one of which has an external Seagate drive connected over USB, I’d like to connect the LaCie to the other one. If both devices can only host other USB devices, however, doing so isn’t going to get me anywhere.

The problem is that most forms of back-up that it provides for don’t support the deletion of files that are no longer on the source. For example, if file A and B were backed up last night, but file A was deleted on the source by somebody this morning, tonight’s backup should back up only file B (and even then, only if it has since changed) and delete file A from the back-up destination.

This level of control calls for the common free software program, rsync, to be used for back-ups. The ReadyNAS does support rsync, but Netgear’s interface to it via the Web-based FrontView software is less than ideal. That’s because it doesn’t allow one to specify the use of rsync’s many optional flags and parameters. In particular, it doesn’t allow the essential --exclude flag to be used to omit certain directories from the back-up. I’m not being picky; I actually have a back-up job that will fail without the use of this flag.

Happily, though, the ReadyNAS is Linux-based and Netgear nowadays provide an EnableRootSSH patch, which will, oddly enough, allow you to ssh into your ReadyNAS as root.

I’d been resisting the temptation to do this for some time, because I had no good reason to do so. The ReadyNAS is sold as an appliance and one isn’t really supposed to go prodding at its internals. The potential for rendering one’s device non-functional is definitely there. Of course, I know what I’m doing (famous last words, I know), but I still have a healthy respect for devices supposed to operate as black-box appliances.

Nevertheless, I needed more flexible rsync functionality for my back-ups. An alternative to poking around on the Netgear would be to schedule the back-up jobs on the clients themselves, pushing the data to be backed up to the ReadyNAS instead of having the ReadyNAS run the back-up job and pull the data from the clients.

I wanted my back-ups centralised, however, so I installed the EnableRootSSH patch and went gently wandering across the file-system.

I found what I needed and was able to add the functionality I needed with 15 lines of Perl. Now, it’s possible to define a set of extra options to be passed to an rsync back-up job when it’s invoked.

I’ve posted details of how to do this to Netgear’s ReadyNAS forum, so I won’t repeat them here. I mention the hack here only to gain a bit of publicity for it, as I’m sure I’m not the only person who needs this extra functionality.

Of course, a much better solution would be for Netgear to integrate this into their FrontView Web-based interface. I’d much rather be able to use the supplied tools than have to resort to hacks like this.

Still, at one level, it is nice that Netgear have allowed this kind of thing to be done. It encourages experimentation, development and user community growth.

Of all the stuff I’ve written, this is possibly the most obscure and least useful to anyone else (of course, I’ve said that before and been wrong). Nevertheless, necessity is the mother of invention, and I need this program, so I’ve been working on improving it over the Christmas period.

Specifically, this new version uses some heuristics to try to derive a subtitle for the programme in question. Ideally, this should be the episode name for a series, the destination city/country for a travel programme, etc. Sometimes, UPC includes this kind of information as part of the programme’s description, but programmatically determining whether the first sentence of the description is suitable for use as a subtitle is a tricky business; hence the many man hours that have gone into the 0.5.0 release, as I had to perform a fair amount of textual analysis and parser refinement before reaching the point that plucking text from the description to use as the subtitle was logical enough to be more use than hindrance.

Anyway, 0.5.0 of tv_grab_nl_upc is now out, even if I’m the only one who cares.

With this in mind, I purchased an XFX GeForce FX5200 AGP video card for €39 from Alternate, which has a well-supported nVidia chipset. The card arrived in the post yesterday, so I installed it in the system and got to work configuring it at the end of the evening.

With the loss of the PVR-350′s on-board MPEG-2 decoder, playback now has to be handled by the CPU, but we have a 3 Ghz Pentium 4 in the box, so it can take it in its stride. This is pretty much the only disadvantage to switching to this video card.

Here are some of the advantages:

• The FX5200 has a DVI Out socket, so we’re now connecting to the TV using DVI. The result is that X and MythTV now look superb on our 94 cm Philips LCD TV. The image is crisp and clear and we can drive the TV at its native resolution, which appears to be 1280×720. Related to this, menus and widgets no longer run off the screen and fonts are properly scaled. Bliss!

• Thanks to DDC, the monitor can now tell the video card which video modes it can handle, so the Xorg configuration is now very simple and doesn’t even need HorizSync or VertRefresh parameters for the TV. Here’s the relevant section from Xorg.0.log;

(--) NVIDIA(0): Connected display device(s) on GeForce FX 5200 at PCI:1:0:0:

(--) NVIDIA(0):     Philips FTV (DFP-0)

(--) NVIDIA(0): Philips FTV (DFP-0): 135.0 MHz maximum pixel clock

(--) NVIDIA(0): Philips FTV (DFP-0): Internal Single Link TMDS

(WW) NVIDIA(0): Mode "1280x800" is too large for Philips FTV (DFP-0);

(WW) NVIDIA(0):     discarding.

(WW) NVIDIA(0): Mode "1280x768" is too large for Philips FTV (DFP-0);

(WW) NVIDIA(0):     discarding.

(II) NVIDIA(0): Assigned Display Device: DFP-0

(II) NVIDIA(0): Validated modes:

(II) NVIDIA(0):     "1280x720"

(II) NVIDIA(0): Virtual screen size determined to be 1280 x 720

(--) NVIDIA(0): DPI set to (76, 76); computed from "UseEdidDpi" X config option

I’m not sure why those first two modes are tried, since they wouldn’t offer the correct 16:9 aspect ratio. If anyone knows, please tell me. Nor do I understand why 1920x1080i isn’t tried or selected, since our TV is capable of that resolution. I’m not too bothered, though, since we don’t have any input sources that can provide that resolution.

• MythTV is slowly moving towards OpenGL for its themes and menus, so having an nVidia card with its hardware acceleration allows us to enjoy all of the OpenGL goodies. TV playback can also use certain OpenGL functions to reduce jitter and make other improvements to the image. And, very pleasingly, we can now enjoy all of the OpenGL visualisations offered by the MythMusic module. The TV has become a big flat disco ball for listening to my music collection!

• Although MPEG-2 decoding is now handled by the CPU, we can still offload some of the work to the video card’s GPU by using MythTV’s XvMC support. A lot of people seem to have trouble with XvMC, but I found it very easy to get working. The only issue was that the OSD (on-screen display) became greyscale rather than colour, but that’s a known issue and there’s an easy fix for it.

• During playback, fast-forwarding at greater than 3x speed now properly displays the current location in the recording. With The PVR-350, fast-forwarding beyond 3x speed would freeze the playback image, leaving you with only the playback timer to hazard a guess at where in the stream to resume playback. This was very annoying and confined us to 3x fast-forwarding much of the time.

• During playback, rewinding at any speed now properly displays the current location in the recording. Similar to the previous point, but even more annoying, was that the PVR-350 would freeze the playback image when rewinding at any speed. If you wanted to replay the last couple of scenes in a programme, you would thus have to guess how long they were and resume playback after rewinding that many minutes.

• Not using the PVR-350 MPEG-2 decoder for playback means that the audio and video are now separable. This, in turn, means that we can now send audio to our sound system, rather than being restricted to using the TV’s built-in speakers.

• As a result of the previous change, the internal MythTV volume controls now also work. Previously, we had to adjust the volume via the TV, because the PVR-350′s hardware decoder volume was beyond the control of MythTV.

• The ivtv driver decoder errors that have plagued us since I first set up this system almost a month ago are now happily also a thing of the past. We would regularly get errors like these in the log:

Sep 18 14:36:52 tourbillon kernel: ivtv0 warning: DEC: Sched Buffer end reached 0x0ad51267

Sep 18 14:36:52 tourbillon kernel: ivtv0 warning: DEC: Mailbox 10: 0x00000000 0x0ad41267 0x0ad41267 0x00000000

Sep 18 14:48:32 tourbillon kernel: ivtv0 warning: DEC: Decoder Invalid type 0xd8031707?

Sep 18 14:48:32 tourbillon kernel: ivtv0 warning: DEC: Decoder Invalid type 0x0e86df64?

In practical terms, these manifested as occasional picture freezes during playback. Sometimes we’d get several within a few minutes. At other times, we’d watch a whole programme without one. They were very unpredictable.

A quick hit of the Rewind button was necessary to unjam the system. It was irritating, but we were able to live with it. Now we’re no longer using the hardware MPEG-2 decoder of the PVR-350 card, however, we’re avoiding whatever it was in the driver or the firmware that was causing these.

• Time-stretching now works properly. Time-stretching is the ability to play back video at faster than normal speed, but with the appropriate audio compensation, so that the pitch remains constant.

The idea is that, if you’re short on time, you can get through a 30 minute programme in, say, 20 minutes if you pay good attention and can stand listening to people who talk very quicklyt. At 1.5x speed, for example, everyone sounds like the people who read the disclaimer at the end of American radio adverts. You know the ones, where it sounds as if all the gaps between the words in their sentences have been sucked out.

• Because we’re using a plain old video card now, the entire Linux boot process can be followed on the TV screen. If there’s ever a problem that causes the system to fail to boot, I’ll now be able to debug it without a blindfold.

And that’s about it. I reprogrammed our Harmony 885 universal remote-control to use the external sound system instead of the TV’s audio for MythTV playback and to select the DVI input on the TV instead of the relevant SCART connector, and now we’re all set. I just need to go and buy a new DVI cable, as I borrowed the one from my computer upstairs for testing purposes.

I had intended to go into the crawlspace under our house at the weekend to lay down some CAT5e cable. The intention was to run Ethernet to the spot directly under where our TV is located, then up through a tiny hole in the floor that the previous owners must have (had) drilled. That would give us the much needed wired network access that we’re missing in the living-room.

Well, when I went to do the work, I noticed that I had purchased the wrong kind of cable; I had bought solid cable instead of braided. So, I went back to Media Markt yesterday and switched my solid cable for a 50m reel of braided.

Today, I had no good reason to put off the work any longer, so with the family out of the way, I got down to some undisturbed work in the cellar.

The crawlspace under our house is really quite vile. It’s not just a flat, dusty space down there. Oh no, it’s full of rubble, old plastic bags, bits of old wire and God knows what else; probably a load of rat turds and asbestos, I shouldn’t wonder.

I’d bought a nice, powerful Maglite torch yesterday, an essential piece of kit when crawling around on your belly and elbows in the pitch black. It has a rotary head, so that you can turn from a wide angle beam into a sharp, bright point of light. I’d been bitching for ages that we didn’t own a decent torch, but thanks to a local ironmonger’s, that’s now been put to rights.

Anyway, I was under the house for only about fifteen minutes and there were no unexpected hitches. It was easy to draw the cable across the breadth of the house and feed it up into the living-room.

Upon exiting the crawlspace, I immediately headed upstairs for a shower. My clothes, skin and hair were covered in… I don’t even want to know what.

Back downstairs, I carefully stripped the cable in the living-room and crimped an RJ-45 connector onto the end, using an excellent guide, turned up by Google. If you think that I know the colour-coding order of an Ethernet cable off by heart, you’d be wrong.

With one end done, I went back downstairs into the cellar and crimped a connector onto the other end. I then hooked up that end to the router.

Back in the living-room, I plugged the other end of the cable into the on-board Ethernet jack of the MythTV box, tried to bring up the link and… bingo!

Sep 20 16:43:32 tourbillon kernel: e1000: eth0: e1000_watchdog_task: NIC Link is Up 100 Mbps Full Duplex

I’ve already decommissioned the 802.11b WLAN card inside the MythTV box, as it’s no longer needed. It wasn’t working well any more anyway, because it was suffering interference from the wireless speakers of our recently purchased Logitech Z-5450 5.1 speaker set.

With a 100 Mbit link from the MythTV box, I’ll now be able to stream TV programmes to my workstation on the top floor, which could be handy if Sarah is commandeering the real TV downstairs.

In the future, I suspect we’ll eventually move to gigabit Ethernet and a distributed MythTV set-up, so that we can stream programmes and DVDs to televisions anywhere in the house. We could even make the front-ends discless, so that there would be almost no noise emanating from the cases.

Anyway, that stuff is all some way off yet. I’m just happy to finally have Ethernet where the TV is.

As I’ve mentioned before, the new hardware that Web Host Plus put me on after managed.com sold my hard drive to them was less than reliable. I suspected a few causes, one of which was bad RAM. This theory now seems to have been borne out by an experiment I did. Before I rsynced our photo gallery across the Atlantic, I rebooted the problem box in New Jersey and reduced its operational RAM from 2 Gb to 512 Mb. In that new configuration, I was able to spend many a joyous hour copying my precious data over the transatlantic pipe without the originating box going AWOL. QED, I’d say.

I’ll be cancelling service with managed.com, Web Host Plus or whoever’s running the show now as soon as my next invoicing cycle starts. Good riddance to bad rubbish, as they say.

In the meantime, any DNS oddness you may have been seeing should now be a thing of the past. All slaves are in sync and handing out correct data. Incorrect data in the caches of other DNS servers should now also have expired. Normal service has now been resumed.

I was able to bring it back much more quickly than I had first anticipated, because I used an old Gallery 1.x back-up to seed the albums in the Gallery 2.x installation. That copied hundreds of extra, unnecessary files, but they were easily removed afterwards by rsync.

I did this by getting a list of all the album directories on the remote server:

cd /var/www/g2data/albums
find -type d > /tmp/file_list

I then copied this over to the new server with the Gallery 1.x back-up:

for i in `cat /tmp/file_list`; do
  album=${i##*/}
  src=`find /var/www/html/albums -type d -name $album`
  [ -n "$src" ] && rsync -av $src/ /var/www/g2data/albums/$i
done

In the end, I needed to copy from New Jersey only the photos we had taken since mid-February, which is when I had done a full back-up in preparation for migrating from Gallery 1.x to 2.x.

Somehow, one of the tables in the MySQL database had got corrupted in the move:

060518 18:02:38 [ERROR] Got error 134 when reading table './gallery2/g2_ImageBlockCacheMap'

This was easily corrected:

mysql> repair table g2_ImageBlockCacheMap;
+-----------------------------+-------+---------+----------------------------------------+
| Table                           | Op     | Msg_type | Msg_text                                    |
+-----------------------------+-------+---------+----------------------------------------+
| gallery2.g2_ImageBlockCacheMap | repair | warning  | Number of rows changed from 45465 to 45460 |
| gallery2.g2_ImageBlockCacheMap | repair | status   | OK                                           |
+-----------------------------+-------+---------+----------------------------------------+

And, with that, the rescue and salvage operation to yank caliban.org from the incompetent clutches of the unholy alliance of Managed.com and Web Host Plus is 95% or more complete.

Once the residual DNS propagation issues evaporate, I’ll be able to fully exhale once again.

I’m knackered, but a lot has been accomplished today. DNS and e-mail have now been fully migrated, including Web mail and mailing lists. The Web site, too — which you’re now reading — is also up and running on the new (well, actually quite old) server.

The main thing that’s not yet back up is our gallery of photos. That’s because it’s 19 Gb of data, which would be slow to copy from a reliable server on a fast network. Well, I have to copy it from a machine that keeps crashing and is not on a fast network. It could be a couple of weeks before I manage to get all of my data off it… if I’m lucky. I don’t want to even contemplate the notion of not being able to recover all of my data.

I thought I’d left this kind of sysadmin drudgery behind me when I stopped working. Indeed, I moved my domain to dedicated hosting to reduce the downtime and maintenance that I had repeatedly endured when I hosted it myself on a domestic DSL line. Little did I know that I would get to enjoy such advantages for barely a year before falling victim to the worst kind of professional incompetence: that with no sense of responsibility for one’s customers.

And so caliban.org is back on a domestic DSL line, albeit one that has proved itself more reliable than those I had in the US. The upstream bandwidth is also somewhat better.

Anyway, don’t bother looking for new photos — or old ones — in the near future. I’ll announce when — if? — they’re once again available.

Who am I talking about? Managed.com, of course, the

company to which I give good money each month to host this site.

What happened?

Well, managed.com decided to move its network from California to New Jersey.

At least, that’s as much as they told us, the paying customers.

In preparation for this, they sent all of their customers an e-mail asking to

be supplied with the customer’s root password via plain text e-mail. For those

of you who aren’t in the field of computer system and network administration,

let me state that this is a violation of one of the most basic and universally

lauded principles of the profession: never, under any circumstances, send

passwords in the clear.

And yet, my hosting provider was asking me to do just this. In hindsight, that

should have been enough to spur me into action. I should have found another

hosting provider, right there and then, and moved my data prior to the

migration. But I decided to wait until after the migration to seek a better

provider. As always, laziness, compounded by a failure to recognise the

urgency of the situation, won out.

Anyway, managed.com were supposed to back-up their customers’ data, firstly

with a full back-up and then, shortly before the migration, with a further

incremental back-up. The migration was supposed to be barely noticeable, with

a guaranteed maximum of two hours of downtime.

I was sceptical, but kept my fingers crossed.

Can you believe that managed.com didn’t tell its customers in their

notification e-mail when this migration would actually take place? We were

left to guess. E-mails to them on the subject went unanswered, as did requests

for a secure channel through which to supply one’s root password.

When I noticed one day that my machine had been rebooted without my

permission, I incorrectly assumed the migration had already taken place. If

I’d known at that time that things would be moving to New Jersey, not just

around the corner in California, I could have run a traceroute and seen that

my machine had not actually gone anywhere. At that time, however, I thought

they were just moving locally. What else could I think? Managed.com had told

me virtually nothing in their e-mail.

caliban.org mysteriously went off the network on 9th May. It remained

inaccessible for almost three days. So much for the two hours of guaranteed

downtime.

All of my e-mails to managed.com went unanswered in this period. Only when I

threatened them with legal action (a trick I picked up in America), did they

finally respond by rebooting the machine and getting it back on-line.

Naïvely, I thought that would be an end to my problems. Yes, that was

very naïve of me.

You see, managed.com restored my service from a week old back-up. I’ve no idea

what happened to the promised incremental back-up. It was probably never made

and, even if it was, it would have had to be of the last week’s worth of data,

not just the day before the migration. I suspect it was never even made,

however.

The net effect? I found I was missing a week’s worth of e-mail, multiple DNS

changes had been lost, the last week’s worth of blog entries had effectively

never been written, and sundry other less serious issues now needed to be

fixed, such as recent software updates becoming undone.

More e-mails to managed.com went unanswered. Due to an oversight on my part,

my own off-site back-ups had not taken place in recent times, so I had no

private back-up from which I could recover my data. Typical.

I began work on the system to repair the damage my hosting provider had done

to it, but before I could achieve very much, the system went down again. The

system was off-line again for more than a day. Once again, e-mail threats were

required to get it back on-line.

So what’s going on?

Exploration of my system’s log messages shows that the new hardware on which

my data resides is not the same as the old. For one thing, the system has a

different Ethernet card. Now, either that card is flaky or the Linux driver

for it is, because the system regularly gives up the ghost and all but

crashes: TCP connections to open ports hang without response; processes can no

longer be forked; even syslogging stops.

Yet, even if the new hardware had presented no problems, it’s inconceivable

that a company would move a working Linux (or any other) system to new

hardware and just expect it to work. What if I had not had the driver for the

new network card compiled for my kernel? My machine would have had absolutely

no way of ever getting back onto the network after the migration. It’s sheer

luck that I can sometimes still log into my machine and that it’s not

completely dead to the world.

So, the networking on the new hardware is extremely unreliable. rsyncs

regularly fail with checksum errors. The more network traffic one pumps over

the interface, the more such errors occur. Eventually, the system becomes

unstable and eventually unreachable.

It’s also possible that the machine has bad RAM or ineffective cooling, either

at the CPU or the data centre level. Witness these messages, culled from my

log in a rare moment of accessibility.

May 15 06:39:58 ulysses CPU0: Temperature above threshold

May 15 06:39:58 ulysses CPU0: Running in modulated clock mode

The system is now on heavy-duty medication: cold reboots, at first twice

daily, but that proved inadequate, so cron now reboots the machine every hour.

That’s the only way to avoid the machine locking up completely, which then

puts me at the mercy of managed.com to reboot it. That’s something that now

seems to take more than 24 hours to accomplish.

Clearly, this appalling state of affairs can’t be allowed to continue, so I’m

already on the look-out for alternative hosting providers.

A year ago, when I selected this company to host my services, people seemed

happy with it. I, too, was happy with the service until earlier this year. In

the last couple of months, however, things have been going downhill, which is

never a good portent for the future. Nevertheless, I was not prepared for what

has now befallen me. These people are lacking even the most basic system

administration skills.

So, what happened? Well, a little research shows that managed.com is not

really performing a migration. The hard drives and the data have moved to the

other side of the country, yes, but not because managed.com is doing it. No,

managed.com has been sold, you see? My data now turns out to be at the mercy

of Web Host Plus, so the current disaster is

actually largely due to their mismanagement and incompetence.

In fact, it turns out that a great many people are in a [similar or even worse

state](http://www.webhostingtalk.com/showthread.php?t=508358), thanks to this

bunch of clowns.

Sixty-three

pages of utter misery and appalling professional disregard of one’s customers

come to light.

Anyway, to say that I am in the market for a new hosting provider is an

understatement. If you have any recommendations, I’d be glad to hear them.

Ideally, they should not be located in the US, due to that country’s Draconian

legal stance with regard to privacy.

Thanks to Google, I was able to rescue the missing

blog entries from the Google

cache. I had to add back

the article comments by hand, which caused the loss of the original time of

entry, but at least the text of the article itself has been recovered.

The week of missing e-mail, on the other hand, is simply gone. Calls to

Web Host Plus to make available the missing incremental back-up simply fall on

deaf ears.

I’m utterly appalled to experience first-hand how this company has lost my

data and now ignores my complaints. I’m left bewildered as to the precise

ratio of incompetence to deliberate professional disregard, but I am 100% sure

that I have to get my data away from this bunch of wankers as soon as I

possibly can.

Until that time, expect the server to be up and down like a yo-yo.

Sadly, I had to bite the bullet and take the thing into a trusted PC shop. There, the bloke tried a new power supply, but it made no difference. That leaves pretty much just the CPU and motherboard to test. I bet it ends up being the sodding motherboard. That’ll give me another thing to send back to the place I purchased it. What a hassle. Buying hardware on-line is fine when everything works, but when it doesn’t…

Anyway, they probably won’t even start to look at it until early next week, so I’ll forget about it for the next few days.