EARLIER FEATURES

FEATURES CONTENTS

LATER FEATURES

BRIAN'S BACKUP

Brian Grainger

brian@grainger1.freeserve.co.uk

When adversity strikes you can either moan a lot and try and blame someone, or do something about it so it does not happen again. When it comes to troubles causes by our IT department at work I do both!

The way the PCs are managed on the network at work is fairly standard. The applications are stored on the desktop PCs but the login profile is on a central server and employees are advised to store their data on central hard drives. Each user has their own 'home' drive when they logon, specified as 'H:' on the network. We are told that if our work is stored here then it will be backed up automatically and we do not have to worry about it. However, as became clear last year, we are not told how often the backup is done!

I was very lucky last year. I was having a few problems with accessing my home drive. Sometimes it worked and sometimes it didn't. This is a problem because all my working data is stored on it. If I cannot access the data I cannot work. I decided to backup my H drive to my hard drive on the PC just in case. Lo and behold the day after I did this nobody in the company could access the their home drives! I was smirking. I could carry on working because I had all my data on my local PC. The real killer to those people that didn't came later. First, it took best part of a week before the home drives were restored. Then, when they were, some people found that the last backup had occurred a month previous, so they had lost a lot of work. It all depended on the initial letter of your surname as to when your backup occurred. Here was me and many others thinking that incremental backups were done daily, or at worst a couple of times a week. I happened to know that one of the unfortunates was someone in IT who had done rather a lot of work in the period up to the problem so I felt that retribution had been dealt in some way.

That was last year. Slowly things got back to normal and the H drive became very reliable again. Of course, we forgot all about it. Our colleagues in Portsmouth complained a lot that their H drives would periodically disappear but this seemed to be a Portsmouth problem and did not affect us in Stevenage. Then, earlier this year, the unthinkable happened. We lost the home drives in Stevenage again and this time I had not got a copy on my PC's hard drive to use. Apart from the inconvenience of trying to do work I had visions of losing my data for the previous month. While we were without our home drives for a week again, it being a function of checking the recovery process we were told, I was fortunate to have all my data back intact. However, I vowed never to trust our IT service again.

What I wanted was a backup system. It had to be simple and quick to do, because I wanted to do it once a day, at least, and it had to work! There was one other difficulty. We are not allowed to install our own software on our PCs so the backup had to be done with our existing software.

The first part of the problem, defining what to backup, was easy. My way of keeping data saw to that. Our wonderful IT service sets things up so that users have a Document directory, a Spreadsheet directory, a Graphics directory and so on. Windows XP follows a similar idea with My Documents, My Pictures, My Music, etc. We run Windows NT4 at work but I soon found this type of segmentation unhelpful. We all work on projects so I wanted my data, whatever format it was in, to be associated with the project it was applicable to. Of course, I do further segmentation but that is irrelevant to my backup procedure. Suffice to say I have I folder at the top called Documents and then it splits into the various projects and so on down the tree. Defining what to backup was therefore very simple. I wanted to backup everything on the Documents directory and below from my home drive to my local PC.

The first time I did this backup it took quite some time as I have about 1.7GB of data to transfer from the network. My backup system therefore could not simply back up everything, every day. I only wanted to backup the files that changed or were new since the last backup. This is called an incremental backup. This is not so easy to do with the Windows on our PCs because it does not include the Windows Backup system tool. IT do not like us to use our hard drives! However IT have not removed the command line utilities so my knowledge of DOS came to the fore.

First of all I created a directory for the backup on my PC's hard drive. The files on my home directory are in H:\data\documents and below, so I created D:\H Drive\data\documents on the D drive of my PC. Having done this I could do the incremental backup with a single DOS command:

The first two parameters of xcopy are the source and destination directory.

The /s switch says copy everything in the directory and all subdirectories.

The /d switch says copy those files whose time is more recent than that of the equivalent file on the destination drive. It is this parameter that does the incremental backup, rather than a full backup.

To incorporate my backup command I just created a batch file with that single DOS command in it. All I had to do was run the batch file by double clicking it in Windows Explorer. That made my procedure simple and quick. The final requirement to meet was: Did it work? I decided the simplest way to do this was manually. No doubt I could program something but I decided for simplicity. I decided to do a comparison check before and after the backup.

The simplest comparison check is, prior to the backup, to:

Open Windows Explorer

Right click H:\data\documents and select properties

Make a note of the total bytes used and the number of files and the number of folders.

After the backup is complete

Open Windows Explorer

Right click D:\H Drive\data\documents and select properties.

Make a note of the total bytes used and the number of files and the number of folders.

If the numbers match those noted before the backup then it has worked.

This procedure worked fine for a number of days but there was a problem, which I had recognised. This backup procedure copes fine with file changes and file additions, but not with deletions. If a file is deleted on the home drive it will stay for evermore on my PC's hard drive. A similar problem occurs if you rename a file. Again, I initially solved this manually. On those rare occasions when I delete or rename a file I need to do it on the backup as well. However, there are times when I am going to forget.

The problem is that if, after doing a backup, the bytes/folders/files numbers of the D drive backup do not match the H drive original then files may have been deleted, (by mistake or deliberate). The problem is how to determine which ones!

It seems obvious that taking a directory listing with the subdirectory, (/s), option in the documents directory of source and backup is required. Doing this and comparing the two files should highlight the differences. However, there are problems.

When directories have to be created on the backup the time stamp of directories and the files '.' and '..' can be different, even though the directories are otherwise the same. The only way round this I could see was to use the wide format, (/w), option or the bare, (/b), option, which will not dump the time stamps. The /b option names every file complete with directory path from the root. Thus every file will be different by name, because it is on a different drive.

Even the /w option shows the directory names including the drive specifier, so all directory headings will be different between files. The way to solve this is to use the SUBST command to associate the document path to a fixed drive before doing the directory listing.

I also think it may be wise to sort the directory order when listing it.

Bearing in mind the above points I created a batch file with the following contents:

I use the x: drive as a substitute for whatever folder I am going to list.

The dir command then does this listing of all subdirectories, (/s), in sorted order, (/ogne), to a file on the PC's hard drive

After doing the listing of the home directory I remove the x: drive, (the /d, for delete, option to the subst command), before reassigning it to the backup directory.

This backup directory is listed to another file on the PC's hard drive.

Finally the two listing files are compared, using the fc command. The comparison is fed to the file compare.txt on the PC's hard drive.

Now, whenever there is a discrepancy in the figures before and after a backup I simply run this batch file and have a look at the text in the compare.txt file. While it will not spell out what is wrong, it will indicate the additional files/directories on D drive compared to H drive. Usually there is enough information to determine where the additional files are located so finding them is now much easier to perform.

The use of this little procedure will also show when you have accidentally deleted a file, which is quite useful when you still need it. It is much quicker to recover it from your PC than ask IT to get it from the backup!

There is one potential problem outstanding with this procedure. Because there are no time stamps or file sizes dumped, the comparison will not catch any files that differ only by date or size. The original backup process should catch these files, but it cannot be confirmed. You will see a total file size difference, but you will not know which files are the problem! So far I have not been caught out by this, so I think it is such a rare event that an automatic process is not necessary.

I hope this little tale of how I overcome another obstacle laid by our IT department was of interest. Necessity is the mother of invention, they say, and, as I have said before, good old DOS will often be the invention you need!

TOP