Real World Computing
How not to get my back up
Starting with the server, a full backup was made to the external disk drive. Then I decided it would be wise to get the built-in backup working properly, and to help with this I downloaded the 30-day trial version of the most excellent BackupAssist from www.backupassist.com. This isn't a backup program but rather a front end that controls the free built-in NTBackup program that comes with the OS. There's nothing wrong with NTBackup at all, except that it's somewhat feature-light - BackupAssist fills in these gaps by watching what NTBackup does when it runs under its control. A great example of this is email notifications. NTBackup doesn't tell anyone whether the backup has succeeded or been a total disaster: you're supposed to check for yourself in the logs. BackupAssist allows you to enter a list of email addresses of people who will be notified when it works or when it doesn't, and so forth.
This is quite important, especially when you're trying to engage the onsite staff to have some understanding and take responsibility for their own IT infrastructure. It isn't very good when one of them emails you and says 'I've stopped doing the daily backups, as they weren't working anyway'. One might have hoped that sentence would go on to ask 'What should we be doing instead to fix this?', but no, just stopping doing the backups was fine by them. At least now with BackupAssist in place, they know whether the backups have worked or not.
Within BackupAssist, I created a set of rules to do a daily overwriting backup of everything to the external hard disk. While this wouldn't help if the building caught fire or if they were burgled, it does ensure the backups aren't held on the same actual spindles as the original data. Next up was to fix the tape backup regime, and specifically the handling of the DAT tapes required for each day. This is simplicity itself in BackupAssist, and now a backup tape can be taken offsite every day.
Where to go next? Obviously, it's necessary to do a huge purge of that data fog to remove unnecessary duplication of files. Unfortunately, this is one of those tasks where I can only set up the folder structures for E:\current and E:\archive and then get the staff to do the moving and collating, but at least once we have a sifted 'current' directory tree it will become possible to tease the information into work areas by role. Then I'll be able to start applying some server-side security to the file system to ensure only the necessary people have access to sensitive information. The mess is sufficiently big that this process is going to take several weeks, and it just isn't cost-effective to have me sitting there sifting through the wreckage asking someone what each file is for.
Once this is done, it's time to move on to the next phase of the recovery. At the moment, everyone loves storing data files onto their local hard disks (especially their Desktop). I can understand and sympathise with this desire if you have a network that's more like a 'notwork', because it's very frustrating to keep losing connectivity with the server. However, anything that's stored on the Desktop isn't going to get anywhere near a backup process, so some action is required there. Without telling the staff, we'll deploy the capability in Active Directory to redirect their whole Desktop and 'My...' tree onto the server without them noticing, so that anything they save to their Desktop or My Documents is automatically on the server anyway. Yes, it would be nice to re-educate them into using shares properly, but we have a better plan in place.
