Real World Computing
How not to get my back up
Bob Dylan sang The times they are a-changin, and indeed they are in the world of backup and disaster recovery. Thanks to the explosion in both server disk space and the amount of stuff people now insist on storing, I thought it might be a good idea to revisit a few of the fundamental points when it comes to securing your data. First, though, let's sort out the vocabulary: disaster recovery (DR) isn't backup, and backup isn't DR. In a real disaster, you might end up using some or all of your backup as part of your DR solution, but the needs and expectations of these two areas are quite separate. The tools available to help you do this stuff seem to be changing quite rapidly too, which can be a problem because we tend to take a long-term view of the subject. This isn't kit that will be written off over one year, but investment that's expected to last for many years. The problem with such a long-term approach is that while it works well in the large enterprise space, where you can afford specialists to look after your storage - which is probably hosted on its own SAN (Storage Area Network) - it doesn't work well in the SME space.
Let me give you an example of one company I visited recently. This company is well funded and has around ten people working in the office, with one server running Windows 2003. All the desktops run XP Professional, and it's been relying on ad-hoc support from an external support company for some time, which has almost certainly given good service. However, it's clear there's been a long lag between the reactive flag waving from the office whenever people spot that something is wrong and the external support company dialling in via Remote Desktop to actually identify what's happening. There's no ongoing support contract in place, so the offsite support company quite understandably doesn't spend any billable time on active problem analysis and solution finding, given that the client would probably argue it hadn't been called in to do that particular piece of billable work.
So you have the classic situation of a rotten network, rife with problems and glitches, but with no-one onsite with the knowledge to define the problems accurately, let alone request specific help to cure them. And then you have offsite support that can only try to fix problems when it's told about them and commissioned to do some specific fixing. And let's not get into the politics that this foists onto both organisations involved: 'blame culture' hardly even begins to describe that can of worms.
So what do I find within an hour of parachuting in? Well, the server is a Dell desktop wholly unsuited to the role of a 24/7 server: it has way too little fan capacity and is shoved under a desk in the corner of the office. There's no UPS for it, despite the office being situated at the end of a farm track in the deepest countryside. ADSL is provided via a USB-presenting router, and hence the server has been press-ganged into supporting the NAT routing role too. Fortunately, the firewall had been turned on.
Inside the server configuration, I found an event log that looked like a Christmas tree decorated with red warning errors. It seems no-one had installed any Client Access Licences for this server, so not surprisingly the License Service was shouting every hour or so. Then I came upon the hard disk configuration. There were two hard disks in place, the first one partitioned into a 12GB C drive and a 56GB E drive, both under NTFS. The second disk was set up as a 68GB D drive in NTFS format.
