Three useless backups

Copyright Dr Alan Solomon, 1986-1995

The first phone call came from Ian.  "We've lost all our accounts, can
you help us?".  I calmed him down, and talked him through what had
happened.  He wasn't sure, of course, but his Pegasus accounts had
vanished.  "I've got three backups, but none of them work", he said.
"Switch off and do nothing else", I said.  "We got in an expert, and he
tried to use Recover on the hard disk, but it didn't work." I hate
Recover.  It creates files all over the deleted data, and makes rescuing
their data impossible.  "Oh dear", I said, and explained that Recover
didn't do what he thought - look in the manual.  "Still, there might be
something salvageable left.  Bring it round, and the backups", I said.
"I'll have to get approval", said Ian, and we left it at that.

When I got home the next day, a computer was sitting in the hall.  I
left it sitting there for a couple of days while I finished off someone
else's data recovery, and then brought it up to the computer room, and
opened it up.  I always open them up before I start, you never know what
you might find inside.

This one was quite interesting.  It had a mono card, a floppy card, and
no fewer than two multifunction cards.  Some dealer had flogged them a
multi card when all they had needed was more memory!  The motherboard
was the old 64K type, so they were actually getting only 512K out of it.
They had two serial ports, two clock/calendars and three parallel ports!
There was also a very large card with an attached daughterboard that I
didn't recognise.  It had a port that looked like a video port, but was
the wrong sex;  some special network port, I guessed.  This card was
attached to the hard disk, via ribbon cable and power cable, and I
assumed that the hard disk was being controlled and supplied with power
from this card.  Extremely bad practice, I thought, drawing so much
power from the system bus.

I connected a monitor, and started it up with my copy of DOS.  It booted
up fine, but then refused to recognise the hard disk.  I wasn't very
surprised;  PCs with 64K motherboards need either a replacement BIOS to
drive a hard disk, or else they need to run a device driver.  I phoned
up Ian, and explained the problem.  "I need the disk that you normally
boot from", I said.  Ian said he'd organise something.

Next day John arrived.  He brought a floppy disk, and their copy of
Pegasus, in case I needed it.  I started up the machine, and now it
recognised drive C, but it gave "Device not ready" when I tried to read
it.  I thought about the power cables from the card to the hard disk,
about the very silent hard disk, and about the networking port.  I
realised that at least one of us had been very silly, me included.  "Is
there a separate power supply?", I asked.  "Oh yes", said John, "Don't
forget to switch it on." "I haven't got it", I said.  We looked at each
other.  John said something.  I agreed.  Then he trekked back to his
office to get the power supply, and when he returned that afternoon, I
was able to get the whole thing working.  And by golly you knew it was
working.  The hard disk made a sound like gravel being ground up all the
time - I couldn't see how people could bear to work with that racket
going on.  "This sounds like an imminent hard disk failure", I said, and
John admitted that he'd been a bit worried about it.

I looked at the hard disk.  It looked as if someone had deleted all the
Pegasus data files with a DEL *.DAT.  Then the expert who ran Recover
created a whole load of garbage files right on top of them;  even the
directory entries were overwritten.  The hard disk was hopeless, and I
told John so.  "But I had to look at it," I said.

Next, I turned my attention to the floppies.  There were three sets of
floppies, marked A1 to A5, B1 to B6 and C1 to C5.  There were also four
floppies without labels, which I labelled as D1 to D4.  I printed out
directories on all of then, spread the printouts on a table, and looked
at what I had.  A1, B1 and C1 were pretty nearly identical.  The first
file was called BACKUPID.@@@ which meant that they were files created
using BACKUP.  Then there were about a dozen files with names like
APL-TRAN.DAT and ASL-FREE.DAT.  Pegasus uses the first letter of the
file name to distinguish between the different companies;  I could see
that their company was A.  PL probably means Profit and Loss, SL
probably Sales Ledger and ST probably Stock.  TRAN was probably a file
of all the transactions, and FREE perhaps was free space?  You never
know what deduction might be useful when you're doing a thing like this,
so you just learn all you can.

The other interesting disk was A5.  This also had several files on it,
starting with BACKUPID.@@@, then AST-TRAN.DAT, then various other
Pegasus data files.  The way backup works, is if a file is too large for
one disk, it continues it on the next disk.  So, I could see that I had
all the files on these two disks, with the exception of AST-TRAN.DAT,
which was obviously a large file.  When I looked at the other disks,
most of them were pieces of AST-TRAN.DAT, even if the files on them had
other names.  You can see what a file is supposed to be, as the first
128 bytes of a BACKUP file contains the subdirectory and filename.
There is also a flag that numbers the disks in a backup series, and
other flags that I didn't understand, but noted down in case they were
useful.  One of them, I think, was a flag that said "continued on the
next disk" which is how RESTORE knows when to stop asking for disks.  I
wrote a little program to convert BACKUP files (with the extra 128
bytes) into normal files, and rescued all the little files.  I didn't
think that John would get much benefit from them, but at least I would
have something for him.  The main job, though, was AST-TRAN.

I looked more closely at the disks.  The best batch was the B series.
B1 was fine, but B2 looked like it actually been used as the fourth
disk.  B3 looked OK, and B4 nearly OK - the BACKUPID was part of the
file, and the first part of the file was the BACKUPID.  B5 looked fine,
and B6 was the tail end of the backup - a dozen files, starting with
AST-TRAN.

Next came the A series.  A1 was all right, but A2 was one long
FILE0000.REC;  someone had used recover.  A3 was a part-backup of
AST-TRAN, A4 was another FILE0000.REC and A5 was the dozen or so files
at the end of the backup, starting with the end of AST-TRAN.  The C
series looked awful.  The first was OK, but the next two had their
directories badly trashed.  I had a look at the directory sectors and
the File Allocation Table, and I could see that I could use CHKDSK on it
if necessary, as the FAT looked fine.  C4 was a blank, formatted disk,
and C5 was a dozen FILE00nn.REC.  The D series turned out to be all
FILE00nn.REC files.

So I had the first part of AST-TRAN on disks A1, B1 of C1 - I could take
my pick.  The B series was the most recent by a few hours, so I took
that one.  That gave me the start of AST-TRAN, and the next job was to
find part two.

I poked around inside the first part of AST-TRAN.  The file consisted of
records, and I documented the record structure.  The most interesting
fields were a code that was usually three letters and three numbers that
was not unique (probably a part number), two integers in ASCII format
(probably the price and cash paid) and two four-byte things.  One of the
four-byte things was the same for each record, and changed only quite
rarely - I guessed that this was the date.  But the other one was
extremely interesting, because it appeared to be unique to each record.
I guess that this is the unique key that identifies each record, so that
Pegasus can find them.  But this uniqueness was just what I needed.  I
made a note of the last key in the first part of the AST-TRAN file, and
went looking for it on the other disks.  I searched all the disks,
without success.  Then I thought that perhaps one of the disks would
just be a continuation of the files, and again I searched through.  This
time, I was lucky.  It would be hard to explain what it was that made it
possible to see that one disk was a follow-on, but it was the way the
part numbers ran, the way the dates worked and the fact that a record
was split between the two files, and matched up exactly.  So now I had
part two of AST-TRAN, on A2.

I looked at the far end of part two, and tried to do the same again.  I
searched all the possible disks, but couldn't find a match.  So I went
back to the previous method - I wrote down one of the unique codes and
searched for that.  BINGO!  in the middle of one of the disks, there it
was.  I also found it on two other disks.  I displayed the area around
the code, and I could see that the match was no coincidence - everything
before that code was identical also.  So I had found part three.  Then I
searched for part four using the same method, and I found it on one of
the disks that was the last of the backup series, in the middle of the
file.  So I knew it was the last one.

Having found the four pieces of file, I carefully snipped off the
surplus bytes that BACKUP puts on, and also removed those parts of file
that overlapped.  Then I joined the four pieces of file together,
end-to-end.  I then used BACKUP to create a backup of all the Pegasus
data files, and RESTORE to put it on John's computer.

At this point, I didn't know whether it would work.  I had joined pieces
of four different files together, and Pegasus might well have found it
impossible to read the resulting hybrid.  For example, if this joining
process had meant that the pointers were no longer consistent, I was
probably helpless.  Either this thing worked, or else it didn't, and all
my careful surgery had been for nothing.

It worked.  Pegasus showed me all John's stock - the Men's Berets (size
7), the Boys Shirts (blue);  his purchases and his sales.  I rang him
up.  "Come and see what I've got for you", I said.

John, of course, was delighted.  I think he'd really given up, and was
just letting me have a go because I seemed to think there was some hope.
He wandered happily through the data he thought he'd never see again,
and beamed.

"Right", I said.  "Prevention.  I don't want to see you here again, or
at least, not with a computer under your arm." Pegasus recommend a
rotating backup using three generations of disks.  John had been
following that faithfully, but using the same disks, and never
reformatting them.  Some of the C series had got trashed (probably by a
magnetic field at some time) and their directories didn't work properly.
One of the B-series wouldn't take data, claiming that it was already
full.  And I wasn't sure exactly what was wrong with the A-series.
Here's how I told John to do backups in future.

Always use freshly formatted disks, so that if a directory or FAT gets
scrambled, formatting will put down a new, clean one.  Don't do a
rotating backup (using three sets of disks in turn), as if anything
happens to your main database, this will very quickly get copies over
all your backups, perhaps before you realize that you have a problem.
Instead, use a completely new set of disks for each backup, and label
them with the date and their backup order.  Keep these disks in a
cupboard and don't re-use them until they are so out of date as to be
useless.  Disks are so cheap these days that if you buy them in
quantity, you won't pay anywhere near a pound each.  Every now and then,
take one set of backups home with you;  if a really major disaster
strikes, it could wipe out your cupboard-full of disks as well as your
computer.

How much trouble you should take to protect your data depends on how
important your data is, how much time it takes to do a backup, and on
how likely it is that you will lose the contents of your hard disk.  My
experience is that on the average, a major data disaster happens about
once per year;  now you can decide how much data you want to lose when
it hits you.  Not if - When.

Alan Solomon