RemoteBoxes & Customer Profiles: Under Development

The first RemoteBox grew out of a simple need; a need shared by many computer users: to have a computer that would continue to work reliably without user intervention; particularly as this computer would normally be 100Km away from me and yet I would be expected to retain full control of it when required. The server was for academic/domestic use with unpredictable useage patterns throughout the day. This was required to support 3 fixed clients, and some laptops on occasions.

To that end a Linux based computer was built with solid communications abilities and with much greater than average fault-tolerance. The steps towards fault tolerance - and fault avoidance were relatively simple, with hindsight:

 Disk Mirroring: contrary to the beliefs of some 'experts', hard drives do fail. So data was duplicated onto multiple drives. No data has ever been lost from a RemoteBox.

 Service Control: some computer/network services were more reliable than others. Any essential service was re-configured to restart in the dead of night, whether necessary or not, so that it would be good for the next working day.

 Killing the Box: Linux is the best system for a RemoteBox; but on one occasion we had to use a Microsoft© Windows NT Server. This was a noteably troublesome server, not living up to expectations or needs. In the end, every Sunday at 04:00 it was set to automatically restart itself as it could not be depended upon to work properly from the 8^th day onwards! We never built an NT© server after that.

 WAN Reset: under normal circumstances a modern RemoteBox is connected to your broadband line. Back when we had to use modems we'd find that a modem would become 'stuck' and refuse to operate after a while. For this RemoteBox the solution was to put a digital multi-day timer on the modem that would turn the modem off and on again - whether it needed it or not - to refresh the modem. As there were 4 modems in place to enable staff to dial onto the network from around the country, it was essential the modems worked, or else I'd get an earful! Again this was done at the lowest part of the night, every few nights.

 Backups and off-site backups: some customers take this more seriously than others. With our modern RemoteBoxes we can do off-site encrypted backups over The Internet back to the base server. This provides fantastic data security in the event of fire and loss of premises.

 Daily monitoring: tomorrow (Monday) morning I must ring one client to inform them that one of their hard-drives went down late last week. They don't know that because the RemoteBox is fault tolerant. You could say that this is the peace of mind they bought. We know about it because the RemoteBox talks to base every day. The Box is well out of warranty but the replacement drive will be inexpensive and probably be installed out of business hours in order not to interrupt the companys computer intensive routine.

That first RemoteBox lasted 437 days on its longest run. Then the CPU cooling fan failed causing the CPU to overheat and the system to stop until repairs could be made. The Box used a Pentium 166 (modern it's day!) processor which had the fan firmly attached. Therefore the repairs involved replacing the CPU & fan combination from stock. Today we'd just replace the fan but even in this smallest of ways, technology moves on. No data was lost from the repaired server, however. That server was called \\mercury and there are still folders with its name on the base network into which we backed up its data when we de-commisioned it a year or so later.