Gallery

How not to get my back up

Posted on 24 Oct 2005 at 12:34

Jon Honeyball is in total disbelief as he comes to the rescue of a company completely ill prepared for data backup emergencies

Due to numerous staff changes over the last few years, there was absolutely no sign of data management in place at all. Endless copies of workstation hard disks and My Documents folders were sprinkled all over it like confetti, while a thick fog of Word documents, Excel spreadsheets flowed all over the disks without any regard for structure at all. All users - yes, everyone - had access to the root share of the E drive on the server, and no security had been put in place to keep the wrong people out of the more sensitive directories (holding stuff like the staff payroll and HR files). Taking both the D drive and E drive into account, we were looking at about 60GB of data and, although obviously the working set was likely to be much less than 1GB, deciding which 1GB out of 60 wholly defeated me. Naturally, every user knew the Administrator password...

Then I came to the backup procedure. Someone had attempted to be bright by going for both a disk-based solution and a DAT tape, which at least sounded promising. The disk-based solution consisted of running NTBackup and making a disk-based file the destination: so far so good. Unfortunately, though, this backup file was located on the same physical hard disk as the source data, and was thus completely useless in the event of a disk failure. And these backups ran only every Monday, Wednesday and Friday, which wasn't much help either.

The backup to tape looked marginally more promising until I looked at the backup log in NTBackup: the words 'Cannot locate the specified media or backup device. This backup operation will terminate' may perhaps cause the same nervous flutter in you as it did in me. What it meant, of course, was that the responsible person in the office was dutifully removing last night's day-of-week tape from the tape drive every evening, then inserting the correct tape for tonight. However, at no point did anyone actually check that the backup was running, whether it had fallen over or crashed, or whether anything was happening at all. As best as I could find out, the same nothing had been happening for months. Oh yes, did I mention that the NTBackup settings for the tape backup had 'verify' turned off, so that even if a tape operation had actually taken place there was absolutely no confidence that it had successfully written anything to the tape?

Then I looked at the network cabling itself: a mangrove swamp of 100Mb switches creeping around the room, which naturally had no proper structured wiring in place, despite having been rebuilt only a few years ago. There was also a nice 10Mb hub connecting the whole network to the server, to ensure that everything ran as slowly as possible. A few members of staff complained that opening and saving files on the server was highly unreliable, because often the machines would 'just sit and think for minutes at a time'. A poke under the desks found that over half the Ethernet plugs were hand-made push-on types that were falling apart and becoming disconnected. The real surprise is that any packets at all managed to struggle over the Himalayan peaks that divided server from workstation - a true testament to the sheer resilience of Ethernet.

Where does one start when presented with a mess like this? Well, the first job has to be to secure the data currently on the server, so a swift trip was made to a local hardware emporium where an external USB 2 hard disk was purchased, along with a proper Ethernet-delivered ADSL router (with firewall), a 100Mb Ethernet switch to replace that 10Mb hub, and some lengths of Ethernet electric string to replace the dodgy plugs.